On 13/07/2015 22:47, Avery Payne wrote:
> My Unix internals knowledge is slightly higher than zero. Perhaps a
> decimal point and a digit. So this - specifically process groups -
> is unfamiliar territory for me. Learn-as-I-go, and all that.
Then you definitely don't want to focus on the details of sessions and
process groups right now. The only thing in Unix I can think of that you
want to focus *even less* on is terminals.
The only things you need to know are these:
- A session is a "family" of processes: all processes in the same session
are, in a way, related. Process groups are cliques inside this family.
- The setsid() system call makes the current process run in a new session,
if it's not already a process group leader (i.e. head of a clique). In
other words, a process says "screw you, suckers" to all its relatives,
slams the door and goes and starts its own family. I like those processes.
> My limited understanding was that it would through means not known to me
> cause all child processes to refer back to a common ancestor process
> (provide that the process is still around, which implies it is the
> parent of all others beneath it). This is probably a completely
> erroneous assumption on my part.
It's more complicated than that. If you really want to know, the definitions
are at:
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_292
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_339
and the interesting functions are setpgrp() and setsid():
http://pubs.opengroup.org/onlinepubs/9699919799/functions/setpgrp.html
http://pubs.opengroup.org/onlinepubs/9699919799/functions/setsid.html
but I really wouldn't do that without a medium-to-solid grasp on the
rest of Unix (save terminals), some Zen training, too much time on your
hands, and aspirin.
> That being said, for whatever reason, using pgrphack fixes a problem
> I had with mingetty as built against Debian 8. Without pgrphack,
> mingetty would not function; the addition of pgrphack causes it to
> work correctly, and no other changes were needed.
I would say this has to do with the supervision suite you were using.
mingetty *needs to* run as a session leader, because it allocates a
terminal which becomes the controlling terminal for a whole session,
and it can only do that as a session leader.
But it is good practice for a supervisor to automatically start its
daemon as a session leader. (fork(), and in the child setsid() then
execve()), because running the daemon in the same session as the
supervisor makes little sense: daemons want their independence.
(There are a few quirky cases where running the daemon in the same
session does make sense, that's why s6-supervise recognizes a
"nosetsid" configuration file in a service directory; but the default
should be to setsid().)
And so, if you had problems with mingetty that you solved by running
it under pgrphack, I'd say that your supervision suite did not run it
in a new session.
daemontools' supervise doesn't setsid() by default.
runsv doesn't setsid() by default. runsv is actually made a session
leader by runsvdir, and runs the daemon and its logger in the same
session. That makes sense from the supervisor's standpoint, but not
from the daemon's standpoint.
I'm not sure what perpd does. There's no mention of sessions in the
documentation.
Bottom line: use s6, which does the right thing. :P
> Also, thanks for pointing out the use of s6-setsid, which of course
> should be present in the use-s6 script when remapping pgrphack. I'll
> get it fixed as soon as I can.
No problem. s6-supervise setsid()s by default anyway, so it should
not be necessary to use s6-setsid or any other pgrphack-like tool in
run scripts.
--
Laurent
Received on Mon Jul 13 2015 - 23:12:21 UTC