Re: init system daemon readiness protocol
Hi,
Jonathan de Boyne Pollard:
> Readiness is not something that any service manager does reliably.
> There's just not the consistent mechanism for it, yet.
There probably never will be _one_ such mechanism. So your service manager
needs to implement most, if not all, of them.
systemd does exactly that -- socket activation, forking, writing the PID
file, its own protocol … did I miss any?
(I'm disregarding Upstart's SIGSTOP protocol here because IMHO it's broken
idea to signal a service's readiness by stopping it.)
> On the subject of readiness protocols: To see another already-established
> mechanism, perhaps avoid reinventing the wheel, and once again see the error
> of thinking that all this was only just thought of and entirely missing a
> whole history of tools development, see Laurent Bercot's fifodir mechanism
> (http://skarnet.org/software/s6/fifodir.html).
That's an interesting way to do publish-subscribe for short messages, but
I wouldn't apply it to a service manager. fifodir supports multiple
subscribers, a feature which you don't need in this case. It also doesn't
tell the reader which writer signalled it, information which you do need
(and get for free with a unix-domain socket; guess what systemd uses).
> On the subject of forks: It's interesting to observe that an EVFILT_PROC
> kevent() with NOTE_TRACK works reliably on FreeBSD/PC-BSD for tracking
> across forking daemons. This is not to say that forking is suddenly
> alright. But it gives the lie to any claim that daemontools-family service
> managers lose track when daemons fork.
Sure, but that doesn't exist on Linux.
Linux has the PR_SET_CHILD_SUBREAPER prctl() flag for keeping track of your
children -- introduced in 2012 by, surprise, Lennart.
--
-- Matthias Urlichs
Reply to: