[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: init system daemon readiness protocol


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: