<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">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.: <a href="http://git.musl-libc.org/cgit/musl/tree/src/misc/syslog.c">http://git.musl-libc.org/cgit/musl/tree/src/misc/syslog.c</a>). 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.</body></html>