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

Bug#733452: init system daemon readiness protocol



]] Ian Jackson 

> (Sorry, 2nd copy here because I missed up the change of To field in
> the previous one.)
> 
> cameron writes ("Re: Bug#733452: init system daemon readiness protocol"):
> > I was curious: why should SOCK_STREAM be used instead of SOCK_DGRAM in 
> > your proposed protocol?
> 
> SOCK_DGRAM sockets do not offer reliable delivery (at least, not on
> all unices).
> 
> > Have you seen Lennart Poettering's pastebin of a short daemon side 
> > implementation of that protocol: http://fpaste.org/64821/32737713/? It 
> > meets all your desired criteria, it is used in one init system already, 
> > and it is very extensible. Now that you know that systemd does not 
> > actually use SOCK_SEQPACKET, but SOCK_DGRAM, do you have any changes in 
> > opinion of the systemd approach?
> 
> I still think it would be simpler to pass the ready-connected socket
> (or whatever) to the daemon by inheritance, rather than having the
> daemon call socket() etc.
> 
> Do you know why in systemd it was done the way it was ?

Passing a file descriptor around reliably so it only ends up in the
right place is harder than doing the same with an environment variable.
Many daemons close all fds as part of the startup (this is documented as
best practice in quite a few places).

You also need to ensure that the fd given in the environment variable is
actually a valid file descriptior.  As per Lennart when asked on IRC:

17:16 < poettering> Mithrandir: anyway, the one line summary is that i
wanted this to be as simple as possible: it should suffice to place a
single sd_notify() at the appropriate place to make this work. With fd
passing that would not work, as you first have to make sure the passed
fd is not closed as part of setting up the execution environment during
daemon initialization.
17:17 < poettering> Mithrandir: sd_notify() as it stands now is really
really isolated. As long as the env var is there it doesn't need
anything else
17:17 < poettering> Mithrandir: what ian wants otoh is not so isolated,
you need to have a look at the entire daemon initialization and make
sure the fd is never closed or handled in its process, and then you
*also* need to look at the env var for it
17:17 < poettering> hope that makes sense

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


Reply to: