On 05 Oct 2014, at 11:02, Andrei Borzenkov <arvidj...@gmail.com> wrote:
> В Fri, 3 Oct 2014 22:55:13 -0700
> Aleksei Besogonov <alex.besogo...@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.
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
