RFR(s): 8223777: In posix_spawn mode, failing to exec() jspawnhelper does not result in an error

[David Lloyd]

Pipe communication isn't very costly AFAIK.  The added complexity
would be waiting for either a thing to appear on the pipe indicating
success or else a waitpid/waitid+WNOHANG for exit code 127.  But
writing a thing to the pipe won't help determine if the subsequent
exec succeeded, which is really the interesting bit.

You *could* wait for the other end of the pipe to close (and write
jspawnhelper to close the write end on exec) as an indication that the
subsequent exec succeeded, while also reading from the pipe to
determine if the exec has failed (writing the errno or something).
Not sure if that's racy though, as I've only given it a minute of
thought.

On Tue, May 14, 2019 at 4:37 AM Thomas Stüfe <thomas.stuefe at gmail.com> wrote:
>
> Neat idea!
>
> But this incurs costs for this pipe communication on every spawn. What do
> the others think?
>
> Cheers, Thomas
>
> On Tue, May 14, 2019 at 10:22 AM Florian Weimer <fweimer at redhat.com> wrote:
>
> > * Thomas Stüfe:
> >
> > > This is impossible to fix completely - see Martin's comment about the
> > > impossibility to foresee whether an exec() will succeed without actually
> > > exec()ing. But at least we can test the execute permissions on the
> > > jspawnhelper. Which this fix does. This fixes Ubuntu 16.4 (Now, I get an
> > > IOException if jspawnhelper is not executable).
> >
> > I think jspawnhelper could write something to the pipe to show that it
> > has started.  If you never get that notification, you know that
> > jspawnhelper hasn't run, even if posix_spawn has succeeded.
> >
> > (This fix will also help qemu-user and WSL, which implement vfork as
> > fork and interfere with the internal error reporting from posix_spawn.)
> >
> > Thanks,
> > Florian
> >



-- 
- DML