> Hi, > >>> $ cat /usr/lib/systemd/system/haproxy.service >>> [Unit] >>> Description=HAProxy Load Balancer >>> After=syslog.target network.target >>> >>> [Service] >>> EnvironmentFile=/etc/sysconfig/haproxy >>> ExecStartPre=/usr/sbin/haproxy -f $CONFIG -c -q >>> ExecStart=/usr/sbin/haproxy -W -f $CONFIG -p $PIDFILE $OPTIONS >>> ExecReload=/usr/sbin/haproxy -f $CONFIG -c -q >>> ExecReload=/bin/kill -USR2 $MAINPID >>> Type=forking >>> KillMode=mixed >>> Restart=always >> Your systemd configuration is not uptodate. >> >> Please: >> - make sure haproxy is compiled with USE_SYSTEMD=1 >> - update the unit file: start haproxy with -Ws instead of -W (ExecStart) >> - update the unit file: use Type=notify instead of Type=forking > In fact that should work with this configuration too. OK, I have to admit that we started experiments on 1.8-dev2, at that time I had to do that to make it work. And true, we build the RPM and so didn't notice there was some updates after the 1.8.0 release for the systemd unit file provided in contrib/. Currently recompiling, bumping the release on CI / dev environment etc... > >> We always ship an uptodate unit file in >> contrib/systemd/haproxy.service.in (just make sure you maintain the >> $OPTIONS variable, otherwise you are missing the -x call for the >> seamless reload). > You don't need the -x with -W or -Ws, it's added automaticaly by the master > during a reload. Interesting. Is this new ? Because I noticed it was not the case at some point. >> Run "systemctl daemon-reload" after updating the unit file and >> completely stop the old service (don't reload after updating the unit >> file), to make sure you have a "clean" situation. >> >> I don't see how this systemd thing would affect the actual seamless >> reload (systemd shouldn't be a requirement), but lets fix it >> nonetheless before continuing the troubleshooting. Maybe the >> regression only affects non-systemd mode. > Shouldn't be a problem, but it's better to use -Ws with systemd. > > During a reload, if the -x fail, you should have this kind of errors: > > [WARNING] 004/135908 (12013) : Failed to connect to the old process socket > '/tmp/sock4' > [ALERT] 004/135908 (12013) : Failed to get the sockets from the old process! > > Are you seeing anything like this? Yes, in > 1.8.0. If I rollback to 1.8.0 it's fine on this aspect.
I'll give updates after applying Lukas recommendations. Pierre
signature.asc
Description: OpenPGP digital signature
