[systemd-devel] A way to better integrate rsyslog into systemd?

[Lennart Poettering]

On Sun, 05.10.14 14:54, Aleksei Besogonov (alex.besogonov at gmail.com) wrote:

> On 05 Oct 2014, at 11:02, Andrei Borzenkov <arvidjaar at gmail.com> wrote:
> > В Fri, 3 Oct 2014 22:55:13 -0700
> > Aleksei Besogonov <alex.besogonov at gmail.com> пишет:
> > 
> >> 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).
> > This will make syslog compete with journald for /dev/log, no? So either
> > one will miss some messages?
>
> No, it won’t. Systemd owns the /dev/log socket and accepts
> connections to it as usual. However, if a "ForwardLogSocket=/path"
> option is set for a certain service then systemd connects to this
> socket and sends the client connection over it.

There aer no "client connections" for syslog really. It's an
AF_UNIX/SOCK_DGRAM socket, i.e. connection-less. While in theory
there's a connection-ful mode, it's not really that great a choice
(and we don't support it in systemd) since it loses global ordering of
log messages, for zero benefit.

There can only be one process reading off the socket. It's either
journald or rsyslog. It cannot be both. If both listen and read of it,
it's essential random which process gets a message, and the other one
will not see it.

Lennart

-- 
Lennart Poettering, Red Hat