[systemd-devel] logging in RAM and journald configuration issue

[Lennart Poettering]

On Di, 19.03.19 20:45, Dave Howorth (systemd at howorth.org.uk) wrote:

> In the case of a machine that uses an SD card as its primary backing
> store, it is desirable to reduce the number of write operations to the
> card in order to prolong its life. journald is quite well-behaved in
> this regard since it offers the choice of a temporary or permanent
> journal and limits the frequency of its writes, except in emergencies.
>
> However, its permanent journal is written under /var/log/journal and
> there is no way to configure the path as far as I am aware. I think
> this is a problem.
>
> The reason is that on this type of machine people sometimes map
>  /var/log to RAM using tmpfs and then perhaps persist the logs using a
> program like log2ram. When this is done, journald's emergency writing
> capability is lost and crash analysis becomes more difficult.
>
> Of course it is possible instead to redirect the log files of programs
> individually to temporary memory using systemd-tmpfiles wherever
> needed. But this involves reconfiguring each and every program that
> uses /var/log both initially and whenever new programs are installed.
> This is tedious not only in quantity but because each program has a
> different detailed format of configuration file.
>
> So making /var/log into a tmpfs is a more attractive option. But
> ideally the journal would be placed somewhere else in persistent
> storage so its contents are available after a crash. This does not seem
> to be possible through lack of a config option.
>
> Is my analysis correct? Are there any other ways to resolve this
> difficulty? Otherwise, is it possible to consider a log location config
> option for journald?

Right now, when persistent mode is enabled journald will store its log
data in /var/log. When it is disabled it will store things in /run/log
instead.

It has been requested that we add a hybrid mode that makes journald
log to both locations at the same time, but filter by log priority so
that log msgs higher than some priority go to one location and the
ones below it go to the other. A patch like that would probably be
relatively straight-forward and short. Would be happy to review/merge
a patch for that.

I think if that's implemented the log location should really stay
unmodified: /var should be persistant and /run not, and there would be
no need to remount any of those paths in a different way.

Lennart

--
Lennart Poettering, Berlin