On 9 February 2013 09:45, Willy Tarreau <w...@1wt.eu> wrote:
> On Fri, Feb 08, 2013 at 03:58:46PM +0100, Marc-Antoine Perennou wrote:
> > @@ -1493,8 +1499,13 @@ int main(int argc, char **argv)
> > px = px->next;
> > }
> >
> > - if (proc == global.nbproc)
> > + if (proc == global.nbproc) {
> > + if (global.mode & MODE_SYSTEMD) {
> > + for (proc = 0; proc < global.nbproc;
> proc++)
> > + waitpid(children[proc], NULL, 0);
> > + }
> > exit(0); /* parent must leave */
> > + }
> >
> > /* if we're NOT in QUIET mode, we should now close the 3
> first FDs to ensure
> > * that we can detach from the TTY. We MUST NOT do it in
> other cases since
>
> I think we have an issue here, which should not be too hard to fix. The
> parent is the one which binds to all the ports, so here it still owns
> them. This means that a soft restart of a new process will fail until
> the parent leaves, since it will not release these ports. And the parent
> will not leave until all of its children have terminated. Or maybe I'm
> missing something :-/
>
> Also wouldn't it be worth catching EINTR here in the loop ? Otherwise
> I fear that random signals sent to the process will make the for loop
> progress to next child eventhough previous ones are not dead. This can
> easily happen during debugging sessions (ctrl-Z/bg) or when people
> mistakenly send a SIGHUP to the old process.
>
> Willy
>
>
>
I just made a simple test, running a webserver serving a big file locally,
using haproxy,
my wrapper and systemd service. I started a download and during this
download,
reloaded haproxy. I using nbproc = 2.
What happened ?
When I started haproxy, I ended up with a wrapper launching a child
launching itself
two children, we'll call them ha1, ha11 and ha12. Then when I reloaded, the
wrapper
launched a new child which launched two new children, ha2, ha21 and ha22.
ha11 and thus ha1 were still there until the download had finished, ha12
got to zombie state.
ha2, ha21 and ha22 successfully have shown up and take all new connections.
Once the download has finished, ha11 exited, ha12 too (waitpid making it
leave the zombie state)
and then ha11, leaving us with only ha2, ha21 and ha22.
I think this is the expected behaviour, so there don't seem to be any bug
here.
For the EINTR stuff, I'm not sure at all, not really familiar with it, so I
will give it a look
