[Patch] weston-launch: Fix tight poll/recvmsg loop on weston exit

[Bruno Prémont]

On Wed, 07 Oct 2015 15:27:18 -0500 Derek Foreman wrote:
> Still need to decide what to do with this patch...
> 
> comments below.

Sorry for not being very responsive, I'm running rather low on time and
have had no time to play around with weston to determine which factors
are needed in addition to strace'ing weston-launch to reproduce.

> On 14/05/15 03:43 PM, Derek Foreman wrote:
> > On 27/03/15 07:29 AM, Bruno Prémont wrote:
> >> When weston fails to run while being launched by weston-launch it's
> >> socketpair causes poll() to notify POLLIN|POLLHUP and lets recvmsg()
> >> return 0.
> >>
> >> Properly cleanup and exit in that case instead of poll()ing in a tight
> >> loop and leaving tty in graphics mode if we get SIGKILLed as only way
> >> out.
> >>
> >> This happens only when weston-launch (and weston) are being traced
> >> as in `strace -f weston-launch` as then signalfd is not passing the
> >> SIGCHLD signal.
> > 
> > How would I go about reproducing this bug?
> > 
> > When I strace -f weston-launch sigchild gets through just fine.
> > 
> >>
> >> Signed-off-by: Bruno Prémont <bonbons at linux-vserver.org>
> >> ---
> >> --- a/src/weston-launch.c	2015-03-01 18:46:27.289835438 +0100
> >> +++ b/src/weston-launch.c	2015-03-01 18:46:24.599835453 +0100
> >> @@ -771,6 +771,8 @@ main(int argc, char *argv[])
> >>  			error(0, errno, "poll failed");
> >>  		if (fds[0].revents & POLLIN)
> >>  			handle_socket_msg(&wl);
> >> +		if (fds[0].revents & POLLHUP)
> >> +			quit(&wl, 0);
> 
> This would prevent us from getting weston's exit code on a successful
> exit, since it could trigger before the sigchild handling?
>
> Just moving the clause after the fds[1] test isn't sufficient to fix
> that as it could happen in an earlier event before sigchld even happens.

That could be avoided by explicitly wait()ing for weston in quit() when
no signal has been received yet (and moving logic for SIGCHLD from
handle_signal() to quit()).

> It would be good if you could explain how exactly to reproduce the problem.

It triggered for me just by running weston-launch under strace (running
it as a non-privileged user if I remember correctly).
Running weston-launch unmonitored avoids the issue.

> >>  		if (fds[1].revents)
> >>  			handle_signal(&wl);
> >>  	}

Regards,
Bruno