On Mon, Apr 29, 2019 at 08:51:58PM +0200, Tim Düsterhus wrote: > > One issue here is that this problem was not detected by the > configuration check (for obvious reasons), most problems (fat fingered > configuration) are detected using the check. > > Regarding the sd_notify integration: > > I guess this is a 'bug' within the sd_notify integration. HAProxy > reports READY=1 back to systemd, even if the startup failed and it falls > back to waitpid mode. Possibly the ERRNO= return should be used here (I > did not check whether that actually does the right thing): > https://www.freedesktop.org/software/systemd/man/sd_notify.html#ERRNO=%E2%80%A6 >
Unfortunately this is not a bug, I made some test a while ago, the systemd API is limited and it's not possible to report a fail during a reload with sd_notify. Maybe I was doing it wrong, but the only way I found to do it is to return a bad status code from the command executed by ExecReload. The problem with launching an haproxy -c for that, is that the configuration is parsed twice (once for the -c, once during the reload) which can be a problem if you have a lot of SSL certificates for example. Another problem is that it's possible that the -c will succeed and the reload will fail. The two commands aren't atomics so there is a small window where you could have 2 differents configuration files between the -c and the reload. The solution I would implement in the future is a synchonous state on the master CLI during a reload. We could have an `haproxy -reload` command, which will connect to the master CLI, ask for a reload, and return the status code corresponding to the state of the reload. The current architecture of the master CLI doesn't allow that, because the re-execution of the process close the connection to the master CLI. -- William Lallemand
