Re: [libvirt] [Xen-devel] [vbox-dev] Assert with libvirt + xen hvm

Cole Robinson writes ("Re: [Xen-devel] [libvirt] [vbox-dev] Assert with libvirt + xen hvm"): Sadly the way that there's a single SIGCHLD handler in the Unix API is extremely awkward in multithreaded programs. The complicated code in libxl is trying to help cope with that. I think you are wrong about this. SIGCHLD (like all signals) is set to SIG_DFL by default. But it is only SIG_IGN that causes automatic reaping of children. I normally use the online Open Group spec to check this kind of thing - it's more authoritative than manpages. http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#... SIG_IGN ... If the action for the SIGCHLD signal is set to SIG_IGN, child processes of the calling processes shall not be transformed into zombie processes when they terminate. If the calling process subsequently waits for its children, and the process has no unwaited-for children that were transformed into zombie processes, it shall block until all of its children terminate, and wait(), waitid(), and waitpid() shall fail and set errno to [ECHILD]. I don't know exactly what virtualbox does with children but if the only reason it is setting a SIGCHLD handler is to avoid its children being automatically reaped, leaving it set to SIG_DFL will work just fine. If virtualbox always reaps its children synchronously (ie, it does not use SIGCHLD to get notified of child death) then setting the libxl signal mode to libxl_sigchld_owner_libxl_always_selective_reap in libvirt should work. This is what libvirt (at laast in master) does. There would then be no need for virtualbox to do anything to SIGCHLD. Although, it might be worth checking that it isn't SIG_IGN and screaming somewhere if it is. Incidentally it seems to me possible that the reason why virtualbox explictly sets a SIGCHLD handler may be that at some point in the past you had encountered a bug with someone in the same process setting SIGCHLD to SIG_IGN. Ian.