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.
Bug 1028691 - [GSS 7.0] Restart libvirtd.service results in 'libvirtd was killed by signal 6 (SIGABRT)'
Summary: [GSS 7.0] Restart libvirtd.service results in 'libvirtd was killed by signal ...
Keywords:
Status: CLOSED DUPLICATE of bug 1014029
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: selinux-policy
Version: 7.0
Hardware: x86_64
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Miroslav Grepl
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks: 860099
TreeView+ depends on / blocked
 
Reported: 2013-11-09 16:26 UTC by Scott Spurrier
Modified: 2013-12-04 11:24 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-12-04 11:24:55 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
coredump (1.06 MB, application/x-bzip)
2013-11-09 16:43 UTC, Scott Spurrier 		no flags Details
View All

Description Scott Spurrier 2013-11-09 16:26:39 UTC 
Description of problem:
On a Server with GUI install with all the virt add-on's selected, virt-manager is unable to connect to any hypervisors with the error "verify that the libvirtd' daemon is running".  

'libvirtd.service' was already enabled, but 'libvirt-guests.service',  'virt-who.service',  'virtlockd.socket' were disabled so I enabled them.  Restarting 'libvirtd.service' resulted in "Process /usr.sbin/libvirtd was killed by signal 6 (SIGABRT) -abrt.

Version-Release number of selected component (if applicable):


How reproducible:
On my system I can repo this easily.  

Steps to Reproduce:
1.  Install 'Server with GUI' and select all the virt add-on's.

2.  Open virt-manager.. my system is unable to connect to any hypervisors and the error message says to verify libvirtd is running.

3.  I verified libvirtd is running..

[root@localhost ~]# systemctl list-unit-files | grep virt
libvirt-guests.service                      disabled
libvirtd.service                            enabled
virt-who.service                            disabled
virtlockd.service                           static
virtlockd.socket                            disabled

enable - 'libvirt-guests.service',  'virt-who.service',  'virtlockd.socket' 

[root@localhost ~]# systemctl list-unit-files | grep virt
libvirt-guests.service                      enabled
libvirtd.service                            enabled
virt-who.service                            enabled
virtlockd.service                           static
virtlockd.socket                            enabled

[root@localhost ~]# systemctl restart libvirtd.service

Actual results:
Restarting 'libvirtd.service' resulted in "Process /usr.sbin/libvirtd was killed by signal 6 (SIGABRT) -abrt.

Expected results:
On this same hardware running RHEL 6, I have no problems running virt-manager and vm's.  I expect the same functionality with RHEL 7.

Additional info:
I seem to have lost my messages file but I do have a coredump which I will attach.
Comment 1 Scott Spurrier 2013-11-09 16:43:47 UTC 
Created attachment 821919 [details]
coredump
Comment 3 Ján Tomko 2013-11-11 14:41:02 UTC 
The coredump was generated by libvirt-1.1.1-8.el7. Relevant backtrace:
#0  0x00007f2356561999 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x00007f23565630a8 in __GI_abort () at abort.c:90
#2  0x00007f23565a2147 in __libc_message (do_abort=do_abort@entry=2, 
    fmt=0x7f23566aa888 "type=\"fast\" count=\"%zu\" size=\"%zu\"/>\n<total type=\"rest\" count=\"%zu\" size=\"%zu\"/>\n<system type=\"current\" size=\"%zu\"/>\n<system type=\"max\" size=\"%zu\"/>\n", fmt@entry=0x7f23566aa968 "*** Error in `%s': %s: 0x%s ***\n")
    at ../sysdeps/unix/sysv/linux/libc_fatal.c:196
#3  0x00007f23565a7f47 in malloc_printerr (action=<optimized out>, 
    str=0x7f23566aa8b0 "tal type=\"rest\" count=\"%zu\" size=\"%zu\"/>\n<system type=\"current\" size=\"%zu\"/>\n<system type=\"max\" size=\"%zu\"/>\n", ptr=<optimized out>) at malloc.c:4972
#4  0x00007f2356f237b7 in selabel_open (backend=942, opts=0xa11, nopts=6) at label.c:166

^^ these may be innacurate because I only have the correct debuginfo installed for libvirt

