When the processes stack up, the old ones don't respond to anything other than 'kill -9'.
On Fri, Oct 30, 2015 at 1:20 PM, Willy Tarreau <[email protected]> wrote: > On Fri, Oct 30, 2015 at 12:23:57PM -0400, Chris Riley wrote: > > Hi Willy, > > > > Thanks for your quick reply. > > > > > It should work better but will very likely hide the root cause. I > suspect > > > you'll find two processes running after a reload because the old one > > > doesn't stop then. > > > > Yep, that's exactly what I'm seeing with 3.10. I've got a bunch of > haproxy > > processes stacked up, all with an -sf flag and each being passed the PID > of > > the previous process. The only one not in the process list is the initial > > haproxy instance created when 'service haproxy start' was first run. > > > > lb-01 ~ [qa] # ps ax | grep hap > > 2834 ? Ss 0:00 /usr/sbin/haproxy -D -f > /etc/haproxy/haproxy.cfg > > -p /var/run/haproxy.pid -sf 2822 > > 2871 ? Ss 0:00 /usr/sbin/haproxy -D -f > /etc/haproxy/haproxy.cfg > > -p /var/run/haproxy.pid -sf 2859 > > 2883 ? Ss 0:00 /usr/sbin/haproxy -D -f > /etc/haproxy/haproxy.cfg > > -p /var/run/haproxy.pid -sf 2871 > > 2910 ? Ss 0:00 /usr/sbin/haproxy -D -f > /etc/haproxy/haproxy.cfg > > -p /var/run/haproxy.pid -sf 2896 > > 2922 ? Ss 0:00 /usr/sbin/haproxy -D -f > /etc/haproxy/haproxy.cfg > > -p /var/run/haproxy.pid -sf 2910 > > 2947 ? Ss 0:00 /usr/sbin/haproxy -D -f > /etc/haproxy/haproxy.cfg > > -p /var/run/haproxy.pid -sf 2934 > > 2959 ? Ss 0:00 /usr/sbin/haproxy -D -f > /etc/haproxy/haproxy.cfg > > -p /var/run/haproxy.pid -sf 2947 > > 2962 pts/1 S+ 0:00 grep --colour=auto hap > > These ones don't all match, in fact only the last one is fine. That's > strange. > > > > That would confirm the possibility that the signal is not sent at all, > > > or at least not to the right process. Could you check the exact command > > > that is started, to ensure the pids are correct (or present at all) ? > > > Can you also try by hand to first send SIGUSR1 to the old process, > > > then perform the reload, then send SIGTTOU by hand to the old one ? > > > If it works, it would confirm an issue with the ability to send a > > > signal to the old process from the new one. > > > > 'service haproxy start' invokes this: > > > > daemon $exec -D -f /etc/$prog/$prog.cfg -p /var/run/$prog.pid > > > > which produces: > > > > usr/sbin/haproxy -D -f /etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid > > > > ps ax shows: > > > > 2822 ? Ss 0:00 /usr/sbin/haproxy -D -f > /etc/haproxy/haproxy.cfg > > -p /var/run/haproxy.pid > > > > cat /var/run/haproxy.pid shows: > > 2822 > > > > 'service haproxy reload' invokes this: > > > > $exec -D -f /etc/$prog/$prog.cfg -p /var/run/$prog.pid -sf $(cat > > /var/run/$prog.pid) > > OK so there is no reason for it not to work. > > > which produces: > > > > 2834 ? Ss 0:00 /usr/sbin/haproxy -D -f > /etc/haproxy/haproxy.cfg > > -p /var/run/haproxy.pid -sf 2822 > > > > cat /var/run/haproxy.pid then shows: > > 2834 > > > > I'll try manually sending SIGUSR1 and SIGTTOU as you suggested and see > if I > > can determine what's happening. > > Yes that will definitely help. > > > > Any chance that this issue is related to or that same as this one? > > > > https://github.com/haproxy/haproxy/issues/48 > > Looks similar indeed. RHEL has selinux enabled by default I believe, I > don't know if that could prevent haproxy from sending a signal to another > process. Maybe you can try to stop it (if enabled at all). > > Regards, > Willy > >
