Description of problem: It would be nice when systemd supports the upstart like SIGSTOP method to signal when a daemon is ready. E.g.: 1. .service contains 'Type=sigstop' or similar entry and executes daemon with a special cmdline option 2. daemon initializes itself (e.g. goes into chroot, drops permissions) 3. daemon calls 'raise(SIGSTOP)' 4. systemd catches the SIGSTOP, sends SIGCONT and marks the service as ready Although there exists already a more powerful sd_notify(3) function, this is often not applicable because: * it is complicated (extra sources + ./configure checks vs. a simple 'raise(SIGSTOP)') * does not work when daemon goes into a chroot() at step 2 * requires additional SELinux permissions for working on the socket
SIGSTOP is a mechanism for stopping processes, not for notifying service readiness. We shouldn't attempt to overload OS functionality like this, as SIGSTOP might happen for it's real purpose too. I also fail to see in which way: #include <signal.h> ... raise(SIGSTOP); ... was any simpler than this: #include <systemd/sd-daemon.h> ... sd_notify("READY=1"); ... And people can just use the .pc file to add libsystemd-daemon to their build, so that's dead easy. The chroot() issue is a real issue, but easily fixed, by simply using an abstract namespace socket for this, which the spec explicitly allows, and which we actually used before. I have noq added a todo list item to revert back to using an abstract namespace socket for this. Another big problem with raise(SIGSTOP) is that if done on an init system that can't handle it will result in a freeze. OTOH sd_notify() handles this gracefully and just becomes a NOP. But anyway, we really shouldn't overload OS functionality like this anyway. SIGSTOP has a useful meaning already, and use for anything else would conflict with this.