Hello,
2017-11-21 8:39 GMT+01:00 William Lallemand <[email protected]>: > On Tue, Nov 21, 2017 at 07:16:19AM +0100, Willy Tarreau wrote: >> >> I really don't like this. My fears with becoming more systemd-friendly >> was that we'd make users helpless when something decides not to work >> just to annoy them, and this reports seems to confirm this feeling :-/ >> >> Tim, have you seen this message about a "hold-off timer over" being >> displayed at the same second as the startup message ? Isn't there a >> timeout setting or something like this to place in the config file ? >> And is there a way to disable it so that people with huge configs >> are still allowed to load them ? >> > > There is indeed a timeout value, which is configurable in the unit file, the > default value is 100ms. > > https://www.freedesktop.org/software/systemd/man/systemd.service.html#RestartSec= > > > There is also the start one there: > > https://www.freedesktop.org/software/systemd/man/systemd.service.html#TimeoutStartSec= > > I suggest we configure it to a greater value per default, it can be set to > infinity too, but I don't like the idea. That's not it, the hold-off timer is only a consequence of this problem. I believe the notification does not work in my case, which is why for systemd haproxy did not start correctly which is why systemd continues to restart haproxy. I found the root of the issue: the "daemon" keyword in the global configuration section. We need to remove "daemon" from the configuration for systemd to mode work correctly in notify mode. We can override the "daemon" keyword in the configuration by passing -db to haproxy. Adding it to the unit file fixes the issue even if they keyword is in the configuration (so we pass "-Ws -db" ). "-Ws -db" along with a note in the documentation that "daemon" may be ignored in systemd mode seems like a good compromise here? I will send an RFC patch shortly. Regards, Lukas
