Laurent,
Thanks for the quick reply.
If getppid() returns 1, it means the service has already been orphaned.
I don't think that's guaranteed by Posix.
Apparently another data point:
https://gist.github.com/gsauthof/8c8406748e536887c45ec14b2e476cbc
Normally you should never be worried about the supervisor dying. ...
the lock-fd file is meant to avoid that
What are your thoughts for this specific scenario? My understanding is
that the supervisor would be relaunched, and another instance of the
service would be started. I'd like to avoid/deal with the situation of
the evil-twin service instance.
An optional regular file named lock-fd.
Oh ... it seems I missed this part of the documentation.
Earl
On , Laurent Bercot wrote:
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://stackoverflowcom/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
