move /var/log to a RAMDISK

With systemd, systemd-journald collects messages during early boot, in ram. The in ram copy is flushed to persistent storage shortly after the / filesystem is remounted rw over the ro / filesystem from the initrd.

That's why I recommend adding an extra ExecStart to systemd-remount-fs.service to set up the directory structure in a tmpfs mount of /var/log right after the / filesystem is ready to accept writes. That way it's done before the journal or, if present, rsyslogd starts writing to /var/log.

Regards, Dave Hodgins

Hmm ... MIGHT be able to make that work with minimal pain using systemd. It has 'depends on','run after' and such params. He could init the ramdisk REALLY early in a quasi-structured/quasi-safe environment.

Not everyone likes systemd - but it DOES have its uses.

Another trick is to just make the ramdisk whenever and then make /var/log into a symlink/mountpoint. Yes, there'd be some early stuff still in the real /var/log, but maybe that's not important for him.

However I'd rec ramdisks for where they're more useful. I have an app that does a lot of image manipulation before the results are shown via PHP/Apache on a Pi. I don't want any of that to be reading/writing to the SD card - too slow AND burns it out - but I did want access to be "normal", like with any 'real' drive. A small ramdisk was by far the best/easiest solution.

Would this be of any interest?

I think that SD cards (apart from a very few) have no sophisticated wear levelling *at all*.

From what I could find out they never map *already written* sectors to new ones so the old sectors get their allocation of writes, too.

My guess is that they would probably *at best* allocate new blocks to writes till they ran out.

Then sequentially reuse all the already used but 'erased' blocks. That sort of behaviour would work well for e.g. camera SD cards which get full but no so often

So, the more blocks the merrier.

If they are *really* cheap they wont do anything at all and there will be a 1:1 correlation between physical and logical sectors, in which case it doesn't matter how big they are, they will wear out the directory and sector allocation sectors without ever using the majority of the card.

I am not sure if e.g. linux can map out bad sectors in those areas. I suspect not.

My other Pi zero has been on for about 3 years now, writing the log files. and rotating them. It doesn't do a lot - its simple allows me to access and play my recorded music and the radio to one of the home hi fis.

A cursory glance at systemd reveals a huge potential flaw in it, or at least that is my understanding.

There is no order of execution of systemd scripts. They all get executed in parallel. Instead there are dependencies, which I THINK are encapsulated in the scripts as 'depends upon', not 'is depended on by'. So a standalone systemd script wont do the job. Instead one would probably have to find the mount script and add a patch to that.

Pi Zero only has 512M RAM!

Ah. That is interesting. Patching the mount service *itself*. That sounds like a plan, unless any updates wipe out the config...but who bothers to update an embedded system that Just Works?

Can you explain why that would be necessary?

Ahaha. First thing that systemd does that actually makes sense.

Yes. The advantage of that is that no info is lost writing to the on-disk /var/log - the boot stuff will all be flushed to the ramdisk once it is available.

Well it will be several weeks before I am ready to do any practical experimentation. I try to ask first, implement later. Soi as not to waste time on finding out what others already know, by experiment

Many thinks. I think your solutions is the one to use. It surgically splices in the minimum of configuration required to do the job. It OUGHT to be an optional part of Raspios really...

I use them in this and my other pi-zero context as fundamentally simple interprocess communicators. So in my Hifi Project, a daemon reads the icecast info off radio streams and writes it to a file in a temporary file system.

The web server then has access to that to let me know what misc is being played, via ajax calls from the web servers radio interface.

As long as only one process is writing them, this is a very simple and effective way to transfer data from one daemon to another.

In the current project which involves driving 4 mains relays using a daemon that collects various bits of information in order to decide when to switch them on, it is used to store the relay state, so again ajax calls from the web server can determine not what *should be on, but what is *actually* on.

I am sure the semaphores messages and pipes might have done the job, but simply recreating a file ion a ramdisk every few seconds works fine.

AFAICS all the dependency options have reverses, see the table in systemd.unit(5).

There are both functional dependencies (e.g. Wants/WantedBy) and ordering dependencies (e.g. After/Before). If you want to serialize startup you’ll need both.

Given their race to the bottom price wise, this is a reasonably safe assumption.

If the hardware does not handle bad sector replacement then you'd need to run a Linux filesystem that does do so on top. For an SD card, that would likely best be one of the 'flash' filesystems.

I've been using SanDisk Class 10 uSD cards in various PIs, with the machines running continiously for years without errors. Some of these machines have survived multiple power failures without problems. Several of these machines I use as "build boxes". I have been using good old Ext4 as the FS.

Indeed. People DO have failures, but I can find no really clear data on

Ultra "cheap" no-name brand uSD cards?

On Bullseye and later the largest amount of logging activity to disc is bloody systemd's journald, which by default will grow /var/log/journal/* to 2GB, taking up valuable space on SD cards and severely reducing their write life.

