为什么 systemd 在会话终止时不尝试停止（某些）进程？

Question

当我尝试关闭logind会话（通过注销）时，某些进程仍在会话下运行，从而阻止其正确终止，从而导致也user@uid.service未终止。我听说后者是一种预期行为（某些单元保持运行是可取的），但我认为让会话运行不是实现这一目标的正确方法。此外，当我手动终止会话时，user@uid.service也终止，所以它似乎像挥之不去的会话被用于此目的。

为了说明我在做什么，这是systemd-cgls我正常登录时（即现在）的输出的一部分：

Control group /:
-.slice
??user.slice
  ??user-1000.slice
    ??user@1000.service
    ? ?? //various units listed; removed for brevity
    ??session-c8.scope
      ??4883 login -- sammko     
      ??4905 /usr/bin/gnome-keyring-daemon --daemonize --login
      ?? //various other processes listed; removed for brevity

输出完全符合预期。退出会话后：

Control group /:
-.slice
??user.slice
  ??user-1000.slice
    ??user@1000.service
    ? ?? //various units listed; removed for brevity
    ??session-c8.scope
      ??4905 /usr/bin/gnome-keyring-daemon --daemonize --login

gnome-keyring-daemon以某种方式幸存下来，使会话保持活跃。如果我们现在运行loginctl show-session c8，我们会State=closing在输出中找到。如果我们继续，kill -HUP 4905我们会发现进程和会话终止，并带走了整个进程user-uid.slice。如果我们继续kill -TERM 4905，该过程也将终止。这让我认为gnome-keyring-daemon不会忽略信号或类似的东西。如果进程需要两次信号才能实际关闭，我会kill -HUP 4905在注销之前尝试这样做，并且进程也终止了。

我的印象是 systemd 试图用 终止进程SIGHUP，它gnome-keyring-daemon通常会做出相应的响应。（我也一直在gpg-agent徘徊，并且成功地忽略了SIGHUP。但那是一个不同的故事。）

所以我的问题是：为什么gnome-keyring-daemon在没有明显原因的情况下注销后继续运行以及如何解决它，除了启用KillUserProcesses.

另外，请注意，这个问题与 systemd-230