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.
Due to a programming error in the initialization code of the libvirtd daemon, the QEMU driver could have failed to find the user or group ID of the qemu application on the system. As a result, libvirtd failed to start. With this update, the error has been corrected and libvirtd now works as expected.
Description of problem:
Trying to start libvirtd fails. This started after upgrading my host from 6.0 -> 6.1
Version-Release number of selected component (if applicable):
libvirt 0.8.7-18.el6_1.1
qemu-img 2:0.12.1.2-2.160.el6_1.2
How reproducible:
100%
Steps to Reproduce:
1. service libvirtd start
Actual results:
libvirtd fails to start.
Expected results:
libvirtd starts.
Additional info:
messages log:
Sep 30 22:35:58 kvm libvirtd: 22:35:58.907: 5356: info : libvirt version: 0.8.7, package: 18.el6_1.1 (Unknown, 2011-09-01-11:22:40, sl6.fnal.gov)
Sep 30 22:35:58 kvm libvirtd: 22:35:58.907: 5356: error : virGetGroupID:2858 : Failed to find group record for name 'qemu': Numerical result out of range
Sep 30 22:35:58 kvm libvirtd: 22:35:58.907: 5356: error : virStateInitialize:1038 : Initialization of QEMU state driver failed
Sep 30 22:35:58 kvm libvirtd: 22:35:58.948: 5356: error : main:3326 : Driver state initialization failed
Sep 30 22:35:58 kvm libvirtd: 22:35:58.949: 5357: warning : qemudDispatchSignalEvent:403 : Shutting down on signal 3
Yes the user/group exists. I tried rolling back to the previous version of libvirt and still get the same error. I have an identical host which is working fine and was upgraded in the same fashion. The user id's and group id's are also identical on both hosts.
cat /etc/passwd |grep qemu
qemu:x:107:107:qemu user:/:/sbin/nologin
cat /etc/group |grep qemu
kvm:x:36:qemu
qemu:x:107:
We need to backport this commit:
commit b3918fabda42e3aecf1b0bfe1079a05e6cad62f7
Author: Eric Blake <eblake>
Date: Mon May 16 15:37:15 2011 -0600
build: tolerate unlimited group size
POSIX allows sysconf(_SC_GETPW_R_SIZE_MAX) to return -1 if there
is no fixed limit, and requires ERANGE errors to track real size.
Model our behavior after the example in POSIX itself:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/getpwuid_r.html
Also, on error for get*_r functions, errno is undefined, and the
real error was the return value.
* src/util/util.c (virGetUserEnt, virGetUserID, virGetGroupID)
(virSetUIDGID): Cope with sysconf failure or too small buffer.
Reported by Matthias Bolte.
https://www.redhat.com/archives/libvir-list/2011-May/msg01074.html
Problem we are facing here is: we use getgrnam_r() to get group ID for qemu. But this function can return ERANGE in case an insufficient buffer was supplied. However, there are not many ways to tell how big buffer should be sufficient, besides iterating over and over until something else than ERANGE is returned.
Short of backporting the patch, or abusing LD_PRELOAD to replace the failing getgrnam_r in a way that works around unpatched libvirt's misuse of the function, I don't see any easy way to work around the failure. I'm not in charge of release decisions, but I can at least ask around to see whether it is possible to get this backport out sooner rather than later.
Comment 18Miroslav Svoboda
2011-10-20 13:51:48 UTC
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:
Due to a programming error in the initialization code of the libvirtd daemon, the QEMU driver could have failed to find the user or group ID of the qemu application on the system. As a result, libvirtd failed to start. With this update, the error has been corrected and libvirtd now works as expected.
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