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