Fabio is not handling SIGHUP (HUP) signal properly - it dies

[sielaq]

Usually HUP signal is being used to reload configuration (like in consul)
(for example can be used in systemd when reloading/upgrading package) .

Kindly please make fabio survive at least,
or in best scenario reload config when HUP signal is detected.

[magiconair]

That is somewhat intentional. The architecture isn’t designed for hot reload since that’s something that shouldn’t happen often enough to need this. Which problem are you trying to solve?

[tino]

"shouldn't happen often enough" still means => I need to find time when I can incur downtime (albeit short). I agree with sielaq that this is the "default" behaviour of most daemon processes.

I would for example use it when adding new listening ports for an TCP proxy implementation, FTP for example.

Of course this can be done staggered when multiple fabio instances are used, but being able to combine with nomad + templating and SIGHUP would make it also possible on a single instance.

[magiconair]

I’m not saying it can’t happen but this is not a trivial change and if you need to do this only once every three months then this would have to wait. Especially, dynamic listeners is something I’d like to have but they should show up when a service registers the port and disappear with the last instance.

[magiconair]

Also downtime is a couple of seconds

[aaronhurt]

This is indeed not trivial and even load balancers that implement reload still have downtime. HAProxy is a perfect example where you can reload an entire configuration but there is much more to consider. What happens to existing connections if the route to them is deleted? What about websockets and other long-running connections that prevent a graceful shutdown and reload? That's just a few of the issues but those were enough to make us restart HAProxy vs reload anytime the configuration changed and live with a few possible dropped connections between the anycast instances.

True zero downtime reload isn't in the scope of the load balancer process itself. There is a good blog post from Yelp about how they got a real zero downtime reload working with os level connection queuing. The same should in theory work with fabio or any other network service.

[tino]

Agreed

[sielaq]

true, but then it shouldn't just die.
Rather informing [INFO] restart/reload has to be done in a controlled way. Application will not be reloaded.
and let fabio still running.Otherwise we have to overwrite the daemon's behavior in systemd for something hack'y like:

ExecReload=/bin/true

[magiconair]

How often do you have to apply changes to the config that require a restart? If you do a restart with a graceful period of 1 sec fabio will have restarted within 2 sec. How much of an impact is that?

[sielaq]

As I said, it is not always about changing config - it about upgrading fabio in a Debian/Ubuntu way.
Since we do Debian wrapper package for Fabio, each installation triggers (by default, not by us)
service reload - which makes Fabio die (since it doesn't handle with HUP signal).

As I said - we can overwrite systemd behavior - but better is to align all "perfect trinity" 🙏 behavior (consul, nomad, fabio) - Fabio is behaving differently here.

[magiconair]

It could ignore the HUP signal. For now I suggest to change the systemd config