Two things you can do; first as f****ng Peottering always knows best, there is no way of turning off journald and just using the god given rsyslog, but you can stop journald logging to disc and just keep it in RAM instead by adding the following to /etc/systemd/journald.conf

Storage=volatile RuntimeMaxUse=32M RuntimeMaxFileSize=32M ForwardToConsole=no ForwardToWall=no

Secondly stop systemd spamming /var/log/syslog with all sorts of crap you have no interest in. Create a file called /etc/rsyslog.d/drop.systemd.conf containing

# Drop messages from f***ing systemd :programname,startswith,"systemd" stop

If you do that, you'll be left with far less logging activity to disk, so you may not have to bother moving it to RAM. If you still want no logging at all to disc, you can disable rsyslog entirely and just use journald restricted RAM. But that way madness lies.

---druck

Works fine for me. Pi W running Raspbian (Debian 11 version)

Cron job reboots it every morning so I don't worry about ramdisk filling up.

$ df -h Filesystem Size Used Avail Use% Mounted on /dev/root 7.0G 2.1G 4.7G 31% / devtmpfs 183M 0 183M 0% /dev tmpfs 215M 0 215M 0% /dev/shm tmpfs 86M 2.7M 84M 4% /run tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 100M 8.0K 100M 1% /tmp tmpfs 100M 176K 100M 1% /var/log tmpfs 30M 0 30M 0% /var/spool/mqueue tmpfs 30M 0 30M 0% /var/tmp /dev/mmcblk0p1 253M 51M 202M 20% /boot tmpfs 43M 0 43M 0% /run/user/1001

Logging works and everything needed seems to be created on boot.

$ ls /var/log -la total 180 drwxr-xr-x 3 root root 260 Aug 1 05:33 . drwxr-xr-x 11 root root 4096 Jan 11 2021 ..

-rw-r----- 1 root adm 23843 Aug 1 08:06 auth.log

-rw-rw---- 1 root utmp 3072 Aug 1 08:03 btmp

-rw-r----- 1 root adm 21318 Aug 1 08:00 daemon.log

-rw-r----- 1 root adm 1032 Aug 1 05:33 debug

-rw------- 1 root root 2559 Aug 1 08:03 fail2ban.log

-rw-r----- 1 root adm 26940 Aug 1 05:33 kern.log

-rw-rw-r-- 1 root utmp 292584 Aug 1 08:00 lastlog

-rw-r----- 1 root adm 26239 Aug 1 05:33 messages drwx------ 2 root root 40 Aug 1 05:33 private

-rw-r----- 1 root adm 50106 Aug 1 08:00 syslog

-rw-rw-r-- 1 root utmp 1920 Aug 1 08:00 wtmp

It's been running like this on the same SDCARD for 2+ years.

Possibly, again, no direct evidence, sadly.

Its another of those details that Pi users probably need to know, but no one else cares about.,

There are SD cards for data transfer - video capture - and sd cards for multiple use like cameras.

no -- “it should be clear by now to everyone that activist environmentalism (or environmental activism) is becoming a general ideology about humans, about their freedom, about the relationship between the individual and the state, and about the manipulation of people under the guise of a 'noble' idea. It is not an honest pursuit of 'sustainable development,' a matter of elementary environmental protection, or a search for rational mechanisms designed to achieve a healthy environment. Yet things do occur that make you shake your head and remind yourself that you live neither in Joseph Stalin’s Communist era, nor in the Orwellian utopia of 1984.”

Vaclav Klaus

I am already liking your world view. As I said 'designed to make life easier for a minicomputer system admin' Not really what we want in a Pi.

Ah. I had already limited its size. Where in RAM does it keep it, or is that only known the the Great Poettering, who has provided some buggy tool to access it?

In normal use I would have access and hopefully not error logs from apache, but only minimal. And perhaps the odd error message being mailed out via exim.

Mostly the machine will be, apart from a daemon waking up every few seconds and seeing what's what, essentially idle

is ryslog still running? Oh, yes it is.

I think stage one is to create and mount something like /var/ramlog and see how much standard logging can be moved there by patching rsyslog.conf and the logrotate files.

apache2 can be moved there too. That's defined in /etc/apache2/envvars

The only hardwired one I can see so far is exim4, but I can cope with that. Certainly should be able to push a huge amount off the SD

Logging is phenomenally useful for debugging a *development* project, but there is absolutely no need for persistence

So a ram disk plus limiting what goes on it, is handy. ...a few moments later... successfuly got systemd journal to cease to exist on disk, and moved nearly everything to a ram log. As the man falling past the 13th floor yelled: 'so far. so good!'

Why don't you just use overlayfs to overlay a ramdisk on /var ?

One would hope that these cards would have wear levelling set up to handle lots of small I/O operations but I suspect that's not part of the spec...