Hi Willy,
Op 25-11-2017 om 8:08 schreef Willy Tarreau:
Hi Pieter,
We found that it's the first fork_poller() placed after the fork which
fixed the issue but that makes absolutely no sense since the next thing
done is exit(), which also results in closing the kqueue fd! So unless
there's something in at_exit() having an effect there, it really doesn't
make much sense and could imply something more subtle. Thus my question
is : do you have a real use case of master-worker+daemon on freebsd or
can we release like this and try to fix it after the release ? It's
about the last rock in the shoe we have.
Thanks,
Willy
Personally i do not need master-worker at present time..
But running it with 'quiet' configuration option or -q startup parameter
is something that imho does need to be checked though. It seems to
always die when doing so after sending a USR2, also without using daemon
mode.!. (i didn't quite specify that fully in the other mail/thread..)
-- Some background info --
My usecase mainly revolves around running haproxy on pfSense (a FreeBSD
firewall distribution), im using and maintaining the haproxy 'package'
for it.
All services there are 'managed' by php and shell scripts. When users
modify the configuration in the webgui and press 'apply' i need to
restart haproxy and show any warnings/alerts that might have been returned.
This has worked and still works fine without requiring master-worker.
So no problem or missing advantages for myself or users of that package
if haproxy 1.8 gets released as it currently is.
I'm not sure if other folks are using some service management tool like
systemd on FreeBSD... But i guess time will tell, i'm sure 1.8 wont be
the last release ever so fixes when required will come :).
Regards,
PiBa-NL / Pieter
