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
>
Received on Tue Jan 04 2022 - 18:32:12 CET