Hi Florian,
Interesting, but in this case it is not posix_spawn, but plain fork(). The
VM does this, the exec calls come from us, not the libc. See childproc.c .
Cheers, Thomas’
On Tue 4. Jun 2019 at 22:42, Florian Weimer <fwei...@redhat.com> wrote:
> * Thomas Stüfe:
>
> > Then I ran an strace over it and saw this:
> >
> > 5332 [pid 3911] execve("./sleep2", ["./sleep2"], [/* 78 vars */]
> <unfinished ...>
> >
> ..
> > 5342 [pid 3911] <... execve resumed> ) = -1 ENOEXEC (Exec format
> error)
> > 5343 [pid 3911] execve("/bin/sh", ["/bin/sh", "./sleep2"], [/* 78 vars
> */] <unfinished ...>
> > 5347 [pid 3911] <... execve resumed> ) = 0
> >
> > So, if the first exec fails for whatever reason, we try again, passing
> the executable file name
> > as argument to the system shell. This does not feel right? Do you know
> why we do this?
>
> What's your glibc version? Unless it's ancient, this is probably this
> bug:
>
> <https://sourceware.org/bugzilla/show_bug.cgi?id=23264>
>
> I don't know why this behavior was part of the initial implementation of
> posix_spawn. It was subsequently removed for new binaries, but came
> back as a regression (the bug I referenced).
>
> Thanks,
> Florian
>
