[systemd-devel] [PATCH] journald: Introduce RFC 5424 syslog

[Zbigniew Jędrzejewski-Szmek]

On Thu, Feb 19, 2015 at 12:10:04PM +0100, Lennart Poettering wrote:
> On Thu, 19.02.15 13:28, Susant Sahani (susant at redhat.com) wrote:
> 
> > This patch adds support for RFC 5424 syslog format to journald. Journald
> > can now forward logs to a multicast UDP group.
> > 
> > RFC 5424 format:
> > <PRI>VERSION SP TIMESTAMP SP HOSTNAME SP APP-NAME SP PROCID SP MSGID SP
> > [SD-ID]s SP MSG
> 
> Hmm, wasn't the last proposal we discussed to do this in an auxiliary
> daemmon, possibly in systemd-journal-upload or so, but not in
> journald?
We discussed both...

>From http://lists.freedesktop.org/archives/systemd-devel/2014-December/026202.html:

  > Having this in systems-journald and extend the forward to syslog config with the target
  > host was our expectation anyway. 
  The difference is in how the logs are accessed: if journald itself does the jobs,
  they would be forwarded "live". If anything else, the uploader would be a client
  which reads the files in /var/log/journal/. The are advantages to both solutions:
  the first one might be more robust if writing the logs fails or stops for whatever
  reason. The second one will probably send more logs, because sending of logs can
  be delayed until the network is up. In the second version, the uploader can also
  forward logs from other machines (containers). Now that I spelled it out, the second
  version seems nicer.

After rereading the old discussion, I have to agree with Lennart that
*not* doing it in systemd-journald directly seems better. Reasons below...

> I see two problems with journald: first of all, for security reasons I
> am conservative about making it deal with the network
> directly. Opening up such a basic daemon to the network is a something
> i'd prefer to avoid.
I don't see how opening a socket to send UDP messages is dangerous.
But yeah, sd-journald runs as root with full
capabilities. sd-journal-upload runs as an unprivileged user.

> The other thing is that journald runs really really early during boot,
> at a time where the network is unlikely to be up. This means that
> early boot msgs could never be delivered via syslog...
And this is a convincing argument for me. Essentially, by doing it in a
separate tool we get reliability which we could never have with journald.

> I'd really prefer a scheme where this syslog broadcaster can be run
> relatively late at boot and where it tries to repeatedly send the
> messages, until sendmsg() actually succeeds. i.e. using the journal
> cursor logic it would not send a log message until the point where the
> previous message was delivered with a successful sendmsg(). Wth such a
> scheme all early boot msgs would be dumped on the network the moment
> the network is up.
> 
> Zbigniew, do you have more ideas about this?
Yep, sounds right.

Susant, sorry! I think we should at look at adding this to sd-journal-upload,
or a separate similar tool which reuses some code of sd-journal-upload.

Zbyszek