[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.

[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

[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.