"expect daemon" and daemons being ready to serve requests

Dmitrijs Ledkovs xnox at ubuntu.com
Tue Oct 1 16:25:59 UTC 2013


On 1 October 2013 17:21, Robie Basak <robie.basak at ubuntu.com> wrote:
> Currently, when libvirtd is started (process A) with "-d" to daemonize,
> it:
>   1) Forks process B.
>   2) Forks process C (from B).
>   3) Binds a Unix socket (in C).
>   4) Listens on a Unix socket (in C).
>   5) Causes process A to exit (using an internal pipe to communicate
>      between processes C and A).
>
> libvirtd's packaging in Ubuntu (libvirt-bin) currently uses an upstart
> script that calls "libvirtd -d" and uses "expect daemon".
>
> Upstart detects that the daemon has started at step 2 above. This
> creates a race: libvirt-bin.postinst finishes before step 4, and so a
> subsequent uvtool.postinst that depends on libvirt-bin fails when it
> tries to set up a libvirt volume storage pool and cannot connect to
> libvirtd.
>
> I have other solutions in the bug: making uvtool.postinst explicitly
> wait for the Unix socket to appear, and switching to "expect stop".
>
> But libvirtd's behaviour seems reasonable to me. And in the Sys V world,
> an init.d script would only exit after step 5 above, so there would be
> no race. So it feels bad to introduce the SIGSTOP hack into libvirt in
> order to solve this problem.
>
> Could upstart wait() on process A before concluding that the service is
> started, in the case of "expect daemon" (and also, presumably, "expect
> fork")? Would changing upstart's behaviour to do this cause any problems or
> regressions that I haven't thought of?
>
> libvirt bug: https://launchpad.net/bugs/1228210
>

There is a plan to track EXITED, thus $ expect daemon, would then mean
that process A & B should exit to satisfy "expect daemon" condition.
I believe this will resolve above race, but it is not as of yet implemented.

Regards,

Dmitrijs.



More information about the upstart-devel mailing list