<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body>
    On Sun, 2 Aug 2020 22:08:56 +0200 Mart van de Wege
    <a class="moz-txt-link-rfc2396E" href="mailto:mart@vdwege.eu"><mart@vdwege.eu></a> wrote:<br>
    > On Sun, 2 Aug 2020 21:59:05 +0200<br>
    > Michael Biebl <a class="moz-txt-link-rfc2396E" href="mailto:biebl@debian.org"><biebl@debian.org></a> wrote:<br>
    > <br>
    > > Am 02.08.20 um 21:41 schrieb Mart van de Wege:<br>
    > > > Package: systemd<br>
    > > > Version: 245.7-1<br>
    > > > Severity: normal<br>
    > > > <br>
    > > > With SELinux enabled (booting with selinux=1
    security=selinux), as<br>
    > > > soon as systemd wants to clean up
    /run/user/<UID> for a session,<br>
    > > > the kernel will oops, leaving the
    systemd-user-runtime-dir process<br>
    > > > that's trying to clean up the directory in an
    uninterruptible sleep<br>
    > > > (D) state. <br>
    > > <br>
    > > I fail to see how this is a systemd bug. This looks more
    like a kernel<br>
    > > and/or Selinux issue to me.<br>
    > > <br>
    > You have a point there. I selected systemd because it at first
    appeared<br>
    > to be a systemd bug (process hangs), but of course, if it
    causes an<br>
    > oops reliably with selinux enabled (which it does), it should
    be<br>
    > retargeted to those packages.<br>
    > <br>
    > Is that still possible, or should we close this one and let me
    refile?<br>
    <p>Before closing the bugs, could you confirm that you are running
      SELinux in permissive mode or not (for what I can see in the logs
      it seems to be the case)?</p>
    <p>On one of my machine at home, I had a similar issue where the
      shutdown/reboot is blocked by systemd-user-runtime-dir and I'm
      certainly running in permissive mode on that machine. But on other
      machines it was not happening, I was planning to investigate more,
      but ENOTIME<br>
    </p>
    <p>Permissive mode shouldn't deny anything, just log what would be
      denied by SELinux. So the bug could be either in the kernel or in
      libselinux (systemd shouldn't be aware that anything would be
      denied). And indeed I see the following BUG in the provided logs:</p>
    <pre class="message">Aug 02 21:05:37 galahad kernel: BUG: kernel NULL pointer dereference, address: 0000000000000060

</pre>
    Are you running the latest available kernel?<br>
  </body>
</html>