On Mon, Nov 20, 2017 at 02:07:18PM +0100, Tim Düsterhus wrote: > William, > > Am 20.11.2017 um 13:45 schrieb William Lallemand: > > On Mon, Nov 20, 2017 at 12:55:06PM +0100, Tim Düsterhus wrote: > >> May I suggest the following: If haproxy is *not* compiled with the > >> `USE_SYSTEMD` option it checks for the existence of the `NOTIFY_SOCKET` > >> environment variable and refuses start up, if it is defined. > >> > >> Then `Type=notify` will "just work" if haproxy is compiled with the > >> option and will emit a proper error message if it is not. > >> > > > > If you're suggesting of doing this with -W, it's not a good idea, sometimes > > you > > just want to start HAProxy for tests or development independently of any > > init > > system. > > > > but upon a manual start `NOTIFY_SOCKET` would not be set, no? I made the > suggested change in my working copy to test it: > > > $ sudo env NOTIFY_SOCKET=foo ./haproxy -W -f ./haproxy.cfg > > [ALERT] 000/010000 (22263) : NOTIFY_SOCKET is defined, but haproxy is not > > compiled with USE_SYSTEMD=1. Change Type=notify in your unit file. > > $ sudo env ./haproxy -W -f ./haproxy.cfg > > ^C[WARNING] 323/140435 (22278) : Exiting Master process... > > [ALERT] 323/140435 (22278) : Current worker 22279 left with exit code 130 > > [WARNING] 323/140435 (22278) : All workers are left. Leaving... (130) > > Rebuilding with USE_SYSTEMD and starting with the obviously incorrect > NOTIFY_SOCKET=foo does not prevent the start: > > > $ sudo env NOTIFY_SOCKET=foo ./haproxy -W -f ./haproxy.cfg > > ^C[WARNING] 323/140545 (22703) : Exiting Master process... > > [ALERT] 323/140545 (22703) : Current worker 22704 left with exit code 130 > > [WARNING] 323/140545 (22703) : All workers are left. Leaving... (130) > > $ sudo env ./haproxy -W -f ./haproxy.cfg > > ^C[WARNING] 323/140556 (22722) : Exiting Master process... > > [ALERT] 323/140556 (22722) : Current worker 22723 left with exit code 130 > > [WARNING] 323/140556 (22722) : All workers are left. Leaving... (130) >
What's annoying me is that it's done automatically, I understand how convenient it can be but there might be some usecases where you don't want to enable that, because of a bug, an architecture limitation, or I don't know what. For example some people might want to use some wrapper (a good example is to pass FDs) which will use the sd_notify API, or don't want to use sd_notify for whatever reason you can imagine without rebuilding the whole thing because it's a maintenance cost. -- William Lallemand
