docker-tools: Haproxy-Keepalived not starting haproxy (multiple errors)

Hi I have a couple of errors using this image and I was wondering if it can be updated to support vrrp_track_process haproxy.

Receiving the following error message Keepalived_vrrp[20]: WARNING - the kernel does not support proc events - track_process will not work

Additionally when I specify my own haproxy.conf as stated in the ReadMe section. The Haproxy does not seem to start. Here’s my docker run command

docker run -it -d --cap-add=NET_ADMIN --name haproxy-keepalived --net=host --privileged --userns=host --restart on-failure -v /home/da/.haproxy-keepalived/haproxy:/usr/local/etc/haproxy.cfg:ro -v /home/da/.haproxy-keepalived/keepalived/keepalived.conf:/etc/keepalived/keepalived.conf:ro instantlinux/haproxy-keepalived:latest

If I map /home/da/.haproxy-keepalived/haproxy:/usr/local/etc/haproxy.d haproxy works just fine but then it throws other errors regarding the stats section.

[NOTICE]   (24) : haproxy version is 2.6.0-a1efc04
[ALERT]    (24) : config : Parsing [/usr/local/etc/haproxy.d/haproxy.cfg.old:13]: frontend 'stats' has the same name as proxy 'stats' declared at /usr/local/etc/haproxy/haproxy.cfg:18

My haproxy.conf

  stats socket /var/run/api.sock user haproxy group haproxy mode 660 level admin expose-fd listeners
  stats socket ipv4@*:9999  level admin  expose-fd listeners
  log stdout format raw local0 notice emerg

defaults
  mode http
  timeout client 120s
  timeout connect 5s
  timeout server 10s
  timeout http-request 120s
  log global

frontend stats
   bind *:9000
   stats enable
   stats uri /stats
   stats refresh 10s
   stats auth statsadmin:password

frontend eth-mainnet
   bind *:18545
   mode http
   default_backend eth-mainnet
   timeout client 120s
   timeout http-request 120s

backend eth-mainnet
   option httpchk
   balance roundrobin
   mode http
   timeout server 120s
   server host1 192.168.1.10:8545 check
   server host2 192.168.1.11:8545 check

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Comments: 19 (7 by maintainers)

Commits related to this issue

Most upvoted comments

Keepalived is already current at 2.2.7; I bumped haproxy from 2.6.0 to 2.6.4 (version 2.7 is still in development). The author of keepalived had this to say about track_process in Jan 2021:

Since I do not get the warning, it is difficult to work out why you are getting it.

When I wrote the code, the only way I could discover to be able to detect of the kernel supported the proc events connector was to check if after opening the connector a PROC_EVENTS_NONE message was received. keepalived allows 1/10 second after opening the connector to receive the message and if it is not received in that time logs the warning.

If you run keepalived and add the -D command line option, you should get a log message “proc_events has confirmed it is configured”. With the -D option, do you get such a message, and if so is it before or after the warning message?

You ask two questions: Is the error message correct - you appear to answer that yourself by saying that proc events is working. Should it raise an error rather than a warning - what would you expect keepalived to do differently if it raised an error? It can’t treat it as a config error, since keepalived can’t detect the problem until after it has started running the configuration.

If you build keepalived with the --enable-track-process-debug configure option, and then when you run keepalived add the --debug=OA option, then keepalived will log all messages received on the proc event connector, and it should then be possible to see what it happening.

If we are to investigate the problem beyond that, we will need the following information:

  • What distro you are using and the version
  • The kernel version
  • The kernel configuration
  • Your keepalived configuration
  • The output of: keepalived -v

I hope that helps,

Quentin Armitage

As with the author’s assessment, I cannot reproduce the issue. There is something about the kernel environment you’re running that differs from mine (Ubuntu 20.04, kernel version 5.4.0-121, docker-ce 19.03.13) that is triggering the track_process warning.