>Is there any appetite for providing a way for ./run to know the PID of its parent s6-supervise instance?
>
>This information allows the supervised child to know that it has been orphaned, and to tie its fate to its parent (eg PDEATHSIG https://stackoverflow.com/a/36945270).
>
>Using getppid(2) alone is not reliable because the child might have been orphaned between the fork(2) and getppid(2) calls.
getppid(2) is totally reliable.
If getppid() returns 1, it means the service has already been orphaned.
(Don't use subreapers without pid namespaces! they're useless and
break that property.)
So you can call getppid() in your ./run, exit if it's 1, and otherwise
record it and continue running with your prctl().
But from a systems designer point of view, I would advise *not* doing
that. s6 was designed to maximize the uptime of the service; it is
100% intentional that the service does not die if the supervisor dies.
Going out of your way to make the service die when the supervisor does
*decreases your uptime*, since now the uptime depends on two processes
being alive, not just one.
Normally you should never be worried about the supervisor dying. It
has been specifically written to be extremely stable. And, just in
case, if what you don't like is the log spam whenever the supervisor
happens to die and comes back up and the previous instance of the
service is still alive: the lock-fd file is meant to avoid that.
The point of supervision is to take burden *off* services. Services
should not care how they're launched, under a supervisor or not, in
what circumstances, etc. The need to add detection shenanigans and
special cases is a sign that you're probably not using the framework
as it was intended to be used.
--
Laurent
Received on Tue Jan 04 2022 - 18:08:17 CET