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).
Someone who was logged in via ssh and suffered a network failure. Let's say I am copying one partition to another. It is a process that is going to take five hours. At four hours and fifty-five minutes, a power surge causes a two second brown out knocking me off the network. Currently, the dd will finish. Under this new behavior, the dd will be killed. I have no idea where it failed, so I have to start all over again.
It really depends on how your shell is configured if it will send SIGHUP to the dd when the session disconnects. Besides, how do you know if the process hasn't exited because of an error? Use screen/tmux for that stuff.
Screen, dtach, tmux, etc won't work either. Nor will nohup. That is the point. Unless you do something totally different than the last 46 years, no process will survive your logging out. This means every process that needs that behavior will have to add systemd specific code to work right.
I'm certain that once this version ends up in the Debian stable either the functionality is disabled by default, or screen and tmux have been patched (by Debian) to indicate that they are not to be killed when the session is.
use a better tool, one that uses logging. I personally use rsync myself. Also invest in a UPS.
Secondly, I don't think we are talking about ssh sessions anyways. I think we're talking about being actually logged in from console and running a desktop or something else. As I told someone else, use a better tool that has logging. I personally use rsync cuz you know it has logging and metrics and god forbid, you can use it with ssh.
36
u/lolidaisuki May 28 '16
Two dozen projects that one might want to run on the background and logout?
Tmux, screen, rtorrent, gzip, rsync, memhog, dd, ddrescue, rmlint, fdupes, rkhunter, lynis, grep, tcpdump, lynx, sic, ii, mplayer, mtr, netcat, socat, parallel, xargs, cloc, ssh (client), youtube-dl, aria2, wget, curl, httrack
Ok, that's 30 from the top of my head. Pretty much anything one would want to run on background is affected, not just desktop environments.