Applet does not terminate at end of X desktop session

This bug has LP: 1871726 as a quasi-parent.

That one system-config-printer process shown in session-status is deceptive; ps(1) shows a much larger number of processes still remaining from the login session. When the s-c-p process goes away, however, all the others follow. The impact of this issue, then, is not limited to a single lingering process.

This bug was reported three years ago in Debian:

    https://bugs.debian.org/863227

Reported upstream as

https://github.com/OpenPrinting/system-config-printer/issues/175

The upstream author has tested and found out that the problem only occurs with lightdm and not with gdm as desktop manager, especially the ones showing the problem are sddm, kdm, lightdm and the ones not showing the problem are gdm and lxdm. Adding desktop manager tasks ...

See this comment and following:

https://github.com/OpenPrinting/system-config-printer/issues/175#issuecomment-627771765

I did not find the package which contains kdm (probably the desktop manager of KDE), if someone could add the appropriate task for this one would be great.

Added systemd task because of the this comment on the upstream but by the original poster of this Ubuntu bug report:

https://github.com/OpenPrinting/system-config-printer/issues/175#issuecomment-627870677

Per https://github.com/OpenPrinting/system-config-printer/issues/175#issuecomment-627964091 there is a possible solution even with how systemd works today, marking as Invalid for systemd.

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.