Hello Moemen,
Am 04.10.2017 um 19:21 schrieb Moemen MHEDHBI: > > I am wondering if this is actually an expected behaviour and if maybe > that restart/stop should just shutdown the process and its open connections. > I have made the following tests: > 1/ keep an open connection then do a restart will work correctly without > waiting for existing connections to be closed. You're right, I got confused there. Stop or restart is supposed to kill existing connections without any timeouts, and systemd would signal it with a SIGTERM to the systemd-wrapper: https://cbonte.github.io/haproxy-dconv/1.7/management.html#4 > I think it makes more sense to say that restart will not wait for > established connections. Correct, that's the documented behavior as per haproxy documentation and really the implicit assumption when talking about stopping/restarting in a process management context (I need more coffee). > Otherwise there will be no difference between > reload and restart unless there is something else am not aware of. > If we need to fix 2/, a possible solution would be: > - Set killmode to "control-group" rather than "mixed" (the current > value) in systemd unit file. Indeed the mixed killmode was a conscious choice: https://marc.info/?l=haproxy&m=141277054505608&w=2 I guess the problem is that when a reload happens before a restart and pre-reload systemd-wrapper process is still alive, systemd gets confused by that old process and therefor, refrains from starting up the new instance. Or systemd doesn't get confused, sends SIGTERM to the old systemd-wrapper process as well, but the wrapper doesn't handle SIGTERM after a SIGUSR1 (a hard stop WHILE we are already gracefully stopping). Should the systemd-wrapper exit after distributing the graceful stop message to processes? I don't think so, it sounds horribly. Should the systemd-wrapper expect a SIGTERM after a SIGUSR1 and sends the TERM/INT to its childs? I think so, but I'm not 100% sure. Is that even the issue? We did get rid of the systemd-wrapper in haproxy 1.8-dev, and replaced it with a master->worker solution, so I'd say there is a chance that this doesn't affect 1.8. Niels, I still think what you want is for Ansible to reload instead of restart, but I agree that this is an issue ("systemctl [stop|restart] haproxy" should work regardless of an additional instance that is already gracefully stopping). CC'ing William and Apollon, maybe they can share their opinion? [1] https://cbonte.github.io/haproxy-dconv/1.7/configuration.html#hard-stop-after
