Description of problem: libvirtd fails to start if pid file exists but init script still says it started OK. Error is being logged to /var/log/messages. Version-Release number of selected component (if applicable): # rpm -qa|grep -i libvirt libvirt-debuginfo-0.5.1-2.fc10.i386 libvirt-python-0.5.1-2.fc10.i386 libvirt-0.5.1-2.fc10.i386 How reproducible: Always. Steps to Reproduce: 1. Make libvirtd crash or kill it. 2. Run "/etc/init.d/libvirtd start" and pay attention to start status: OK. 3. Check /var/log/messages for error about PID file already existing; libvirtd failed to start. Actual results: libvirtd fails to start if PID file already exists, but init script (/etc/init.d/libvirtd) still says it started OK (even when it didn't). /var/log/messages: libvirtd: Failed to open pid file '/var/run/libvirtd.pid' : File exists Expected results: libvirtd init script should say FAILED instead of OK if PID file already exists.. Additional info: Standard Fedora 10 with latest updates installed (no updates-testing in use).
I just tested libvirtd 0.6.1 and the issue still remains there.
Moving to libvirt upstream bugzilla Okay, here's what's happening: 1) /etc/rc.d/init.d/functions:daemon() will happily start the daemon if there is a pid file, but the pid listed isn't running 2) libvirtd refuses to start if there is a pid file 3) it only does this after it has daemonized, so the error code is never seen by the init script Suggest the following changes: -) Don't refuse to start if a pidfile exists -) Write the pidfile from the parent process after the daemon process has been spawned; if it fails, kill the daemon and return an error code
I believe this patch should address the issue - it ensures we exit with an error status if pidfile can't be acquired, and I believe it also avoids unlinking the other apps pidfile upon failure http://www.redhat.com/archives/libvir-list/2009-October/msg00654.html
Fixed in 0.7.4 release