Hi Conrad, On Mon, May 19, 2014 at 07:26:54PM +0200, Conrad Hoffmann wrote: > >> Works all the time for me. Running lsof before and after the signal > >> neatly shows how the worker closed the listening socket but the parent > >> still has it. > > > > I'm just confused with what the "parent" here can be since you have nbproc > > 1, > > so there's a single process overall. Or maybe you're using the debugger to > > breakpoint the parent process and prevent it from leaving ? > > > > I was thinking that starting with nbproc 2 with long connections on both > > would cause the issue to happen as well. > > I am not sure what the proper terminology is, here. But when you run in > daemon mode with nbproc 1 you get exactly one fork. The output of ps > looks somewhat like this: > > 18616 ? S 0:00 | \_ haproxy-systemd-wrapper > 18618 ? S 0:00 | \_ /usr/sbin/haproxy > 18619 ? Ss 0:09 | \_ /usr/sbin/haproxy > > I was referring to 18618 as the "parent" process. It never does > anything, just wait()s.
Ah OK, I forgot about the systemd wrapper. Now that makes sense. Systemd still looks quite strange to me, 3 processes needed to run only one... What a beautiful design :-) (...) > I modified the patch accordingly, with one improvement > suggestion, though: I marked the fds as cloned in fork_poller() instead > of evpolls _do_fork. This way, this flag is set regardless of the > protocol and the poller used and any other (future?) pollers could still > use it. Seemed more generic, what do you think? I can also put it into > _do_fork if you prefer that. That's what I initially thought, because I didn't remember there was this common fork_poller() function, but what you did is better, each part does its own job, that's really clean this way. Can you please provide a commit message summarizing the issue you faced and the solution, then I'll merge your work ASAP ? Thanks, Willy
