On Wed, Dec 04, 2013 at 11:21:12AM -0200, Eduardo Otubo wrote: > On 12/04/2013 07:39 AM, Stefan Hajnoczi wrote: > >On Fri, Nov 22, 2013 at 11:00:24AM -0500, Paul Moore wrote: > >>>Developers will only be happy with seccomp if it's easy and rewarding to > >>>support/debug. > >> > >>Agreed. > >> > >>As a developer, how do you feel about the audit/syslog based approach I > >>mentioned earlier? > > > >I used the commands you posted (I think that's what you mean). They > >produce useful output. > > > >The problem is that without an error message on stderr or from the > >shell, no one will think "QEMU process dead and hung == check seccomp" > >immediately. It's frustrating to deal with a "silent" failure. > > The process dies with a SIGKILL, and sig handling in Qemu is hard to > implement due to dozen of external linked libraries that has their > own signal masks and conflicts with seccomp. I've already tried this > approach in the past (you can find in the list by searching for > debug mode)
I now realize we may be talking past each other. Dying with SIGKILL/SIGSYS is perfectly reasonable and I would be happy with that :-). But I think there's a bug in seccomp: a multi-threaded process can be left in a zombie state. In my case the primary thread was killed by seccomp but another thread was deadlocked on a futex. The result is the process isn't quite dead yet. The shell will not reap it and we're stuck with a zombie. I can reproduce it reliably when I run "qemu-system-x86_64 -sandbox on" on Fedora 20 (qemu-system-x86-1.6.1-2). Should seccomp use do_group_exit() for SIGKILL? Stefan
