Bug#727708: init system discussion status
Russ Allbery <rra@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 (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: