Will you plan to support s6-fghack for forking services?
Instead of the 66-ns -o unshare=pid ? Wherever it works?
Because s6-fghack can find out if the forking service has stopped... and stops itself in a similar in order to convey that to s6-supervise.
Yes, 66-ns -o unshare=pid works , but why not support s6-fghack if it works, as it can detect the errors and pass the error codes with more reliability to s6-supervise?
Let 66-ns -o unshare=pid be a last resort.
A Forking= key in the frontend... with values false|no [default], true|yes [for most forking services], uncatchable [which fork and close the file descriptors passed by s6-fghack, in which case 66-ns -o unshare=pid is the only resort...]
pidfiles are a theoretical race condition, and the s6 developer will never support that method.
If pidfiles need to be supported in 66 [mostly not with s6-fghack], you'll need to have your own tool, say, 66-pidsupervise, or 66-execute itself, running under s6-supervise and doing a similar job.
