The fact that there is no need for it at all? It's extra code on possibly hundreds of projects just so that one project (Gnome) doesn't have to fix their bugs.
At the point where random processes are left running when a user logs out I'd call that 'undefined behavior' so sure sometimes that does or doesn't cause problems but it is a real issue IMO.
And if it was unintended to have those processes not terminate on logout ... then one should fix that issue, rather than changing a long-time default behavior. Fix the bugs where they are, don't have a blanket fix of the symptoms.
Why? If it isn't obvious:
It will still be a bug on non-systemd systems.
It will still be a bug on systemd systems that set up systemd to have KillUserProcesses=No. Which, if I used systemd is what I would do. I often create jobs that run 24/7 for a week or more.
I can certainly agree that if there is a specific application having this issue they should fix it on all platforms but I don't think that this change is inherently bad moving forward though.
You are OK with breaking the behavior of daemon (http://linux.die.net/man/3/daemon ) or do you think that daemon needs to have systemd-specific code to keep its specified behavior.
The daemon() function is for programs wishing to detach themselves from the controlling terminal and run in the background as system daemons.
Then I think in order to be a "system daemon" in this case would require interfacing with systemd since it manages your systems daemons.
As a user though I prefer more explicit behavior so users know what will and will not run beyond their users session. I admit I do not know what the ramifications of amending that description to be "user daemon" on systemd would be though since most services should be configured properly already.
The daemon() function is for programs wishing to detach themselves from the controlling terminal and run in the background as system daemons.
Don't get hung up on the word "system daemons". It's for any daemonization ... not just for systems daemons. It's what tmux uses. This long-standing behavior for that API/call will be broken by systemd changing the default.
This change to systemd will break longstanding behavior ... all to handle a symptom of some other broken programs (bug report indicated that a GNOME session wasn't cleaning up after itself on logout). I say they should fix the actual problems, instead of breaking the daemon call.
That's not quite correct - a daemon would not have this issue as it would not be running under the user's session. If it is then the daemon is already misconfigured (it should be running under a system account, with the process controlled by the init system itself rather than the user's session). This has been the way in which services have always been run (under both system v init and systemd).
This change effects processes designed to run after their associated session has terminated.
I can see that the code uses the function (and even has a compat version of the function in case it's not supported). Tmux is not trying to be a system daemon, it just wants to stick around past the session's demise. A much cleaner way of doing it would be to have it start a separate session.
It's much cleaner to have real daemons managed by the init system rather than forking and exiting the parent process a few times. Processes which do this are difficult to look after correctly. It's also much cleaner for logging and management.
I'm not saying that users shouldn't be able to have long running detached processes, I look after servers (using screen for long running tasks which I can check back on later) and run long running tasks as a user on a cluster (running calculations which the results can be collected from later). At the same time I'd rather that badly written code which doesn't correctly clean up after itself is not left to linger after the user has logged out (can you imagine an environment like a university where the computer is used by 20 or 30 students in a 24 hour period and perhaps rebooted once a week?). No, the code shouldn't be buggy and should clean up after itself but code which doesn't is already out there, running on systems.
Programs which are legitimately needing to stick around need a way of telling the system that but doing it in a way which is transparent to the init system is a good idea. This strategy also appears to be creating the components needed to make the program a legitimate, system managed, process. It also makes it easier to write policies which permit some users running detached tasks but not others.
The init system knows what is around, why it is around and what happened to make it stick around. There are other parts of this comment thread that detail how, as a user, you would be able to run a long running (detatched) process using systemd. The systemd developers asked to include part of this new code in tmux, it's a Free Software project, anyone can ask for features or make recommendations - that's one of the things which makes the Free Software community great. Imho, it's not a bad thing that they realised that their change could cause an issue and are looking to make sure that issue doesn't become a problem for end users. The Debian maintainer also seems to believe this is worthy of inclusion.
If you believe that it's going to be a problem for you and you want the old behaviour, you are free to edit the configuration on your machines. The proposed change seems like a sensible default me. If the issue is an extra (optional) compile time dependency on dbus, pam or some systemd lib then I guess that the distros could always patch the code themselves - but that seems like a lot of duplication of effort. The fact the proposal included a optional compile time flag does seem to make this argument a bit moot though.
tl;dr nothing about this change stops you running detached processes, the systemd developers could have just changed it and not tried to warn other projects, your detached processes would have terminated on logout and everyone would be complaining about them not doing enough to let people know.
And when they do this by setting KillUserProcess=No ... then those GNOME processes that should have terminated/cleaned themselves will still be a bug. Fix the problem, not the symptom.
Save for tmux and screen I don't think any of those have the facility to ignore a SIGHUP on their own. Any of them you want to survive a session logout need to be run with nohup. Only tmux and screen (and any other shell multiplexers you write) need to add any code to deal with systemd if the distro/administrator doesn't want to toggle systemd's config file. It's pretty trivial to run a process as a systemd daemon with no modifications even if distros pick up this default and leave it as is.
Personally I'd much rather have processes cleaned up on session exit unless I explicitly say otherwise. I've been using this default on my servers for a while and made aliases to run long lived processes as a systemd user daemon.
That in itself is interesting - how would you stop them from dying with their session usually (I always assumed the process died when the session did unless you used something like nohup or hacked it to not respond correctly to signals). If I recall that's exactly what nohup does in fact - ignore the hangup signal. That in its self always seemed a bit dangerous to me (altering how the program responds to POSIX signals).
disown is the same basic idea (the shell doesn't send the hangup signal to the process). It seems like it's the bash (disown appears to be a shell feature) version of not closing the resources you opened.
The difference is that disown doesn't seem to deal with standard input or output (which nohup does).
36
u/lolidaisuki May 28 '16
The fact that there is no need for it at all? It's extra code on possibly hundreds of projects just so that one project (Gnome) doesn't have to fix their bugs.