On 17/03/2019 21.32, Dave Howorth wrote:
"Carlos E. R." <robin.listas@telefonica.net> wrote:
On 15/03/2019 13.33, Dave Howorth wrote:
Can systemd's journald be configured to write logs to RAM and then periodically save them to disk? Ok, found one (man journald.conf):
SyncIntervalSec= The timeout before synchronizing journal files to disk. After syncing, journal files are placed in the OFFLINE state. Note that syncing is unconditionally done immediately after a log message of priority CRIT, ALERT or EMERG has been logged. This setting hence applies only to messages of the levels ERR, WARNING, NOTICE, INFO, DEBUG. The default timeout is 5 minutes.
Hmm, so a supplementary question for extra points :)
I'm considering an environment where the 'hard disk' is an SD card (not an SSD or HD) and so minimising writes to it is still a relevant goal.
Hum.
It's possible to use journald to write all the logs to persistent storage, which causes it to write to disk once every five minutes, except in an emergency. That solves the problem but ...
Most applications still use separate log files under /var/log so the strategy above requires every application to be customised to use journald instead. That means customising lots of conf files in various formats at best and ninja acrobatics at worst. Plus customising some of the systemd unit files as well. And maintaining it all through updates.
Hum.
So ... another approach is to mount a tmpfs in place of /var/log and let the applications continue to log as normal. That works, but loses all the logs on crash or power fail :( Not good. So there's at least one solution out there - a thing called log2ram - that does a couple of things. It regularly updates disk copies of RAM-based log files so they're reasonably up-to-date after a reboot. And it copies the directory structure under /var/log from RAM to disk whilst the system is running and then copies the directory structure back from disk to RAM when the system reboots. If we then treat journald as a special case that writes to disk always so we benefit from its crash-saving feature, then we have another solution.
Hum.
So my question is whether this log2ram idea looks like it will hold water? Or if there are other alternatives out there? (It seems like a fairly common problem) Or any other thoughts from the deep-thinking denizens here?
There is something, but I have never tried. Not that extreme, at least. Adjust the kernel filesystem parameters so that it doesn't write the disk cache or buffers frequently. You need also lots of RAM. Now I don't know off hand how to do that, but I know a program that does just that: laptop-mode-tools or some similar name. <https://wiki.archlinux.org/index.php/Laptop_Mode_Tools> <https://github.com/rickysarraf/laptop-mode-tools/wiki/FAQ#i-have-a-solid-state-disk-ssd-in-my-machine-should-i-enable-any-of-the-disk-related-parts-of-laptop-mode-tools-or-are-they-irrelevant> You don't need to use the package, just study it to find out what parameters it changes. Or actually use the package with the adjustments to your choosing. HTH :-) -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)