Im trying to start libvirtd on Ubuntu 18.04 and get the assert: libvirtd: libxl_fork.c:353: sigchld_installhandler_core: Assertion `((void)"application must negotiate with libxl about SIGCHLD", !(sigchld_saved_action.sa_flags & SA_SIGINFO) && (sigchld_saved_action.sa_handler == SIG_DFL || sigchld_saved_action.sa_handler == SIG_IGN))' failed. Any hint what the reason of this could be? I'm running Xen 4.9.2, linux 4.15.0-23-generic. libvirtd is installed via: dpkg -l | grep libvirt ii gir1.2-libvirt-glib-1.0:amd64 1.0.0-1 amd64 GObject introspection files for the libvirt-glib library ii libvirt-bin 4.0.0-1ubuntu8.3 amd64 programs for the libvirt library ii libvirt-clients 4.0.0-1ubuntu8.3 amd64 Programs for the libvirt library ii libvirt-daemon 4.0.0-1ubuntu8.3 amd64 Virtualization daemon ii libvirt-daemon-driver-storage-rbd 4.0.0-1ubuntu8.3 amd64 Virtualization daemon RBD storage driver ii libvirt-daemon-system 4.0.0-1ubuntu8.3 amd64 Libvirt daemon configuration files ii libvirt-glib-1.0-0:amd64 1.0.0-1 amd64 libvirt GLib and GObject mapping library ii libvirt0:amd64 4.0.0-1ubuntu8.3 amd64 library for interfacing with different virtualization systems ii python-libvirt 4.0.0-1 amd64 libvirt Python bindings
(gdb) bt #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 #1 0x00007fa274e80801 in __GI_abort () at abort.c:79 #2 0x00007fa274e7039a in __assert_fail_base (fmt=0x7fa274ff77d8 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x7fa23b297630 "((void)\"application must negotiate with libxl about SIGCHLD\", !(sigchld_saved_action.sa_flags & SA_SIGINFO) && (sigchld_saved_action.sa_handler == SIG_DFL || sigchld_saved_action.sa_handler == SIG_IGN"..., file=file@entry=0x7fa23b297436 "libxl_fork.c", line=line@entry=353, function=function@entry=0x7fa23b297850 "sigchld_installhandler_core") at assert.c:92 #3 0x00007fa274e70412 in __GI___assert_fail ( assertion=0x7fa23b297630 "((void)\"application must negotiate with libxl about SIGCHLD\", !(sigchld_saved_action.sa_flags & SA_SIGINFO) && (sigchld_saved_action.sa_handler == SIG_DFL || sigchld_saved_action.sa_handler == SIG_IGN"..., file=0x7fa23b297436 "libxl_fork.c", line=353, function=0x7fa23b297850 "sigchld_installhandler_core") at assert.c:101 #4 0x00007fa23b253ac0 in libxl.sigchld_needed () from /usr/lib/x86_64-linux-gnu/libxenlight-4.9.so #5 0x00007fa23b253ece in libxl_childproc_setmode () from /usr/lib/x86_64-linux-gnu/libxenlight-4.9.so #6 0x00007fa23b4e4f35 in ?? () from /usr/lib/libvirt/connection-driver/libvirt_driver_libxl.so #7 0x00007fa275c4bdb5 in virStateInitialize () from /usr/lib/x86_64-linux-gnu/libvirt.so.0 #8 0x0000562b443bebeb in ?? () #9 0x00007fa275ba1ad2 in ?? () from /usr/lib/x86_64-linux-gnu/libvirt.so.0 #10 0x00007fa27523f6db in start_thread (arg=0x7fa213fff700) at pthread_create.c:463 #11 0x00007fa274f6188f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Debugging further it seems that The assertion is because there is already a signal handler registered by a Virtualbox library that is loaded: (gdb) p /x sigchld_saved_action $3 = {__sigaction_handler = {sa_handler = 0x7fc5b5b1c400, sa_sigaction = 0x7fc5b5b1c400}, sa_mask = {__val = {0x0, 0xb, 0x7fc5ff51209d, 0x7fc5ff7308f0, 0xb, 0x1d, 0x5, 0x7fc5c5044ca0, 0x7fc594123d00, 0x7fc5c50448d0, 0x7fc5ff5120be, 0x7fc5ff774760, 0x557e03daa170, 0x7fc5b1eae730, 0x7fc594123d00, 0x7fc5b1eae680}}, sa_flags = 0x14000001, sa_restorer = 0x7fc5fec12890} The signal handler is inside /usr/lib/virtualbox/VBoxRT.so: ... 7fc5b5658000-7fc5b5764000 r-xp 00000000 08:12 1578023 /usr/lib/virtualbox/VBoxXPCOM.so 7fc5b5764000-7fc5b5963000 ---p 0010c000 08:12 1578023 /usr/lib/virtualbox/VBoxXPCOM.so 7fc5b5963000-7fc5b596d000 r--p 0010b000 08:12 1578023 /usr/lib/virtualbox/VBoxXPCOM.so 7fc5b596d000-7fc5b5970000 rw-p 00115000 08:12 1578023 /usr/lib/virtualbox/VBoxXPCOM.so 7fc5b5970000-7fc5b5973000 rw-p 00000000 00:00 0 7fc5b5978000-7fc5b5c1f000 r-xp 00000000 08:12 1578012 /usr/lib/virtualbox/VBoxRT.so 7fc5b5c1f000-7fc5b5e1f000 ---p 002a7000 08:12 1578012 /usr/lib/virtualbox/VBoxRT.so 7fc5b5e1f000-7fc5b5e3f000 r--p 002a7000 08:12 1578012 /usr/lib/virtualbox/VBoxRT.so 7fc5b5e3f000-7fc5b5e47000 rw-p 002c7000 08:12 1578012 /usr/lib/virtualbox/VBoxRT.so 7fc5b5e47000-7fc5b5e4f000 rw-p 00000000 00:00 0 7fc5b5e50000-7fc5b5e59000 r-xp 00000000 08:12 1578024 /usr/lib/virtualbox/VBoxXPCOMC.so 7fc5b5e59000-7fc5b6059000 ---p 00009000 08:12 1578024 /usr/lib/virtualbox/VBoxXPCOMC.so 7fc5b6059000-7fc5b605a000 r--p 00009000 08:12 1578024 /usr/lib/virtualbox/VBoxXPCOMC.so 7fc5b605a000-7fc5b605b000 rw-p 0000a000 08:12 1578024 /usr/lib/virtualbox/VBoxXPCOMC.so ... Doing a sudo mv /usr/lib/virtualbox /usr/lib/virtualbox.bck Seems to make libvirtd start... Maybe ticket can be closed?
We really want these to coexist, so ideally libxl would be fixed to not assert like this. I'm unclear if this can be fixed in libvirt's libxl driver, or would need to be fixed in libxl itself.
Added Jim to CC list in case he has ideas about how to solve this problem between libxl & vbox.
There's an older bug tracking this with links to some upstream discussions https://bugzilla.redhat.com/show_bug.cgi?id=1278847 *** This bug has been marked as a duplicate of bug 1278847 ***