On 1 October 2013 17:21, Robie Basak <[email protected]> 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. -- upstart-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/upstart-devel