#5  0x00007f235934bf13 in virSecurityManagerDispose (obj=0x7f2342fd2801) at security/security_manager.c:236
#6  0x00007f23591f96eb in virObjectUnref (anyobj=anyobj@entry=0x7f233c2e30c0) at util/virobject.c:262
#7  0x00007f235934c07c in virSecurityManagerNewDriver (drv=0x7f235962fde0 <virSecurityDriverSELinux>, 
    virtDriver=virtDriver@entry=0x7f2342fd28b3 "LXC", allowDiskFormatProbing=<optimized out>, defaultConfined=<optimized out>, 
    requireConfined=<optimized out>) at security/security_manager.c:99
#8  0x00007f235934c235 in virSecurityManagerNew (name=<optimized out>, virtDriver=virtDriver@entry=0x7f2342fd28b3 "LXC", 
    allowDiskFormatProbing=allowDiskFormatProbing@entry=false, defaultConfined=<optimized out>, requireConfined=<optimized out>)
    at security/security_manager.c:186

This looks similar to bug 1014029. Is your /etc/selinux/targeted/contexts/lxc_contexts missing quotes around the context strings, as described in https://bugzilla.redhat.com/show_bug.cgi?id=1014029#c13?

(Note that 'enabled' in 'systemctl list-unit-files' output does not verify if libvirtd is running, only that it should be run at system startup. Use 'systemctl status libvirtd' instead.)
Comment 4 chentao 2013-12-02 10:25:35 UTC 
Hi,Scott. when i go through this bug ,I can't reproduce this issue, pls help to have a look is there something wrong with my reproduce steps,Thanks.

Version-Release number of selected component (if applicable):
kernel-3.10.0-54.el7.x86_64
libvirt-1.1.1-12.el7.x86_64
qemu-kvm-1.5.3-19.el7.x86_64

steps:
1.Install 'Server with GUI' and select all the virt add-on's.

2.Check the status of 'libvirt-guests.service', 'virt-who.service', 'virtlockd.socket'

[root@localhost ~]# systemctl list-unit-files | grep virt
libvirt-guests.service                      disabled
libvirtd.service                            enabled
virt-who.service                            disabled
virtlockd.service                           static
virtlockd.socket                            disabled

3.enable - 'libvirt-guests.service',  'virt-who.service',  'virtlockd.socket' 

[root@localhost~]systemctl enable libvirt-guests.service

[root@localhost~]systemctl enable virt-who.service

[root@localhost~]systemctl enable virtlockd.socket

[root@localhost ~]# systemctl list-unit-files | grep virt
libvirt-guests.service                      enabled
libvirtd.service                            enabled
virt-who.service                            enabled
virtlockd.service                           static
virtlockd.socket                            enabled

[root@localhost ~]# systemctl restart libvirtd.service

4.#service libvirtd status
Redirecting to /bin/systemctl status  libvirtd.service
libvirtd.service - Virtualization daemon
   Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; enabled)
   Active: active (running) since Mon 2013-12-02 18:12:19 CST; 8min ago
 Main PID: 19654 (libvirtd)
   CGroup: /system.slice/libvirtd.service
           ├─ 2742 /sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default...
           └─19654 /usr/sbin/libvirtd

Dec 02 18:12:19 localhost.localdomain systemd[1]: Starting Virtualization dae...
Dec 02 18:12:19 localhost.localdomain systemd[1]: Started Virtualization daemon.
Dec 02 18:12:22 localhost.localdomain dnsmasq[2742]: read /etc/hosts - 2 addr...
Dec 02 18:12:22 localhost.localdomain dnsmasq[2742]: read /var/lib/libvirt/dn...
Dec 02 18:12:22 localhost.localdomain dnsmasq-dhcp[2742]: read /var/lib/libvi...
Hint: Some lines were ellipsized, use -l to show in full.

#virt-manager
Open virt-manager and my system is able to connect to the hypervisor.
Comment 5 Ján Tomko 2013-12-04 11:24:55 UTC 
The reporter doesn't have the system available anymore, closing as a duplicate per comment 3.

*** This bug has been marked as a duplicate of bug 1014029 ***
Note You need to log in before you can comment on or make changes to this bug.