Distributors ponder a systemd change

Posted Jun 8, 2016 8:48 UTC (Wed) by diegor (subscriber, #1967)
In reply to: Distributors ponder a systemd change by darwish
Parent article: Distributors ponder a systemd change

What you call boldness, I call carelessness. They introduce it not, for security or for cleaness. But just to put a (bad) fix to a problem in gnome. Without thinking to what happens, or asking for suggestion, (or just putting a warning).

And there is already a "clean the process after logout", it is called sighup. And it works. When i work on a remote server with ssh, I never see a process surviving the logout, that are not meant to do it.

Now, desktop is a different beast. Most of the problem come from program launching new process with nohup. That's happen because, they don't want the process be killed, when the father process is terminated. For example when you open an attachment from you email client, the viewer is a child of the email client. So when you close it, unix, as expected, clean all his child process. Because is cleaner, right? Do you see the problem now? Cleaning process is a desiderable thing, in theory, but the user complain, so every one start to mark the child process, as a process to not be cleaned out.

A better solution would be to have a "launcher" process for gui. Your email client instead of forking a new process, it can talk to the launcher and let it fork the new process. So when you logout, let the "launcher" clean his process, and let him kill them with fire, if it is really needed (without breaking everything else).

Distributors ponder a systemd change

Posted Jun 8, 2016 9:21 UTC (Wed) by matthias (subscriber, #94967) [Link] (4 responses)

sighup is not working (at least not all the times). Every program that has some cleanup to do before exiting is intercepting sighup (it has to). If the shutdown of the program fails, it is left running. I have seen such processes hanging around forever, possibly using 100% of CPU time.

Also what is the difference if systemd kills you process or the launcher process of the gui? There has to be an opt-out for screen, tmux and nohup in both cases.

Distributors ponder a systemd change

Posted Jun 8, 2016 11:56 UTC (Wed) by ras (subscriber, #33059) [Link] (3 responses)

> sighup is not working (at least not all the times).

I remember I have had a process going infinite on logout, but can't actually recall when - it was a long time ago. Infinite loops after getting a sighup must be easy to track down.

What I can recall happening recently is a kernel driver misbehaving. I go through the rmmod, modprobe dance. But instead of fixing it the processes using the driver hangs on some unbreakable kernel lock, and the eventual kill -9 is a complete waste of time. The only way out is a reboot of a production machine. I gather race conditions during module removal are unavoidable, and regardless there always seems to be more of them. If the systemd or gnome guys have a fix for this, no matter how bad, I promise to call it a thing of beauty.

But using this sledge hammer to cure a simple infinite loop bug, and break backward compatibility - sorry, no.

Distributors ponder a systemd change

Posted Jun 8, 2016 13:51 UTC (Wed) by bronson (subscriber, #4806) [Link] (1 responses)

Since processes surviving logout has been a problem for decades, it seems like the infinite loops are not so easy to track down after all?

Distributors ponder a systemd change

Posted Jun 8, 2016 22:03 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

Not if they happen in a subset of conditions. For example, if you have an encrypted home directory that is lazily unmounted after the logout.

Distributors ponder a systemd change

Posted Jun 8, 2016 14:51 UTC (Wed) by diegor (subscriber, #1967) [Link]

But if not even kill -9 can kill it, systemd can't kill it too.

Usually process for which kernel is serving a system call, can not be interrupted, until kernel have finished.

Distributors ponder a systemd change

Posted Jun 8, 2016 11:23 UTC (Wed) by niner (subscriber, #26151) [Link] (1 responses)

If SIGHUP worked that well, we wouldn't currently have almost 100 useless processes from previous sessions on our development server and I wouldn't have to reach for killall from time to time to clean up.

Distributors ponder a systemd change

Posted Jun 10, 2016 22:23 UTC (Fri) by xtifr (guest, #143) [Link]

So you have a bunch of programs with bugs (don't respond properly to SIGHUP), and this will merely hide those bugs!

Wouldn't it be better in the long run to have those bugs fixed? And wouldn't it be easier to fix them if the bugs weren't hidden?

In the case of the various GNOME-specific processes which are supposed to be shared between sessions and thus shouldn't necessarily just die whenever one session shuts down (so they can't just die on SIGHUP), they should, instead, keep track of how many sessions they've been attached to (probably via dbus or something), and kill themselves when the last session goes away.

And this kill-everything option could remain an option for people like you who have buggy processes which don't shut themselves down when they should (either when receiving SIGHUP or when their last session goes away). I'm fine with that. But making it a default for everyone, and forcing every program that might be intended to survive beyond logout to be modified just for systemd-based systems seems like the wrong choice.