El vie, 3 de oct 2014 a las 10:55 , Aleksei Besogonov <alex.besogonov@gmail.com> escribió:<br>
<blockquote type="cite"><meta http-equiv="Content-Type" content="text/html charset=windows-1252">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).</blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><br><blockquote type="cite">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.</blockquote><div><br></div><div>Well it already is supposed to listen on /run/systemd/journal/syslog like that is /dev/log; that is how the messages are forwarded.</div><br><blockquote type="cite">It would also solve the problems with rsyslog using its own SCM_CREDENTIALS lookups.</blockquote><br><div>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)?</div><div><br></div><div>Cheers,</div><div>--</div><div>Cameron Norman</div>