Russ Allbery <r...@debian.org> writes: > This, sadly, is slightly harder, since you can't use this hack:
>>> The wrapper could fork and then exec the daemon in the *parent*, and >>> have the *child* listen for the notification message and then >>> kill(SIGSTOP) its parent and immediately exit. I wonder if that would >>> actually work.... > because the child can't waitpid its parent and get notified when the > parent stops. So the compatibility wrapper would have to stick around > for the lifetime of the daemon and pass signals and the like, and I'm > not sure what gotchas would be involved in that. But it's probably > doable. (Why can't I have brainstorms *while* I'm writing mail instead of subjecting everyone to more mail?) Oh, hm, actually... the systemd notification protocol allows you to tell systemd what the actual PID of the process to manage is, using the MAINPID variable. So I think you actually could write a wrapper that starts the actual daemon as a child, waits for it to stop using waitpid, sends it SIGCONT, tells systemd that it's ready along with passing MAINPID pointing to the child process, and then exits. I'd have to try that to see if it would actually work, but I bet it would, and it would be a fairly easy program to write since you can just use libsystemd-daemon and don't have to write any of the socket code. There are probably still some gotchas to sort out, such as signals received before the child process signals readiness and how to handle them, but I think that's all doable. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874n5j84gk....@windlord.stanford.edu