move /var/log to a RAMDISK

No. Files in /var are expected to survive reboot, so that's how the packages are configured.

They are created during package installation. For example, $ rpm -q -l postgresql13-server|grep /var/log /var/log/postgres

Looking at the spec file for the rpm package, it has ... %attr(700,postgres,postgres) %dir /var/log/postgres which is used by rpm to set the ownership and permissions.

Regards, Dave Hodgins

This is in fact the default behaviour for Armbian on my Banana Pi M64.

If you want, I can send you the scripts used. They create the RAMDISK, c>

I feared that might be the case.

I can write that ok myself. However there would be no *controlled shutdown*. We are talking power cuts. The actual application does not write to SD disk at all, except for persistent configuration. Runtime files use a ram disk.

So the aim is to limit random writes that might happend when power is pulled from under. In use the only likely things would be systemd which logs everything all the time, and apache. Exim might send a mail a month.

Looking at the log files there is a huge amount of installation stuff that simply isn't needed, and stuff that appears at boot time that doesn't need to be preserved on power loss.

So I guess this is really a more general discussion about how to reduce logging to a minimum, and reduce writing to persistent storage to a minimum as well

I can set apache to log to a volatile storage area OK I think. And probably Exim too - mount ramdisks on /var/log/apache2 and /var/log/exim4

The problem is that the whole*nix logging system is based on how a good minicomputer sysadmin would like things, not how an embedded linux running off an SD card needs to be :-)

It can be done using scripts that hook into systemd, but is not easy, and may require changes to scripts with any package install that uses /var/log, and also risks losing parts of the logs in the case of an unclean shutdown, which is typically when you are going to want the logs.

Regards, Dave Hodgins

Embeded servers (eg OpenWRT) mount /var from a ramdisk at boot, and likely initially populate it that file system from some "static" initial state (with all of the basic directory tree elements) at boot time. And then on reboot/power failure, all of that is just lost (discarded). (Most OpenWRT-based servers have the option of remote logging, if one wants persistent logs.)

DRBL (Diskless Remote Boot Linux), also does this. It mounts the root (/) and /usr file systems read-only from the server and create RAMDISK file systems for /etc /var and /root (~root) and populates these FSs from pre-generated tarballs and rsyncs host specific content from a template tree at boot time and then discards them on shutdown.

That's not a nix thing. Live iso images work fine with no permanent storage, though most have an option to have persistent storage too.

While running a general purpose linux distribution installed on an sd card does work, they are not tailored for use on embedded systems.

An embedded system should be designed to work like a live iso, but with essential data stored on persistent storage, and with only the minimum needed applications, and system tools.

Regards, Dave Hodgins

Yes a few distros are designed similar to that. The server computer on my home LAN (which also runs off an SD card) is set to only save /var/lib/hwclock between reboots. If you don't run a syslog daemon then logs from programs that send them to syslog don't go anywhere. Busybox comes with a syslogd implementation which can be started to show all log info in the terminal with "busybox syslogd -n -O -". So run that during development for debugging, then when it's all working, go syslog-free.

On a system that isn't designed for temporary /var, if you just recreate empty directories in /var (those listed by "find /var -type d") after reboot, I expect all the programs that are already installed will create fresh files inside those directories by themselves.

On Sat, 29 Jul 2023 20:22:13 -0400, Computer Nerd Kev snipped-for-privacy@telling.you.invalid> w

The owner, group, and permissions must be set correctly too.

Regards, Dave Hodgins

Another common technique is to overlay a ramdisk on a read-only file system so that the ram disk only holds the changes.

That is an thought. Dont rely on fstab, but run a script. Really its only /var/log I care about. Rest of var can do as it pleases

- its so little used ro write to.

Well you would just copy /var/log to somewhere on persistent, delete all the files and then do a cp - R on reboot. Except that the first thing that happens on boot is the daemons fill up /var/log with boot messages :-(

I note since its Sunday, that the newest log files have been created by the logrotate process and are all empty.

Ah well. The smallest SD card I could easily get was 16GB, and RasPios and friends have only used 1.5GB.

It will probably take a long time to wear out.

This is of course not really the first thing that happens on boot, so if you can get in before the init system starts daemons then that solves your problem. I wouldn't like to try figuring out how to do that with something like Systemd, but then I avoid that sort of thing anyway. Busybox has a simple init system, good for embedded systems.

I was curious about this once too - does a 16GB SD card where only

The directory structure may be created by the package manager on install, but the files are created on the fly. In other words I might have /var/log/foo/error.log - foo is a directory that needs to exist, but if I delete error.log it'll be created next time there's something to go in there. This is commonly used by 'logrotate', which moves old files and compresses them, allowing new files to be created for future log entries.

So all you really need to do is reproduce the directory structure:

find /var/log -type d -exec mkdir -p "/tmp/{}" \;

which reproduces /var/log/foo/bar/ to /tmp/var/log/foo/bar/

Theo

Now that is interesting, and if I leave the old /var/log there, and mount a ramdisk over it, provided that the ramdisk is *immediately* populated and directories created, then all should work?

I guess I have to learn how to add a script to systemd :-(

You might like this approach it layers a ramdisc over an existing filesystem.

You /may/ need to trigger the logging deamon to redo the files. With traditional syslog that would be send the log deamon's a sighub. With systemd I have no idea how to do this as none of my linux systems contain systemd.

True. Hopefully there is a way.

Any process that has a log file open before you mount the ramdisk won't automatically start using it. The process will still have the open file handle to the original, disk-based file instead. So you'll either need to be sure to mount the ramdisk sufficiently early in the boot sequence to ensure that no daemons have opened their logfiles yet, or you'll need to signal those daemons reopen their logs. Most do that in response to SIGHUP. Logrotate often uses that mechanism after rotating logs, so its configuration can help you figure out what needs to be done after mounting the ramdisk if programs are still logging to disk.

I would add an entry to fstab to handle the mount ... mylog /var/log tmpfs defaults,user,size=1G 1 1

Copy the directory structure from /var/log somewhere else such as /my/log.

copy /usr/lib/systemd/system/systemd-remount-fs.service to /etc/systemd/system/, (create the dir if it doesn't exist already), then modify the /etc service to add a second ExecStart to run a script that copies the directory structure from /my log to /var/log.

Run "dracut -f" and reboot.

If you later install something that creates a directory in /var/log, just create a directory with that name, owner, group, and permissions in /my/log.

Make a backup on a second sd card first though, just in case! :-)

Regards, Dave Hodgins