Re: Joey Hess is out?
Am 2014-11-17 16:15, schrieb The Wanderer:
Part of what I found reassuring about the statements that Debian's
default systemd configuration stores the journal's binary logs only
in
memory was the idea that it would not be (needing to) write the log
data
separately to the binary format, or possibly even do some of the
related
processing; it could just use the binary format in-memory (i.e. in
its
own process space), and output only in the traditional text form.
There is one reason to actually keep them in memory: so that consumers
(like 'systemctl status') can access the most recent log messages and
do
some processing with that. Otherwise, there is no need to store this
data and you can just set Storage=none anyway.
Accessing the current journal works by reading in journal files in /run
(and /var if it exists) and processing them (there is a shared library
for doing so).
If journald only keeps stuff in its own process space, for other
processes to access them there would need to be some kind of IPC
mechanism for other processes to ask journald to get some logs, that
would involve quite a bit of complexity, a large additional codepath in
both journald and all the clients and thus a large surface for
potential
bugs. With storing them in the same type of files in /run, the codepath
is the same, there is more testing for that codepath and the interface
is a lot easier: access control is just file permissions, scheduling is
done by the kernel, etc.
The alternative you propose is the thing that would be worrisome to me,
i.e. having a completely different, probably less-tested, way of
accessing this stuff, where journald itself (which forwards ALL
messages
to syslog when using systemd) takes on an additional burden. That seems
to be a far worse idea to me, complexity-wise.
And if you say you don't want the features that access the stored logs,
then you can set Storage=none, because then you simply don't need it at
all.
Christian
Reply to: