>> Hi, >> >>> 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 > OK so now that I've applied all of Lukas recos (I kept the -x added ) :
* I don't see any ALERT log anymore.. Only the WARNs Jan 05 14:47:12 hostname systemd[1]: Reloaded HAProxy Load Balancer. Jan 05 14:47:12 hostname haproxy[59888]: [WARNING] 004/144712 (59888) : Former worker 61331 exited with code 0 Jan 05 14:47:25 hostname haproxy[59888]: [WARNING] 004/144712 (59888) : Reexecuting Master process Jan 05 14:47:26 hostname systemd[1]: Reloaded HAProxy Load Balancer. Jan 05 14:47:26 hostname haproxy[59888]: [WARNING] 004/144726 (59888) : Former worker 61355 exited with code 0 * I still observe the same issue (here doing an ab during a rolling/upgrade of my test app => consequently triggering N reloads on HAProxy as long as the app instances are created/destroyed). $ ab -n100000 http://test-app.tld/ (..) Benchmarking test-app.tld (be patient) apr_socket_recv: Connection reset by peer (104) Total of 3031 requests completed Pierre
signature.asc
Description: OpenPGP digital signature
