I stumbled on what might be an odd bug.
Hi Saj,
Thank you for such a detailed bug-report!
The call to posix_spawn(3) appears evident there, but there is no evidence of
any follow-up to the failure. s6-svscan should call term() and die soon
afterwards but that never happens.
Repeating the test with no .s6-svscan/SIGTERM file produced a similar result
(albeit with errno=2 on exec).
At this stage, I am unsure where the problem lies. It may not be in s6.
Congratulations: you have found a bug in qemu! (unfortunately, there
are many of those.)
posix_spawn(3) uses clone(CLONE_VM|CLONE_VFORK) + execve().
Normally, when clone() is run with the CLONE_VFORK option, the
parent immediately stops execution (the clone() call doesn't even
return) until the child has completed, or failed, its execve().
Then the parent can resume, and check whether the child has succeeded
and is now running the new process.
You can check the glibc source code doing it here:
https://elixir.bootlin.com/glibc/latest/source/sysdeps/unix/sysv/linux/spawni.c#L373
But this is not what is happening here. Your strace shows that
clone() returns 25 before the child thread runs, and the
parent execution returns to s6-svscan: read(6, 0x1808550,128) is
s6-svscan reading on its signalfd, checking for another signal,
and returning to its ppoll() loop when it fails.
From s6-svscan's point of view, posix_spawn() has succeeded, so
the SIGTERM is being handled and the default term() routine should
not be called - even though the child hasn't execve()'d yet. And when
the execve() happens and fails, it's just the child process terminating,
nothing to see here, nothing to do but wait4() it.
So, SIGTERM does nothing because posix_spawn() is lying to s6-svscan,
pretending to have succeeded when it doesn't know it yet (and is going
to fail), and goading it into not doing anything. And it's lying
because something in qemu is messing with the semantics of CLONE_VFORK.
I'm sorry, but I don't have an easy solution for you, apart from
fixing qemu (which I'm sure everyone here has already done twice
before breakfast).
The only workaround I can suggest is to rebuild the s6 stack
(skalibs/execline/s6) with posix_spawn() disabled; to do that, add
"--with-sysdep-posixspawn=no" to the ./configure command line when
building skalibs. But of course, that makes it impossible to use
prebuilt packages.
--
Laurent
