On Tue, Oct 01, 2019 at 12:41:33AM +0200, Tim Duesterhus wrote:
> Willy, William, Vincent,

Hello Tim,

> apparently systemd's behaviour changed regarding reloads. When one of the
> reload commands fails it apparently starts stopping the service.
> At first I thought it was some bad systemd configuration on my end, but
> after seeing HAProxy die on me for the bazillionth time because of a bad
> configuration I started investigating.
> I cannot reproduce the issue on my Ubuntu 16.04 with systemd 229. I can
> reproduce it on a Debian Buster machine with systemd 232.

Looks like a bug to me, they can't break the compatibility like that.

> I'm not fully convinced that this patch:
> - is correct, because I am not sure whether "waitpid" mode is doing
>   something bad. That's why I Cc William.

It's not doing something bad, but it's not convenient, and there is a warning 
on the CLI.

> - is the best solution. It certainly isn't because the `reload` succeeds,
>   while actually it does not. Maybe there's some systemd knob that
>   improves on that behaviour. I Cc Vincent as the Debian maintainer of
>   HAProxy, because that's the thing I run in production.

We must not do that. I don't want to change these reload lines until we have a
synchronous reload command which returns a failure. It's going to be worst if we
remove the -c line, I know it takes time to check the conf, but it's the only
way to return a failure. Only people who knows what they are doing should remove
it, we shouldn't do it by default.

> So basically this email is to bring attention to the issue and to confirm
> it's not just me who is holding systemd wrong (I'm seeing that same issue
> with Debian's nginx package, though). This patch is absolutely RFC only
> and probably should not be merged as is without some discussion. It's
> certainly the longest commit message I ever wrote ...
> Best regards
> Tim Düsterhus

Found this in the Debian BTS:


Looks like this exact bug.


William Lallemand

Reply via email to