Hi Tim, 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* > 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.
But from what you explained (or at least what I understood), the mode specified in the unit file needs to match the build option. This is not really cool, especially for users who want to replace their distro's binary without having to modify the settings. Like William, I tend to think that it's best if the behaviour can be changed at runtime with an option. In my opinion it's less cognitive load to know that when you build, the existing unit file will automatically pass the appropriate option for its own settings (ie -Ws when using type=notify or -W for type=forking for example). Willy
