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

[Susant Sahani]

On Fri, 20 Feb 2015 22:14:20 +0530, Zbigniew Jędrzejewski-Szmek  
<zbyszek at in.waw.pl> wrote:

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

Yes :) . I will start working on it. just have to plug in this patch with  
the new daemon.


Susant