[cnvogel]

Another example:

    $ nohup ./long_running_process &
    $ logout

Previously: long running process continues running after you logout. Recent change in systemd: Process is reaped once your login session ends (depending on flags passed via ./configure when systemd was compiled, your distro of choice might not be affected right now).

You could interpret this as "breaking user-space", as it's contrary to long-running practice and user-expectations.

Or you could say that systemd is superior as it's reliably cleaning up unwanted lingering processes which may have bothered some before. And this is worth the hassle of explicitly running intended background processes via systemd-run(1), or adding code to e.g. tmux/screen doing the equivalent via the dbus-api.

[Steeeve]

Dagnabbit systemd! Thank you. You just solved a mysterious bug for me.

The whole purpose of nohup is to get your process to ignore your session ending. Why on earth systemd would up and decide that you didn't do that on purpose is beyond me.

When people say they hate systemd, it's precisely this kind of thing that we're talking about.

[icedchai]

Yes, this breaks something that has worked in Unix for 30+ years. Awful.

Systemd does give us extremely quick boot times, though! Too bad I generally don't reboot my Linux systems more than once a month.

[aexaey]

Indeed. systemd does boast respectable boot times (not as fast as hand-crafted shell script, but pretty good for a generic init).

On the other hand, error handling is pretty awful, especially during shutdown: Every now and then systemd would decide to give that one unresponsive sshd process a generous couple of minutes to shut down. Or will wait for a random filesystem to unmount itself for another 90 seconds. Sometimes outgoing systemd will lock up completely, until you do the magic ritual of pressing ctrl+alt+del 7 times within 2 seconds all while spinning around on your toes trice counter-clockwise and barking - to force "immediate" restart. Better yet - on special occasions this ritual devolves into farce: _after_ hammering ctrl+alt+del at machine gun rate it will print "rebooting now" and... lock up again. Until you hammer ctrl+alt+del again - only to see another empty "rebooting now" promise. SysRq would - of course - have no problem at all remounting filesystems ro and rebooting from this sad limbo.

[digi_owl]

The more one read the more one get flashbacks to the very Windows painpoints that made one adopt Linux in the first place...

[JdeBP]

I actually explained in detail how one could fix this, a year ago.

* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394#221

[MereInterest]

Absolutely. I cannot fathom why they thought that SIGKILL was appropriate instead of SIGHUP, even if they made the misused choice of considering it their responsibility at all.

[SwellJoe]

Here's a good explanation of the behavior, how to disable it, and why Fedora will be turning it back on in 26 (it's been off by default). https://fedoraproject.org/wiki/Changes/KillUserProcesses_by_...

[JdeBP]

No, that's just Zbigniew Jędrzejewski-Szmek's explanation repeated ... by Zbigniew Jędrzejewski-Szmek. I see from elsewhere on this page that you have unwisely bought into the idea promulgated on that page that Zbigniew Jędrzejewski-Szmek will "work with upstream authors and Fedora maintainers of programs like screen and tmux". No, xe won't; and demonstrably has not.

You need to look at some of the history here. Over the course of the past six years, Zbigniew Jędrzejewski-Szmek has twice cycled around the same loop, once in 2011 and once in 2016. Xe goes to the developers of tmux, tells them that tmux needs to change to be systemd specific, and the developers of tmux ask why systemd cannot provide the same semantics for interactive login sessions that have been employed for the past 38 years, with HUP for session hangup and TERM/KILL at system shutdown; or why at the very least xe does not talk to the C library people. Zbigniew Jędrzejewski-Szmek goes away, and then comes back about 5 years later with the exact same thing, unchanged.

Unfortunately, buying into that Fedora wiki page is as unwise as buying into the rather erroneous Freedesktop explanation of how version 2 cgroups work. You will note that the wiki page dates from around the same time as Zbigniew Jędrzejewski-Szmek's last cycle around the loop, which hit the headlines last year.

* https://news.ycombinator.com/item?id=11797075

* https://news.ycombinator.com/item?id=11797926

* https://news.ycombinator.com/item?id=11782364

[asymmetric]

Unrelated, but how come you've chosen to use the `xe` pronoun?

I couldn't find any mention of it in Zbigniew's blog.

[philh]

I've sometimes used it (or ve) in the past, because there's no good gender-neutral pronoun and I don't like to assume. (This is partly a politeness thing and partly an accuracy thing.)

Occasionally when I would do so, people would get confrontational about it, so I mostly stopped. But now that means I sometimes waste time trying to find someone's gender even though that's totally irrelevant, and/or try to work around needing a pronoun at all, and/or use "they" even though I don't like it. None of these solutions is great.

(Btw, I don't parse you as confrontational. Comments like yours wouldn't have bothered me.)

[Nadya]

From what I can tell, they use it for everyone.

[0] https://news.ycombinator.com/item?id=11785977

[1] https://news.ycombinator.com/item?id=14665518

[1] https://news.ycombinator.com/item?id=14580113

[2] https://news.ycombinator.com/item?id=14553959

[jwilk]

FWIW, "Zbigniew" is a male forename.

[MereInterest]

I don't get it. They say that the default should be to kill everything that doesn't opt out, but that already has been the default. SIGHUP gets sent to all processes, and those processes can explicitly ignore SIGHUP. In the new scheme, SIGKILL gets sent to all processes, except if the process has requested not to be killed through systemd's API. A misbehaving program in the old scheme would still be misbehaving in the new scheme, so there is no added benefit.

[digi_owl]

The added "benefit" is that once more systemd gets to define behavior.

Systemd is not about building refinements on unix, it is about turning Linux into something like OSX or Android. a OS that use unix semantics only for bootstrapping convenience.

Effectively they are turning the Linux kernel into a convenient source of drivers, but beyond that could not care one bit about unix.

I really wish i could find the interview again where it mentions that Poettering in the past have advocated throwing away the chapters on unix programming from one of the seminal works on programming unix and Linux.

[MereInterest]

That's what I'm getting, but I'm trying to at least give systemd advocates the benefit of the doubt. When I have the time and energy, it can be a good use of time to poke at people with questions.