Russ Allbery wrote: > 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.
It's an interesting idea as an exercise, but I can't think of a single advantage to using this mechanism in practice, compared to just fixing the daemon to do systemd-compatible startup notification (or better yet socket activation). But as long as we're trying to come up with ways to make an unmodified upstart-compatible daemon work that you'd never actually use in production, what about an LD_PRELOAD library that hooks the raise function, passes through all calls other than SIGSTOP, and changes the first call to raise(SIGSTOP) into a call to sd_notify? Still seems far uglier than just patching the daemon, but as an exercise that actually does seem cleaner than introducing a second process. - Josh Triplett -- 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/20140105070553.GA15198@leaf
