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

[Cameron Norman]

El vie, 3 de oct 2014 a las 10:55 , Aleksei Besogonov 
<alex.besogonov at gmail.com> escribió:
> 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 seems annoyingly roundabout. A more straightforward method would 
be to just have rsyslog listen on /dev/log. Obviously that is the 
original method, and journald changed it, and there are reasons for 
that. I am pretty sure one of the main selling points of journald is 
the extreme catch all nature: from syslog messages, to daemon 
stdout/in, to X.Org logs, etc. You can easily access those logs from 
one place and with one set of tools. If the authors wanted syslog 
messages to not be intercepted by journald, I do not think they would 
have had journald listen on /dev/log.

Of course, I can not speak for them, it just seems reasonable that that 
is their feelings about. An alternate reason for how journald works is 
so that all syslogs do not have to re-implement the forwarding logic.

> 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.

Well it already is supposed to listen on /run/systemd/journal/syslog 
like that is /dev/log; that is how the messages are forwarded.

> It would also solve the problems with rsyslog using its own 
> SCM_CREDENTIALS lookups.

Can it not simply recognize it is listening on 
/run/systemd/journal/syslog and skip any kind of extra steps? Or would 
that cause sec issues (e.g. easier to overflow the logs by faking the 
PID / user then writing to the private socket directly)?

Cheers,
--
Cameron Norman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20141004/383b6633/attachment-0001.html>