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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141025070223.gl24...@smurf.noris.de
