Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Cause:
If both SysV init and Upstart scripts are installed (eg. when VDSM is installed) and libvirtd is managed by upstart, the SysV init script is unaware of this.
Consequence:
While libvirtd is managed by upstart, SysV init script reports confusing error messages to the user, as it is not aware of libvirtd running already. The user is unable to restart libvirtd using the SysV init script, and is unaware that libvirtd is managed by upstart.
Fix:
SysV init script now checks if libvird is managed by upstart, and in a positive case, user is notified, that he should use upstart tools to manage libvirtd.
Result:
Users are able to restart libvirtd without getting strange error messages from the SysV init script, while using upstart.
Description of problem:
run service libvirtd start
Version-Release number of selected component (if applicable):
libvirt-0.9.4-0rc1.2.el6.x86_64
How reproducible:
Steps to Reproduce:
1.service vdsmd start
2.service libvirtd restart
3.
Actual results:
[root@buri01 export]# service libvirtd restart
Stopping libvirtd daemon: [ OK ]
Starting libvirtd daemon: libvirtd: error: Unable to obtain pidfile. Check /var/log/messages or run without --daemon for more info.
[FAILED]
Expected results:
change error message to start to use initctl instead of service
Additional info:
vdsm-4.9-87.el6.x86_64
I don't agree. In RHEL-6 we still use traditional init script for libvirtd so changing the error would be very misleading. The upstart job for libvirtd which vdsm uses is provided in /usr/share/doc and one needs to copy it to the right place first to start using it. And that's exactly what vdsm does.
Eyal, I agree with Jiri here, but I want to confirm something. I don't see the error message currently referencing service; can you point out exactly the language that you think should be changed and what you think it should be changed to?
i think the point is if the service isn't managed by 'service' any more, than it should report so.
i.e.:
service libvirtd status should if it's running or not, regardless if it's running from service or initctl.
or at least should report an error that libvirtd is managed via initctl, rather than via service.
same for start.
i.e., instead of:
Starting libvirtd daemon: libvirtd: error: Unable to obtain pidfile. Check
/var/log/messages or run without --daemon for more info.
I'd expect something either checking the service is managed via initctl and warning about it:
"Starting libvirtd daemon: libvirtd: error: libvirtd is configured with initctl. please use initctl libvirtd start instead"
or (which i think would be more confusing):
"Starting libvirtd daemon: libvirtd: error: Unable to obtain pidfile. Check
/var/log/messages or run without --daemon for more info. This may also happen if libvirtd was started via initctl instead of the service command."
right now, it is very confusing to users that service libvirtd is saying it is not running and fails to start via the service command they know.
Thanks Itamar, that makes sense. initctl status libvirt is pretty clear about whether it knows about libvirt. I wonder if this will be an issue for systemd as well.
I think one of the major point of failure is that the upstart script
should not remove the pid file if the pointed process id is running and
a libvirt daemon. Similary we must make sure that the init.d script
also fail to start a new daemon if there is one run under upstart control
(and again checking the pid file should be sufficient).
If we make sure those two case are correctly detected then I think the
probability of errors comming from confusion on how the daemon is started
in a RHEV environment with vdsm becomes very low. At least this won't result
in two daemon running concurrently !
Daniel
pkgs:
# rpm -q libvirt vdsm qemu-kvm kernel
libvirt-0.9.4-16.el6.x86_64
vdsm-4.9-106.el6.x86_64
qemu-kvm-0.12.1.2-2.195.el6.x86_64
kernel-2.6.32-206.el6.x86_64
Steps:
1.service vdsmd start
2.service libvirtd restart
Actual results:
# service vdsmd start
Stopping libvirtd daemon: libvirtd: libvirtd is managed by upstart and started, use initctl instead
vdsm: libvirt already configured for vdsm [ OK ]
Starting iscsid:
Starting up vdsm daemon:
vdsm start [ OK ]
# service libvirtd restart
Stopping libvirtd daemon: libvirtd: libvirtd is managed by upstart and started, use initctl instead
So, this is fixed.
Technical note added. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.
New Contents:
Cause:
If both SysV init and Upstart scripts are installed (eg. when VDSM is installed) and libvirtd is managed by upstart, the SysV init script is unaware of this.
Consequence:
While libvirtd is managed by upstart, SysV init script reports confusing error messages to the user, as it is not aware of libvirtd running already. The user is unable to restart libvirtd using the SysV init script, and is unaware that libvirtd is managed by upstart.
Fix:
SysV init script now checks if libvird is managed by upstart, and in a positive case, user is notified, that he should use upstart tools to manage libvirtd.
Result:
Users are able to restart libvirtd without getting strange error messages from the SysV init script, while using upstart.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
http://rhn.redhat.com/errata/RHBA-2011-1513.html
Description of problem: run service libvirtd start Version-Release number of selected component (if applicable): libvirt-0.9.4-0rc1.2.el6.x86_64 How reproducible: Steps to Reproduce: 1.service vdsmd start 2.service libvirtd restart 3. Actual results: [root@buri01 export]# service libvirtd restart Stopping libvirtd daemon: [ OK ] Starting libvirtd daemon: libvirtd: error: Unable to obtain pidfile. Check /var/log/messages or run without --daemon for more info. [FAILED] Expected results: change error message to start to use initctl instead of service Additional info: vdsm-4.9-87.el6.x86_64