Nothing lasts, and it's okay
for some things to be lost
In an ideal world, logging wouldn't be necessary. Logs are helpful when things go awry ( and sometimes they're fun just to look at, or useful for learning more about how a system works ), but when things are running well, logging mostly just eats up CPU cycles and storage space. The former isn't a big deal, but the latter can actually become a problem in two important ways.
The first problem, which affects pretty much every logging system, is log files growing too large. Fortunately, every decent logging system has a rotation mechanism designed to archive and / or truncate the oldest logs, taking advantage of the fact that a log's value tends to be inversely proportional to its age. The oldest logs are usually deleted to make space for fresher data, ensuring that disk space is never exhausted, especially important if the logs are stored on the main system volume, where in the worst case, running out of disk space can take the whole system down.
The second problem, which is usually less serious, is wearing out the storage medium where the logs live. While storing logs on the main system volume is common and usually harmless, should the volume reaches its wear limit, the whole the system could become unstable. That said, in many situations, even on single-volume systems, the storage volume is so large ( allowing wear to be widely distributed ), or the medium so durable, that the problem becomes negligible. In certain cases, however, it behooves the system maintainer to tweak the logging setup to reduce load or wear on a disk.
The Raspberry Pi, commonly running from an SD card, is one such special case. Historically, there were some issues with SD cards failing a lot sooner than expected, or getting "corrupted", and although it seems much less common these days, reducing frequent writes to the card is probably a good idea. To that end, logging can be made ephemeral, for in all but the worst circumstances, the logs don't need to persist between boots.
I decided to use the tmpfs file system, as it is basically ramfs with some additional sophistication. Since the default init system on RasPiOS is systemd, and since I'm also running a few "external" services on the target host, this meant creating several new systemd units, one for logging in general, and an additional one for each service. Note that some of the filenames and locations seem to be a bit "non-arbitrary" when using systemd; each new unit goes into "/etc/systemd/system".
[Unit] Description=Mount tmpfs on /var/log DefaultDependencies=no Before=local-fs.target [Mount] What=tmpfs Where=/var/log Type=tmpfs Options=mode=0755,noatime,nosuid,nodev,size=512M [Install] WantedBy=local-fs.target
[Unit] Description=Create /var/log/apache2 at system start After=var-log.mount Before=local-fs.target apache2.service [Service] Type=oneshot ExecStart=/usr/bin/mkdir -p /var/log/apache2 RemainAfterExit=true [Install] WantedBy=local-fs.target
[Unit] Description=Create /var/log/rustdesk-server at system start After=var-log.mount Before=local-fs.target rustdesk-hbbs.service rustdesk-hbbr.service [Service] Type=oneshot ExecStart=/usr/bin/mkdir -p /var/log/rustdesk-server RemainAfterExit=true [Install] WantedBy=local-fs.target
Take note of the "After=" values that establish a dependency on the general logging unit, and the "Before=" values that ensure the service-specific logging directories are ready before their respective services start up. Note also that the general logging definition includes a size limit; for my rasPi4 equipped with 4 GB RAM, I was willing to give up a generous 512 MB to runtime logging, as the host's memory usage was averaging roughly 400 MB.
Don't forget to systemctl daemon-reload as well as enabling the new units. A reboot is also advised to confirm everything starts up correctly.