Ian Jackson <[email protected]> writes: > No. It's in the context of daemons which are written (well, have been > modified) _not_ to fork. They just run as children of the supervisor. > It's a way for a daemon to signal that it is ready.
Oh, I see, I misunderstood the context. (Although correct me if I'm wrong, but it sounded like this also worked for forking daemons.) > systemd supports the non-forking daemon too. Only, instead of > raise(SIGSTOP) the daemon has to fetch an AF_UNIX socket name from an > environment variable, connect to it, and send a special message with > socket credentials attached. I assume this is functionality provided by the libsystemd-daemon library if you're willing to have a dependency on it? (Checks.) Ah, yes, this is one of the things that sd_notify is for. SIGSTOP is simpler in that no build system changes are required. I can see the appeal. I do find the use of the signal for that purpose profoundly weird, though, and it's rather annoying that you have to add an environment variable or command-line option (and hence more complexity). The systemd approach adds a shared library dependency but reduces code complexity, since you can just make that call unconditionally and not care if you're running outside of a systemd environment (where it will just quietly do nothing). sd_notify has a few other rather neat features for daemons that are systemd-aware, none of which are horribly important but which I will probably now start adding to some stuff since I think they're useful. The watchdog stuff in particular strikes me as similar to socket activation: something that requires a lot of upstream cooperation to use well, but which could really improve the state of play for daemon management when used well. -- Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
