Warning in log since latest update

[chris-1243]

Since the last update of the container, i am getting this warning in my log

14:56:07 
[WARNING] While not properly invalid, you will certainly encounter various problems with such a configuration. To fix this, please ensure that all following timeouts are set to a non-zero value: 'client', 'connect', 'server'.

14:56:07
[WARNING] 096/125607 (1) : Can't open global server state file '/var/lib/haproxy/server-state': No such file or directory

Any idea how to solve those?

[stefgo]

Since the last update of the container, i am getting this warning in my log

14:56:07 
[WARNING] While not properly invalid, you will certainly encounter various problems with such a configuration. To fix this, please ensure that all following timeouts are set to a non-zero value: 'client', 'connect', 'server'.

14:56:07
[WARNING] 096/125607 (1) : Can't open global server state file '/var/lib/haproxy/server-state': No such file or directory

Any idea how to solve those?

same here

[ahmadkakarr]

yes same for me

socket-proxy | 2024-06-20T12:36:44.836766108Z [WARNING] 171/123644 (1) : config : missing timeouts for backend 'docker-events'.
socket-proxy | 2024-06-20T12:36:44.836777173Z | While not properly invalid, you will certainly encounter various problems
socket-proxy | 2024-06-20T12:36:44.836780022Z | with such a configuration. To fix this, please ensure that all following
socket-proxy | 2024-06-20T12:36:44.836782185Z | timeouts are set to a non-zero value: 'client', 'connect', 'server'.
socket-proxy | 2024-06-20T12:36:44.836784325Z [WARNING] 171/123644 (1) : Can't open global server state file '/var/lib/haproxy/server-state': No such file or directory

theses are in the logs of socket-proxy .

these warning are related to ha proxy.

[chris-1243]

As a workaround, the file haproxy.cfg.template in /usr/local/etc/haproxyneeds to be edited as followed:

...
backend docker-events
    server dockersocket $SOCKET_PATH
    timeout server 30s
...

I chose 30 seconds but any value according to your need and haproxy documentation should be fine.

Restart your container and the timeout warning should be removed. This is not persistent if you remove the container. A volume should be created to avoid such scenario.

[mrclschstr]

As a workaround, the file haproxy.cfg.template in /usr/local/etc/haproxyneeds to be edited as followed:

...
backend docker-events
    server dockersocket $SOCKET_PATH
    timeout server 30s
...

This workaround does not work for me. If I adjust the timeout as specified, Traefik can no longer establish a connection to the proxy. I may have made a mistake in the configuration...

[chris-1243]

[WARNING] While not properly invalid, you will certainly encounter various problems with such a configuration. To fix this, please ensure that all following timeouts are set to a non-zero value: 'client', 'connect', 'server'.

The warning comes due to a zero value. Maybe try a greater value. See haproxy docs

[scrapix]

is there a way to set this through env variables?

[MikeDeltaHH]

same here

[WARNING] 027/104750 (1) : Can't open global server state file '/var/lib/haproxy/server-state': No such file or directory

[TheDude1972]

I have the same issue, I also added to the environment variables in my docker compose the following:

• PROXY_READ_TIMEOUT=240
• PROXY_CONNECT_TIMEOUT=60
• PROXY_SERVER_TIMEOUT=300

But this doesn't remove the errors. anyone have an idea how to solve the log errors as mention in above posts?

[kikearciniegas]

I've just done a fresh installation with latest (0.3.0) version and still the two reported errors appear in the log:

[WARNING] 118/213144 (1) : config : missing timeouts for backend 'docker-events'.
   | While not properly invalid, you will certainly encounter various problems
   | with such a configuration. To fix this, please ensure that all following
   | timeouts are set to a non-zero value: 'client', 'connect', 'server'.

and

[WARNING] 118/213144 (1) : Can't open global server state file '/var/lib/haproxy/server-state': No such file or directory

Despite these errors, the service seems to be working fine and the container reports as healthy.

#curl http://localhost:2375/version | jq

