Haproxy: when haproxy fails to start and is configured for syslog, the startup errors go (still) to stderr

[f1-outsourcing]

when haproxy fails to start and is configured for syslog, the startup errors go (still) to stderr. For me it would be easier to track changes if startup failures at this stage were also logged to syslog.

  # http://cbonte.github.io/haproxy-dconv/2.2/configuration.html#8.5

  log xxx.local:514 local0

haproxy 2.2

[f1-outsourcing]

That also goes for when you have an error in your haproxy.cfg file and you do a reload. This is also logged to stderr instead of syslog.

[lukastribus]

I disagree.

All startup and configuration errors need to go to stderr, because when the startup fails, you want to see why it fails from the service manager (or when manually launching, on your tty).

What belongs into syslog are runtime events, not startup errors.

[f1-outsourcing]

I am not having that much experience with container environments. But in my case I do not have easy access to stdout/stderr.
I also think, this is a decision for the one who created the haproxy.cfg file. I consider him wise enough to decide where he wants to view this.

[TimWolla]

Startup can also fail if the configuration is not valid for whatever reason. You can't configure anything with an invalid configuration, so you can't configure the logger either. So by not sending these startup messages to stderr you would get erratic behavior depending on what exactly causes HAProxy to fail startup.

[lukastribus]

Issues regarding startup and configuration cannot rely on high layer function such as logging to a remote socket, that would just be a catch 22.

Container folks usually want everything on stderr and stdout, which is why we now can log even runtime events to those fd's.