On Thu, Oct 12, 2017 at 05:50:52PM +0300, Apollon Oikonomopoulos wrote: > > > > One helpful feature I read in the documentation is the usage of the > > sd_notify(.. "READY=1"). It can be useful for configuration files that > > takes > > time to process, for example those with a lot of ssl frontends. This signal > > could be send once the children has been forked. > > > > It's difficult to know when a reload is completely finished (old processes > > killed) in case of long TCP sessions. So, if we use this system there is a > > risk > > to trigger a timeout in systemd on the reload isn't it? > > The Reload timeout is apparently controlled by TimeoutStartSec in > systemd. > > > feature for the reload, it should be done after the fork of the new > > processes, > > not after the leaving of the old processes, because the processes are > > ready to > > receive traffic at this stage. > > That's true. OTOH the problem with haproxy-systemd-wrapper is that once > it re-exec's itself it loses track of the old processes completely > (IIRC),
That's right, but we won't fix it in the wrapper, the current architecture doesn't allow it easily, and it's not reasonable to backport the master-worker in a stable branch. Those problems will be fixed with the master-worker in 1.8. > combined with the fact that old processes may eat up a lot of > memory. There are cases where you would prefer breaking a long TCP > session after 30s if it would give you back 2GB of RSS, to having the > process lying around just for one client. Sure, that can be done in the haproxy config file with the hard-stop-after keyword. > > Are there really advantages to letting know systemd when a reload is > > finished > > or when a process is ready? > > Yes, there are. systemd will only perform a single operation on a unit > at a time, and will queue up the rest. When you inform systemd that > something (startup/reload) is in progress, it will not let any other > action happen until the first operation is finished. Now it's trivial to > issue a ton of reloads in a row that will leave a ton of old processes > lying around until they terminate. I don't think you can, either with the master-worker or the wrapper, it was one of the problems we had in the past. The master-worker waits to be ready to handle the signals, and the wrapper waits for a pipe to be closed on the children side to handle signals. > The other advantage with Type=notify services is that systemd will wait > for READY=1 before starting units with After=haproxy (although HAProxy > is really a "leaf" kind of service). > That's interesting, nobody ever ask for that, but I see a few cases where that can be useful. > Note that the dependency is really thin, and you can always make it a > compile-time option. > > Regards, > Apollon Cheers, -- William Lallemand
