Hi Robie, On Tue, Oct 01, 2013 at 05:21:03PM +0100, Robie Basak 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 Indeed, as you may have gleaned from the IRC discussion, that's exactly the plan. This is bug #530779 in upstart. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ [email protected] [email protected]
signature.asc
Description: Digital signature
-- upstart-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/upstart-devel
