SIGHUP for "session has gone away", not SIGTERM/SIGKILL

Posted Jun 9, 2016 8:52 UTC (Thu) by matthias (subscriber, #94967)
In reply to: SIGHUP for "session has gone away", not SIGTERM/SIGKILL by ewen
Parent article: Distributors ponder a systemd change

case 3 is not necessarily a background process. It is every foreground process that needs to save data before exiting. You have to intercept SIGHUP as otherwise you cannot do anything but the process just dies. We should not rely on the fact that every program is correct.

The problem is that there are many cases, where a program has to intercept SIGHUP despite the program does not want to survive the session.

I agree fully that not every long running program should be systemd/session aware. The overwhelming majority of daemons just work, as they are started as daemons. If a user wants a special program to survive, the user should use systemd-run instead of nohup in a systemd setting. No need to change the program. The only programs needing changes are programs starting new sessions themselves (screen/tmux if you have other examples I am still waiting to here of them). These program should register a PAM session (not only for not being killed but also for proper management of associated processes like ssh-agent).

SIGHUP for "session has gone away", not SIGTERM/SIGKILL

Posted Jun 9, 2016 9:22 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

> the user should use systemd-run instead of nohup
Why? Just wrap/replace nohup with a script that simply invokes systemd-run.

Now, I'm quite partial to doing ctrl-Z/bg/disown dance to background unexpectedly long running jobs. E.g. I've started a build and it suddenly decided to download a new version of the docker image. Very slowly.

What would be the best equivalent in this case?

SIGHUP for "session has gone away", not SIGTERM/SIGKILL

Posted Jun 9, 2016 16:10 UTC (Thu) by cortana (subscriber, #24596) [Link] (1 responses)

Probably some kind of command that moves the disowned process (BTW, what's the difference between SIGSTOP, bg & exiting the shell, and SIGSTOP, bg, disown and exiting?) into its own scope unit. So a bit like 'systemd-run --scope --user' except with an existing process, rather than a new process that the user's systemd instance launched.

SIGHUP for "session has gone away", not SIGTERM/SIGKILL

Posted Jun 9, 2016 16:50 UTC (Thu) by viro (subscriber, #7872) [Link]

disown doesn't do anything to the process; it's a shell builtin that makes shell forget about that job, so that when it comes to shell-sent SIGHUP the job in question won't be affected.

The point is that back when you had launched that sucker you had no idea that it might need to be left to run - otherwise you would've used nohup to start it in the first place. And yes, there's a bunch of real-world situations where you really don't want to kill the damn thing and restart it from scratch, this time with nohup. Consider a case when what you expected to be a couple of hours of calculations you've started in ssh session on a big fast box at 1pm, only to discover at 11pm, when you get around to checking what it has produced that it's only ~2/3 way through. And you really have to disconnect the laptop you'd been using and leave. Killing that sucker and starting it with nohup means that results won't be there until 2pm tomorrow instead of waiting for you when you get back there in the morning. Sure, you ought to have added checkpointing, etc., but the whole problem is that it was supposed to be a one-off thing, and a reasonably quick one. I've no idea whether that's the scenario original poster had in mind, but it definitely does happen. disown can save you a lot of PITA in such case.

SIGHUP for "session has gone away", not SIGTERM/SIGKILL

Posted Jun 9, 2016 9:33 UTC (Thu) by ewen (subscriber, #4772) [Link]

If a foreground process is "resisting exiting" (ie, catching SIGHUP and doing something first), then (a) (almost by definition) that means that there is something user-visible which is obviously not exiting, (b) it is quite likely because the foreground process is trying to ask the user a question ("should I save your file first?") or similar and (c) thus probably *should* cause the exit of the session (eg, GUI desktop logout) to be deferred until a suitable answer can be achieved and state saved.

In the unlikely event that the *foreground* process still isn't behaving properly, and is blocking the session exit as a result, most desktops provide the user with tools to... persuade the process to exit. ("Force Quit" and the like -- which can do the SIGTERM/SIGKILL dance, at the user's explicit request, for the single buggy *foreground* process.)

AFAICT foreground processes were already doing the right thing; the change seems to have been caused solely by background "session-wide" processes (user dbus and the like) and the changes in how they worked.

FWIW, as I said earlier programs like screen/tmux/etc *are* starting new sessions, as that's been historically defined (by detaching from the controlling terminal, calling daemon(), etc). The discussion (in the tmux issue) about putting this "one init/session manager" specific behaviour in a commonly used place (eg, daemon()), so a simple recompile/relink picks it up seems more appropriate than requiring each "working for years" tool to suddenly have to add special code just to avoid being killed in one context. (Even PAM isn't necessarily used on all platforms that tools like screen, tmux, etc, use.)

And IMHO, breaking nohup and then saying "well you should use this other tool (systemd-run) instead just on systems that have this init system" is also unfortunate. It'd probably be better for distributions to install a nohup that continued to "do the right thing" so the background process was allowed to continue to run, keeping the long standing (25+ years I know about) semantics of "nohup".

Ewen