On Mon, Nov 20, 2017 at 11:39:53AM +0100, Tim Düsterhus wrote: > William, > > Am 20.11.2017 um 10:59 schrieb William Lallemand: > > I think a good way to activate this feature will be to use it with a -Ws > > command > > line option instead of changing the behavior of the -W one. > > > > This way we can integrate the -Ws command in the unit file without changing > > the > > behavior of the normal option. > > Just to make sure you understood correctly: The patch does not really > modify the behaviour of the normal option. `sd_notify(3)` is documented > to just do nothing if the `NOTIFY_SOCKET` environment variable is not set: > > > RETURN VALUE > > On failure, these calls return a negative errno-style error code. If > > $NOTIFY_SOCKET was not set and hence no status data could be sent, 0 > > is > > returned. *snip*
I hope it uses non-blocking sockets :-) Well, in this case why not, but we will have to document properly how to configure the systemd unit file depending of how it's built. > The only difference I can see is that haproxy will fail to start for a > different reason (use of undefined option, instead of not sending the > READY=1 notification) if one uses the provided unit file *without* > compiling with USE_SYSTEMD. > Thus in my opinion a separate -Ws option will increase cognitive load (which > option should I use?) for next to no benefit. Well, it's a matter of documentation, and a line to add in the usage() function IMO. This option ensures one thing, if the -Ws option is used in the unit file by default, and if by any chance a binary was not built with the right USE_SYSTEMD=1 option, it won't work at all preventing useless bug reports. We can even put a Warning when trying to use this option when it's not built. -- William Lallemand
