Hi, I had similar issues when reloading haproxy with lot of ssl (long to fork). A solution I use is to delay next reload in systemd unit until a reload is in progress.
2016-10-24 17:06 GMT+02:00 Willy Tarreau <[email protected]>: > On Mon, Oct 24, 2016 at 01:09:59PM +0000, Pierre Cheynier wrote: >> > Same for all of them. Very interesting, SIGUSR2 (12) is set >> > in SigIgn :-) One question is "why", but at least we know we >> > have a workaround consisiting in unblocking these signals in >> > haproxy-systemd-wrapper, as we did in haproxy. >> >> > Care to retry with the attached patch ? >> >> Same behaviour. >> >> SigIgn is still 0000000000001000 (which is probably normal, I assume the >> goal was to ignore that). > > No, the goal was to ensure we don't block anything. I was a bit quicky at > copy-pasting it from haproxy before going to a meeting, I can recheck, but > there's something odd here. > > Willy >
