Comment 8 for bug 1877528

Aaaand the upstream has decided they can't/won't fix this issue.

One thing that bothers me about this whole situation is that, in order for background services like this one to be cleaned up after logout, they need to behave "correctly." From my point of view, this is backwards.

When the system is preparing to reboot, it first sends SIGTERM to all user processes, waits a few seconds, and then sends SIGKILL. Processes that behave correctly are allowed to close down cleanly, and those that don't, are terminated forcibly. If you didn't have that SIGKILL part, then one badly-behaving process could delay the reboot indefinitely. By doing things this way, good behavior is rewarded, but not required.

Something like that should be the case for user sessions, although there are exceptions (screen, tmux, nohup), and SIGKILL might be excessive. The upstream bug mentioned a few other processes that remained visible under session-status, and I myself have seen similar behavior from at-spi2-core (haven't determined yet if a bug report is in order for that one).

We're going to be fighting a losing battle if every single desktop background service in Ubuntu has to do things correctly in order to avoid keeping the session open after logout. There needs to be a failsafe of some kind.