{
  "Platform": {
    "Name": "Docker Engine - Community"
  },
  "Components": [
    {
      "Name": "Engine",
      "Version": "28.1.1",
      "Details": {
        "ApiVersion": "1.49",
        "Arch": "amd64",
        "BuildTime": "2025-04-18T09:52:57.000000000+00:00",
        "Experimental": "false",
        "GitCommit": "01f442b",
        "GoVersion": "go1.23.8",
        "KernelVersion": "6.1.0-34-amd64",
        "MinAPIVersion": "1.24",
        "Os": "linux"
      }
    },
    {
      "Name": "containerd",
      "Version": "1.7.27",
      "Details": {
        "GitCommit": "05044ec0a9a75232cad458027ca83437aae3f4da"
      }
    },
    {
      "Name": "runc",
      "Version": "1.2.5",
      "Details": {
        "GitCommit": "v1.2.5-0-g59923ef"
      }
    },
    {
      "Name": "docker-init",
      "Version": "0.19.0",
      "Details": {
        "GitCommit": "de40ad0"
      }
    }
  ],
  "Version": "28.1.1",
  "ApiVersion": "1.49",
  "MinAPIVersion": "1.24",
  "GitCommit": "01f442b",
  "GoVersion": "go1.23.8",
  "Os": "linux",
  "Arch": "amd64",
  "KernelVersion": "6.1.0-34-amd64",
  "BuildTime": "2025-04-18T09:52:57.000000000+00:00"
}

Following the recommendation posted by @chris-1243, I've managed to "fix" the first error, regarding the zero-value timeouts for 'client', 'connect', 'server'. I went into the container and copied the contents of the /usr/local/etc/haproxy/haproxy.cfg.template into a local file where I could edit:

backend docker-events
    server dockersocket $SOCKET_PATH
    timeout server 30s

and bind the volume to make it a persistent change

volumes:
    - ~/.docker/dsocket-proxy/data/haproxy.cfg.template:/usr/local/etc/haproxy/haproxy.cfg.template
    - /var/run/docker.sock:/var/run/docker.sock

Now, for the second error, I went again into the container and verified that the /var/lib/haproxy/server-state file did in fact not exist.. so i created an empty file and the error disappeared.

touch /var/lib/haproxy/server-state

To make it stick, I created locally the empty file

touch ~/.docker/dsocket-proxy/data/server-state

and a new bind, so my volumes look like

volumes:
    - ~/.docker/dsocket-proxy/data/haproxy.cfg.template:/usr/local/etc/haproxy/haproxy.cfg.template
    - ~/.docker/dsocket-proxy/data/server-state:/var/lib/haproxy/server-state
    - /var/run/docker.sock:/var/run/docker.sock

I restarted the container and these two errors are gone. The container reports healthy, and it seems to work without issues... I'm monitoring for any errors and hope these workarounds don't generate further problems. If you have any comments or recommendation, leave a note.

[Qtax]

[WARNING] While not properly invalid, you will certainly encounter various problems with such a configuration. To fix this, please ensure that all following timeouts are set to a non-zero value: 'client', 'connect', 'server'.

The warning comes due to a zero value. Maybe try a greater value. See haproxy docs

The timeout for events was set to 0 on purpose in PR #98. The motivation was that the /events route is "meant to stream forever" without timing out.

[Qtax]

Made my own simplified version based on latest HAProxy 3.2 LTS which fixes all of this (and is only two files):
https://github.com/Qtax/docker-socket-proxy

[esabol]

I've submitted two pull requests to address these warnings. Can anyone confirm these changes and/or approve my PRs?

[esabol]

PR #163 was merged. That means the "Can't open global server state file '/var/lib/haproxy/server-state': No such file or directory" message should be gone now. You can still mount your own server-state file inside the container, but, for those who don't want the bother of doing that, an internal-to-the-container server-state file is now provided to silence that message.

PR #164 was closed without merging. It was determined that "timeout server 0" was intentional and changing it to a non-zero value would actually detract from the image's usefulness. We're going to have to live with the "While not properly invalid, you will certainly encounter various problems with such a configuration. To fix this, please ensure that all following timeouts are set to a non-zero value: 'client', 'connect', 'server'" warnings.

[chris-1243]

Thanks for the feedback. I am going to close the issue as it is solved.