On Tue, Apr 30, 2019 at 01:47:13AM +0200, William Lallemand wrote: > the systemd API > is limited and it's not possible to report a fail during a reload with > sd_notify.
Anyway a service manager which requires daemons to stay in foreground, does not allow processes to be replaced, and relies on asynchronous and unidirectional signal delivery to perform critical actions such as config updates is obviously misdesigned and can only result from the lack of experience of production servers and people making them work every day. I tend to think that the only longterm solution to work around all the systemd imposed mess is to have haproxy become its own service manager. It is a shame as it significantly complicates haproxy management on Linux compared to sane operating systems, but I'm having a hard time accepting that haproxy has become less reliable on Linux due to systemd. We've already made progress in this direction with the master-worker model, but we need to go further and make haproxy be able to serve as a client to talk to an existing master and return relevant status codes. This way we'll be able to emulate the start/reload/restart operations that are performed on sane systems and gain reliability again, at the expense of using a total of 3 processes talking to each other during a reload instead of just one. The advantage is that it should work on other operating systems too if needed. In my opinion this is something we seriously need to work on for 2.1, and address remaining limitations (doubled memory usage and CLI being closed on reload). By the way, does systemd support passing actions on stdin and getting the result on stdout ? Given that the master process is forced to stay in foreground, at least we could have the equivalent of the CLI on stdio used as a "console" and not require a third process to talk to it. Willy
