Distributors ponder a systemd change

Posted Jun 8, 2016 22:31 UTC (Wed) by flussence (guest, #85566)
Parent article: Distributors ponder a systemd change

I don't entirely understand the full story behind all this, so I'll assume good faith on the part of the systemd developers.

This to me looks like a workaround for Someone Else's badly-engineered software not exiting in a timely manner. I'm not even sure who's to blame for that software, but it must be pretty awful — and widespread — to elicit this kind of nuclear response. It sets an unpleasant precedent in that people writing long-lived processes, who've done nothing wrong, now have an extra non-standard codepath to deal with alongside Android, Windows and OS X.

I thought systemd's whole mission was about pulling up the weeds, not making excuses to keep them there. If the upstream at fault won't cooperate and fix their bugs, why not replace them with code owned by someone less obstinate? That seems objectively better than fracturing the Linux ecosystem to appease them.

Distributors ponder a systemd change

Posted Jun 9, 2016 6:05 UTC (Thu) by matthias (subscriber, #94967) [Link]

Because it is impossible to establish that every software installed on the system is bugfree.

Most software will not need an extra codepath.
- Daemons should be started as daemons. Sytemd will not kill them.
- screen/tmux and the like should register their sessions with PAM. PAM will take care that systemd does not kill. This should be done anyway to manage processes as ssh-agent. Without proper session management they will vanish when the user is logged out even if they are still needed from inside screen.
- Instead of calling nohup you will need to use systemd-run.

I have not seen any other program so far that is affected. I do not claim that there are none, but there seem to be only very few. All the people calling this a big problem have only mentioned these few examples. If this really is a problem, then I would like to see a few more examples.

Distributors ponder a systemd change

Posted Jun 9, 2016 10:11 UTC (Thu) by dunlapg (guest, #57764) [Link]

I found this an interesting summary of how this became a "thing":

http://lwn.net/Articles/690299/

If it's accurate, it's makes it much less justifiable.

Distributors ponder a systemd change

Posted Jun 9, 2016 14:43 UTC (Thu) by ksandstr (guest, #60862) [Link] (2 responses)

The big question is: if this is indeed required by GNOME, KDE, etc. for their ill-behaved spawn, why is it not those desktop environments that set a flag in systemd to have their descendants killed? Why is it the case that screen, tmux, et al. must depend on systemd to avoid that fate?

Per Hanlon's razor, either systemd is again breaking well-working, well-defined userspace (i.e. screen, tmux, nohup'd processes, etc.) just for the dependency-tree influence it yields, or they simply don't know any better than to do a stupid thing and then imperiously double down on it.

Distributors ponder a systemd change

Posted Jun 9, 2016 15:18 UTC (Thu) by johannbg (guest, #65743) [Link] (1 responses)

"well-defined userspace"

Well defined by who?

It's always so that the programs that misbehaving are the ones that need fixing so establish first whether those programs you listed have been technically correctly implemented or are technically misbehaving.

Peoples "feelings", "history", "workflows", "religion" and what not are entirely irrelevant in these types of matter.

So answer this is systemd technically doing the correct thing.

If the answer is yes it's doing the technical right thing then what breaks should be fixed elsewhere.
if the answer is no it's not doing the technical correct thing then what breaks should be fixed in systemd.

It's as simple as that.

Distributors ponder a systemd change

Posted Jun 9, 2016 17:00 UTC (Thu) by ksandstr (guest, #60862) [Link]

> Well defined by who?

By practice across multiple independent implementations of Unix. Call it a silent standard.