Re: supervision-scripts 2015-06

From: Avery Payne <avery.p.payne_at_gmail.com>
Date: Mon, 13 Jul 2015 13:47:14 -0700

On 7/13/2015 2:00 AM, Laurent Bercot wrote:
>
> There's generally no use for the pgrphack/s6-setsid family of tools.
> The mistake of auto-backgrounding is common, so the fghack family
> of tools has easily identifiable uses, and it *is* a hack all right;
> but I've never seen a daemon misuse sessions and process groups,
> probably because those are one of the hairiest parts of Unix, and
> the least you hear about them, the better off you are. :)
>
> That's why I named s6-setsid as it is named: it's not a hack, it has
> rare but useful legit uses. It's unlikely you'll find such legit uses
> in a run script, however.
>
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. 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.

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. Based on what you're
saying, it implies that perhaps that my build (aka Debian's build) of
mingetty is broken? Or is there some low-level system requirement that
is being fulfilled, and it should be using pgrphack to begin with? Or
is it something else entirely?

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.
Received on Mon Jul 13 2015 - 20:47:14 UTC