> 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? > Lennart > > -- > Lennart Poettering, Berlin _______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel