Created attachment 185247 [details]
patch for net/haproxy
I think there's a bug in the RC script that makes it impossible to use HAProxy's "hard stop" feature where it *immediately* quits and closes all established connections.
The RC script always sends the USR1 signal to HAProxy, even if the force prefix is used (but in this case the TERM signal should be used). That's because the $rc_force variable is not available in the context. (See /etc/rc.d/bgfsck for another working example.)
I've attached patches for both net/haproxy and net/haproxy-devel.
Created attachment 185248 [details]
patch for net/haproxy-devel
Well, force prefix means to bypass haproxy_enabled check, not to send some other signal.
Hi Dmitry, I get your point, the man page does not mention this use-case.
That being said, this doesn't mean it's wrong to use it to "force" a
For example, /etc/rc.d/bgfsck  is also using the "force" prefix
for something that is not described in the rc(8) man page.
Please note that the current HAProxy RC script already *tries* to do
exactly what my patch finally makes possible . So I am not trying
something *new*, but instead fixing a bug in the RC script.
I think this is required, because HAProxy provides two methods to stop
it and expects the admin to decide which method should be used .
In it's current state the HAProxy RC script *always* uses the graceful
stop, which may lead to a *very* long downtime of HAProxy, because it
continues to process existing connections until they close. Really not
suitable for many production sites. On literally all production sites
I'd want to use HAProxy's "hard stop".
Do you see another way of getting this feature into the RC script?
Shall we add a "hardstop" command instead?
(see: 4. Stopping and restarting HAProxy)
For bgfsk that makes sence: in someone runs script with forcestart (usually means interactive), then set delay=0.
As for haproxy, (ab)using forcestop is a mistake.
Yes, I know about this feature of haproxy and I thing it should be implemented via another rc command, "hardstop" is a good proposal IMHO.
Do you want to submit a patch for this?
I'll provide a patch for an additional "hardstop" RC command.
Created attachment 185418 [details]
new patch for net/haproxy
Created attachment 185419 [details]
new patch for net/haproxy-devel
> Yes, I know about this feature of haproxy and I thing it should
> be implemented via another rc command, "hardstop" is a good proposal IMHO.
I've attached two new patches to add the new "hardstop" rc command.
Besides that it also replaces the nonfunctional check for $rc_force with a new default value for $sig_stop.
What is haproxy_sig_stop? Do you propose another variable for rc.conf?
I am attaching a bit modified version of your patch which also adds "hardreload" command. What do you think?
Created attachment 185436 [details]
The same patch with hardreload command added
> I am attaching a bit modified version of your patch which also
> adds "hardreload" command. What do you think?
Looks good to me.
A commit references this bug:
Date: Wed Aug 16 08:06:58 UTC 2017
New revision: 448026
Add hardstop/hardreload commands to rc script (to stop/reload haproxy without
waiting for existing connections to close).
Submitted by: Frank Wall <email@example.com>
I committed the change.
Thanks for submission.
No port revision bump? That ends up with a situation where some people will have the newer script while others will not until the next version is released (or the revision bumped for another reason).
Well, yes, I am not a big fan of bumping portrevision for such minor changes: since nobody complained about missing hardstop/hardreload for a long time, I decided it is not a big deal for them to wait for another haproxy version.
I bumped it FWIW since you asked :)
Thank you. I was really just asking, because multiple committers have multiple opinions about these things. It's nice to talk about to the reasoning to learn more. :)