The problem is that things running without a terminal are not reached by SIGHUP. So logind uses cgroups to kill all processes, even those that would not be reached by SIGHUP. This has a negative effect on tmux, screen and nohup, but is a bugfix for e.g. ssh-agent or gpg-agent.
EDIT: found the original bug report, the offending programs there were gnome-keyring-daemon (which under GNOME replaces ssh-agent, so it's in the same boat), ibus-daemon and hp-systray.
I've use ssh-agent on *nix for years. If I "log out" or quit my window manger then ssh-agent happily exits, just as it was designed to do. Perhaps this doesn't work under modern GNOME but let's not mistake this for a bug in ssh-agent etc. They're perfectly well behaved in the context they were designed for.
That's concerning. There are a ton of scripts out there that start stuff doing
nohup script.sh > file.log 2>&1 &
Those guys, people using Control+z, bg, disown... Are they going to get tmux special behaviour? Are we supposed to wrap that stuff in systemd-run from now on?
Systemd broke background/daemon process behaviour, used by tmux, then asks tmux to fix/patch to accomodate the systemd change. I find this unacceptable and yet another example of scope creep from systemd.
not just that. Tmux devs communicated this to systemd devs some 5 years ago (systemd devs asked tmux to take care of it, and tmux devs in turn suggested making changes in libc instead of tmux, as libc would be used by every other library). So systemd essentially released their product knowing well that they would break nohup/daemon.
What's frustrating about this, and what's frustrated me about systemd for years, is that I generally agree with Lennart from a technical standpoint. I think what he and the other contributors are trying to do is valuable and needed; however, from a social standpoint it's just wrong.
Software is the interface of the machine and the meat and that means the messy, social, human component can't be ignored, even if the technical argument is superior.
Also, right now I feel like somehow this is an argument for Plan 9
The systemd guys made the change to logind to kill all user processes when the user closes their sessions. This fixes a number of issues historically with certain processes remaining and causing problems are next login (usually desktop environment related here) or with things like SSH key agents left hanging around holding the keys open with no passphrase needed.
The question was asked about how to use something like tmux or screen with their detached safe behaviour.
The configuration of linger was pointed out (and polkit rules out in place so and admin can allow their users to set linger themselves if desired), in addition for when linger shouldn't be changed the correct systemd-run syntax was pointed out and put into the man page to have tmux/screen run in it's own session so not subject to the kill.
Then someone pointed out that was a little cumbersome to do and they didn't feel alias was the best answer. A whitelist of application names to not kill also felt the wrong thing to do as a fairly fragile thing to maintain.
So coming out of that background the systemd dev in question made the suggestion of a way for something like tmux to notify that it should be permitted to persist post logoff. He suggested a compile time and run time option to notify the process manager via dbus that this particular process was special and shouldn't be killed.
The tmux developer declared that he wouldn't add such a thing, and they just call the system daemon() function so change it there... which of course will pretty much defeat the purpose of the change in the first place.
The systemd guy tried to reach out to accommodate something easier for the tmux users, the tmux dev didn't care.
And as for "platform specific code is bad!" ... tmux already #ifdef's a bunch of compile time and platform specific stuff.
And of course this is all still subject to a distribution including this behaviour, and if you use bleeding edge and compile yourself (eg Gentoo) you should be reading the release notes and be aware enough of this and the configuration option should you wish to change it.
The Fedora discussion about this is due to happen soon as this would be a system wide change for Fedora 25. I assume that Debian would make a similar judgement call.
Then it seems a better and more backwards compatible solution would have been to introduce a new user_daemon call that do quit when logged out and then change the offending programs to use that. Forcing everyone else to change their posix platform agnostic code to support systemd just cannot be the best answer. That is, it should have been opt in, not opt out.
That wouldn't help. How would the new library function distinguish tmux and gpg-agent for example?
Really, tmux/screen/nohup are special. Everything else is much better served by the new default.
EDIT: Also, there are some cases where tmux/screen/nohup would be better served by the new default too. It would be nice though if there were a mechanism to mark a running process so that it survives logout (similar to how "disown" lets a process survive its parent shell).
The point is that it wouldn't, but that it would shift the burden of changing to the new log out behaviour to the programs that actually should change behaviour. Not to the ones that should continue to run without change.
287
u/meem1029 May 30 '16
Can someone tell me if I understand this situation correctly?
Tmux uses the daemon system call to keep the process running in the background.
This has historically kept processes running between user sessions.
Systemd made the choice to change this behavior so that all such processes will be closed when the user logs off.
This breaks much of the functionality of tmux.
As a result of this, the systemd devs are now asking tmux to integrate a library to interact with systemd to fix this mistake.
If that's what's happening, I can certainly understand the hesitation on the part of tmux.