process. Normally it will cause the child to exit followed by the
termination of the supervisor after removing the pidfile.
This looks like desirable behavior, because termination of a
supervisor usually supposes termination of its charge. Also it will
fix the issue with stale pid files after reboot due to init kills a
supervisor before its child exits.
MFC after: 2 weeks
not to leak the descriptor after exec(3). This raises the issue for
daemon(3) of the pidfile lock to be lost when the child process
executes.
To solve this and also to have the pidfile cleaned up when the program
exits, if a pidfile is specified, spawn a child to exec the command
and wait in the parent keeping the pidfile locked until the child
process exits and remove the file.
Reported by: Andrey Zonov <andrey zonov org>
Suggested by: pjd
Reviewed by: pjd
MFC after: 2 weeks
better to leave the pidfile open where it was. Add a note to the
man page describing pidfile strategies to use if the daemon is to
be run as a user other than root.
so pid files can be written in /var/run when started as root.
I do not expect this to cause any security issues, but if anyone objects
it could be easily reverted.
PR: bin/159568
MFC after: 4 weeks
