<p dir="ltr"><br>
On Oct 6, 2014 12:54 AM, "Aleksei Besogonov" <<a href="mailto:alex.besogonov@gmail.com">alex.besogonov@gmail.com</a>> wrote:<br>
><br>
> On 05 Oct 2014, at 11:02, Andrei Borzenkov <<a href="mailto:arvidjaar@gmail.com">arvidjaar@gmail.com</a>> wrote:<br>
> > В Fri, 3 Oct 2014 22:55:13 -0700<br>
> > Aleksei Besogonov <<a href="mailto:alex.besogonov@gmail.com">alex.besogonov@gmail.com</a>> пишет:<br>
> ><br>
> >> 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.<br>
> >><br>
> >> As far as I understand the following holds:<br>
> >> - Systemd takes over /dev/log socket which is normally served by rsyslog (or other syslog daemon).<br>
> >> - That’s really required to make journald-based logging transparent and coherent for most use-cases.<br>
> >><br>
> >> 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.<br>
> >><br>
> >> Namespacing each daemon to provide its own /dev tree with custom /dev/log sockets is possible, but impractical.<br>
> >><br>
> >> So I propose the following solution:<br>
> >> 1) Add an option to systemd units to allow passing opened /dev/log sockets to rsyslog (using the usual SOL_SOCKET mechanism).<br>
> > This will make syslog compete with journald for /dev/log, no? So either<br>
> > one will miss some messages?<br>
> 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.</p>
<p dir="ltr">It doesn't work exactly this way, though. systemd cannot "send" individual connections to a single-instance service like journald or syslogd, nor does it know what process is connecting. It only owns the socket path, but as soon as there's *any* activity on it, journald is started and handles everything. Anything more complex than that would require teaching journald *and* syslogd to somehow accept individual client socket FDs...</p>
<p dir="ltr">(Of course, if a different socket was mounted on top of it using namespaces (as suggested earlier), the connections would directly go to the right place...it's not /very/ impractical given that PrivateTemp and ProtectSystem already use private mounts.)</p>