"expect daemon" and daemons being ready to serve requests

[Robie Basak]

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

Thanks,

Robie