Re: logging in RAM and journald configuration issue

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

On Mi, 20.03.19 09:57, Dave Howorth (systemd@xxxxxxxxxxxxxx) wrote:

> > On Di, 19.03.19 20:45, Dave Howorth (systemd@xxxxxxxxxxxxxx) 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.
>
> Many thanks for the quick reply. I'm not clear how that resolves the
> situation I explained, since it neither provides an alternative
> persistent log location nor provides an alternative means of
> arranging the logs of other programs. It doesn't seem to address my
> issue at all?

I don't understand the problem then?

The journal only collects logs on stdout/stderr, syslog and its native
protocol. Nothing else. It's not a tool that can collect arbitrary
per-app logs that don't go via these transport hence. And it really
shouldn't be.

Also: /var is generally understood to be persistent, and /run to be
volatile. If you want to redefine that you are welcome to, but of
course you have to patch through all kinds of software then.

Lennart

--
Lennart Poettering, Berlin
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel