On Fri, 20 Feb 2015 22:14:20 +0530, Zbigniew Jędrzejewski-Szmek
<zbys...@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 (sus...@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
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
