libvirt-bin upstart job considers service "started" before it is ready
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
uvtool |
Fix Released
|
High
|
Unassigned | ||
libvirt (Ubuntu) |
Won't Fix
|
Undecided
|
Unassigned | ||
uvtool (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
Steps to reproduce:
1. This is a race condition. I observed it without needing this step, but to ensure that it reproduces, you can patch a sleep into libvirt. See reproduce.patch attachment.
2. apt-get install libvirt-bin
Actual results:
Note that /var/run/
Expected results:
The daemon should be ready and answering queries at the time that the libvirt-bin package postinst has completed.
Impact:
It seems that libvirt's postinst finishes before the socket is available, and uvtool's postinst assumes that the socket is available. This causes a race. Workaround: "apt-get -f install".
Perhaps the libvirt postinst should wait for the socket to be available, or our postinst should wait. I'm not sure which.
Log:
Setting up ubuntu-
error: failed to connect to the hypervisor
error: Failed to connect socket to '/var/run/
error: failed to connect to the hypervisor
error: Failed to connect socket to '/var/run/
Failed to define libvirt pool 'ubuntu-cloud'
dpkg: error processing ubuntu-
subprocess installed post-installation script returned error exit status 1
Processing triggers for libc-bin ...
Errors were encountered while processing:
ubuntu-
E: Sub-process /usr/bin/dpkg returned an error code (1)
ubuntu@
sudo: unable to resolve host ubuntu-cloud-saucy
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 76 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Setting up ubuntu-
Pool ubuntu-cloud defined from /tmp/tmp.0R9GjioWBq
Pool ubuntu-cloud marked as autostarted
Pool ubuntu-cloud started
Changed in uvtool: | |
importance: | Undecided → High |
summary: |
- postinst fails to connect to libvirt + libvirt-bin upstart job considers service "started" when it is not |
tags: | added: patch |
Root cause analysis:
libvirtd creates and starts listening on the socket after forking to daemonize. However, it also ensures that the original process only exits after the daemon process has started to listen on the socket (using a pipe to signal readiness internally).
In the Sys V init case, this means that the init.d script would not exit until the daemon is ready.
In the Upstart case, it seems to me that Upstart's documented "expect daemon" behaviour means that Upstart treats the daemon as started as soon as the second (daemon) fork occurs, and there is no provision to wait() on the original process.