Global log config and syslog facilities are not respected

Help!
1

While installing the newest HAProxy on Debian 12, I discovered that the default global log configuration was ignored.
Specifically, facilities are ignored, all log messages use the daemon facility.
Setting a specific log format did not help.

  • HAProxy version 3.0.0-1~bpo12+1 2024/06/01
  • rsyslogd 8.2302.0
  • Debian 12.5 bookworm

haproxy.cfg

global
  # default provided config
  # log /dev/log local0
  # log /dev/log local1 notice
  # attempt to force extended log format
  log /dev/log format rfc5424 local0
  log /dev/log format rfc5424 local1 notice
  # untouched config below this line; no backends, no listeners nothing extra added

For many years I’ve been using these rsyslog config that was working:

$AddUnixListenSocket /var/lib/haproxy/dev/log

if $syslogfacility-text == 'local0' and $programname startswith 'haproxy' then /var/log/haproxy.admin.log
&stop
if $syslogfacility-text == 'local1' and $programname startswith 'haproxy' then /var/log/haproxy.log
&stop

I’ve noticed that apt provides rsyslog config /etc/rsyslog.d/49-haproxy.conf:

$AddUnixListenSocket /var/lib/haproxy/dev/log

:programname, startswith, "haproxy" {
  /var/log/haproxy.log
  stop
}

I decided to enhance it

#$DebugFile /var/log/rsyslog.debug
#$DebugLevel 2

input(
  type="imuxsock"
  Socket="/var/lib/haproxy/dev/log"
)

if ($programname startswith "haproxy") then {
  if ($syslogfacility-text == "local0") then {
    action(type="omfile" File="/var/log/haproxy.admin.log")

  } else if ($syslogfacility-text == "local1") then {
    action(type="omfile" File="/var/log/haproxy.log")

  ### added for troubleshooting purposes
  } else if ($syslogfacility-text == "daemon") then {
    action(type="omfile" file="/var/log/haproxy.daemon.log")

  # was catching everything, until I added case for the `daemon` facility
  } else {
    action(type="omfile" file="/var/log/haproxy.log")

  }
}

What am I doing wrong?
Why is HAProxy not “splitting” logs into multiple facilities “streams”?
Maybe I do not understand something about HAProxy logging, and real daemon messages always use the daemon facility and ignore globa.log config?
Maybe this is a bug in HAProxy?

I’ve tested rsyslog is catching all facilities just, including messages with facilities sent to “haproxy” syslog socket.

logger -u /var/lib/haproxy/dev/log -t test -p local1.info "This is a test log message"
# received message just fine this tmp filter
#if ($syslogfacility-text == "local1") then {
#  action(type="omfile" File="/var/log/troubleshoot.log")
#}
2

Hi,

When you use log directives in the global section, you need to specify log global on each proxy section (frontend, listen, backend, or even defaults) where you want global log settings to be applied

For many years I’ve been using these rsyslog config that was working:

Do you mean that you were previously using an older HAProxy version and it used to work differently?

Thanks

3

Correct. Older versions (2.2 2.4 and some earlier).

I know how to use and reference log global and that’s not what I was asking.

My question was mainly about at least Haproxy startup sequence logs. Which still are being sent to the daemon facility and not local0 or local1 (whatever is configured).
Are HAProxy service/daemon logs hard-coded to use the daemon facility?
Are log /dev/log ... sections not controlling behavior for startup logs?

I read and probably comprehended 90% of HAProxy docs that mention the word “log”, but was not able to find anything about daemon facility set by default, or what the behavior is.

4

I know how to use and reference log global and that’s not what I was asking.

Alright, I just wanted to make sure since your config snippet didn’t show that part.

My question was mainly about at least Haproxy startup sequence logs. Which still are being sent to the daemon facility and not local0 or local1 (whatever is configured).

If by startup logs you’re referring to warnings/advices that are emitted during config parsing/postparsing stages, then indeed they are only reported on stderr (ie: errors reported through ha_alert(), ha_warning()…), effectively bypassing the logging API because at this stage the config isn’t fully resolved and logging API is not yet ready.

Correct. Older versions (2.2 2.4 and some earlier).

Sorry for insisting but I’m quite confused. What behavior (logs related) did you observe in 2.4 that differs from 3.0?

Regarding the example config you provided, I compared the behavior between 2.2 and 3.0 and was not able to spot a regression thus far (global logs settings ignored unless log global is set on relevant proxies). As for “starting logs”, in 2.2 and 2.4 they were also handled similarly, that is: startup messages are reported on stdout/stderr until the process is fully started, so it’s up to the process manager to properly forward them to a logging or journaling facility if needed. Once the process if fully started, HAProxy will try its best to report messages through the internal logging API, with respect to config file settings.

If you still think there is an issue, any hints (ie: relevant log messages) or additional context would be appreciated.

Thanks

5

Also, if you think you’re facing an unexpected change / regression between older and newer haproxy versions and that haproxy is likely the culprit, please don’t hesitate to file a bug report on Github. Any details that help in order to reproduce/confirm the issue are greatly appreciated (whenever possible)