I found what is adding these directives to the config file!
The behavior is hard-coded in /usr/local/pkg/haproxy/haproxy.inc which is what generates /var/etc/haproxy/haproxy.cfg
Line 727
function write_backend($configpath, $fd, $name, $pool, $backendsettings) {
...
Line 1006 (always executes, not subject to any conditional statements)
fwrite ($fd, "\tload-server-state-from-file\tglobal\n");
Line 1520
function haproxy_writeconf($configpath) {
...
Line 1612 (always executes, not subject to any conditional statements)
fwrite ($fd, "\tserver-state-file /tmp/haproxy_server_state\n");
Line 2498
function haproxy_check_run($reload) {
...
Lines 2507-2508 (executes if haproxy is running when a reload is requested, which is almost always true)
if ($reload) {
if (haproxy_is_running()) {
$r = haproxy_socket_command("show servers state");
file_put_contents("/tmp/haproxy_server_state", $r);
}
These lines result in the following behavior:
Whenever HAProxy's settings are saved using the GUI, the server-state-file directive is added to the global section of the resulting config file.
Whenever HAProxy's settings are saved using the GUI, the load-server-state-from-file directive is added to each backend of the resulting config file.
Whenever HAProxy reloads, it writes the backend server state to /tmp/haproxy_server_state, and due to the server-state-file directive, it then always reads and applies the previous state data.
There is no GUI text that mentions that this behavior is hard-coded, and there is no way to disabled it other than commenting out the lines (1006, 1612, 2507, 2508) in haproxy.inc that are responsible for adding the directives to the config file.
The GUI option Reload behaviour is responsible for the directive hard_stop_after which is for a different behavior.
I've added these findings to the redmine.
