With all the recent noise about systemd abusing its position with the way it
takes over logging I’ve been thinking about a way to solve it.
As far as I understand the following holds:
- Systemd takes over /dev/log socket which is normally served by rsyslog (or
other syslog daemon).
- That’s really required to make journald-based logging transparent and
coherent for most use-cases.
However, it creates a problem for log-heavy applications, because of additional
roundtrips between processes. So far I’ve heard people actually using
LD_PRELOAD tricks to hack around applications opening the /dev/log file inside
the syslog(2). As far as I understand, it’s also not really configurable - the
'/dev/log’ string is hardcoded into various libcs (e.g.:
http://git.musl-libc.org/cgit/musl/tree/src/misc/syslog.c). Recent versions of
rsyslog can directly read journald files. But that’s still suboptimal solution,
because it introduces an unnecessary layer.
Namespacing each daemon to provide its own /dev tree with custom /dev/log
sockets is possible, but impractical.
So I propose the following solution:
1) Add an option to systemd units to allow passing opened /dev/log sockets to
rsyslog (using the usual SOL_SOCKET mechanism).
2) Add the corresponding functionality to rsyslog. It should listen on a
special socket (perhaps /run/rsyslog/socket_server ?) and treat all the
incoming sockets as if they were accepted from /dev/log.
It would also solve the problems with rsyslog using its own SCM_CREDENTIALS
lookups.
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
