HAProxy is not linux-specific. We have a POSIX logging facility, and HAProxy works just fine with syslog. If journald has problems with syslog, it's basically journald's problem.
stdout isn't Linux specific, and it's all that's needed.
Edit: solved this one myself with a little research. Systemd also implements the /dev/log Unix domain socket (even with the silly syslog facility names, without needing syslog installed) - so:
global
log /dev/log local0 info
I've added this as an answer on Stack and try and get it into the docs for anyone else.
In the spirit of avoiding code duplication and making daemontools-like process supervisors happy (that includes systemd for these purposes), I greatly appreciate when logs can be sent to stderr
If the admin wants the logs in syslog, 2>&1 | logger or similar. If the admin wants to use multilog, s6-log, or journald, that's also easy.
(For the same reasons, daemons should not include daemonization routines but should run in the foreground. If I want it in the background, I'll arrange for my process supervisor to start it.)
> (For the same reasons, daemons should not include daemonization routines but should run in the foreground. If I want it in the background, I'll arrange for my process supervisor to start it.)
If a daemon doesn't... daemonize into the background, it's no longer a daemon - just a process.
Silly loonix folks.
Please see the FreeBSD program daemon[1] or the FreeBSD handbook section 3.8[2].
The freebsd daemon tool is exactly what I'm talking about. Debian has start-stop-daemon [1]. Process supervisors like daemontools create daemons simply by fork+exec by virtue of the parent process already being a daemon. There's no reason for every service to implement its own daemonization routine.
Edit: solved this one myself with a little research. Systemd also implements the /dev/log Unix domain socket (even with the silly syslog facility names, without needing syslog installed) - so:
I've added this as an answer on Stack and try and get it into the docs for anyone else.