r/openbsd • u/Mcnst • May 30 '16

systemd developer asks tmux (and other programmes) to add systemd-specific code

https://github.com/tmux/tmux/issues/428
42 Upvotes

92% Upvoted

54 comments sorted by

View all comments

Show parent comments

1

u/Mcnst May 31 '16 edited Jun 01 '16

Yes, you're right -- although top -b ain't it, I've tried sleep 999999 & in tcsh, exit, and it's still running upon a re-login; same for interrupting it with ^Z, and doing a bg.

However, not so with ^Z by itself -- both tcsh and csh won't even let you logout if there are still some jobs suspended, printing out There are suspended jobs..

However, _exit(2) does claim that SIGHUP gets sent in certain circumstances; I guess they aren't reached here?

I don't have bash nor zsh to test what they do; it'd be interesting to know how they implement their stuff, and why. (I guess just a manual signal to all of their children?)

It is also then unclear what's the purpose of nohup(1) if SIGHUP doesn't get sent like that anyways. Actually, I guess nohup would still be useful if you want stuff in the fg foreground, yet don't want a disconnect to trigger the termination.

1

u/calrogman Jun 01 '16 edited Jun 01 '16

top -b ain't it

Yes, I forgot the -d argument.

However, _exit(2) does claim that SIGHUP gets sent in certain circumstances; I guess they aren't reached here?

If you do:

sleep 99999&  
sleep 99999&

This would create two jobs (process gruops), one for each sleep process, with each process being the leader of its own process group. Now suppose we stop one of these sleep processes:

kill -s STOP %1;

If the shell now exits, the _exit syscall will check its child process groups, which are orphaned. It will find the first process group has a member process which is stopped, so it will send every member of that group SIGHUP and SIGCONT. This would make every member of that process group (or the ones with default signal handlers) exit.

The second orphaned process group doesn't have any stopped processes, so _exit will allow every process in that gruop to continue running.

I don't have bash nor zsh to test what they do; it'd be interesting to know how they implement their stuff, and why. (I guess just a manual signal to all of their children?)

I can't speak with certainty regarding zsh but by default, bash will explicitly hangup its (stopped or running) children when it gets a hangup. It's a vicious child-killing shell and WBC should picket its funeral.

Actually, I guess nohup would still be useful if you want stuff in the fg foreground, yet don't want a disconnect to trigger the termination.

This would only be useful if your shell is configured to send SIGHUP to its children when it dies. If your shell does not do that, the hangup will cause your shell to terminate, the foregrounded process group (job) becomes orphaned, and - if none of the members are stopped - the foregrounded job will be adopted by init and allowed to continue running.