Bug 491766 - libvirtd fails to start if pid file exists but init script still says it started OK
Summary: libvirtd fails to start if pid file exists but init script still says it star...
Alias: None
Product: Virtualization Tools
Classification: Community
Component: libvirt
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Daniel Veillard
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2009-03-23 22:22 UTC by Pasi Karkkainen
Modified: 2010-03-16 17:18 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-11-26 15:15:10 UTC

Attachments (Terms of Use)

Description Pasi Karkkainen 2009-03-23 22:22:19 UTC
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

How reproducible:

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).

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).

Comment 1 Pasi Karkkainen 2009-03-24 19:07:10 UTC
I just tested libvirtd 0.6.1 and the issue still remains there.

Comment 2 Mark McLoughlin 2009-03-25 16:07:22 UTC
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

Comment 3 Daniel Berrangé 2009-10-23 16:51:57 UTC
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


Comment 4 Daniel Berrangé 2009-11-26 15:15:10 UTC
Fixed in 0.7.4 release

Note You need to log in before you can comment on or make changes to this bug.