Ok we will consider persisting the logs, we would like to check the write load and see what can be done to reduce the logging level where it is not needed. E.g only logging at warning or error and above. daemon.log is also mirrored in syslog.
@pb66 do you use rsync with log2ram? I see that option in the config. Do you also disable the mail option? seems like that would be sensible.
Looks like its fairly straightfoward to disable the mirrored logging to syslog for logging also destined to daemon.log.
sudo nano /etc/rsyslog.conf
change:
*.*;auth,authpriv.none -/var/log/syslog
to:
*.*;auth,authpriv.none,daemon.none -/var/log/syslogNo it is apparently slower.
I don’t recall changing it but it won’t work if there’s no email server configured, IMO it would be a good option to have since it will email you if/when the log partition is short of space. Not a bad idea IMO.
Thanks, I wonder if more processor use in order to reduce disk wear is a valid trade-off to make in this case…?
mb = milli bits, as I understand it. 
At the risk of repeating myself yet again, the rules for the multipliers are:
If the unit is named after a person, that has a capital letter, else
if it’s multiplying by more than 1, and the capital letter is not already taken, it’s a capital letter, else,
it’s lower case.
so K = Kelvin, which forces k = kilo by the second rule
but S = Siemens and s = seconds
M = Mega, G = Giga, T = Tera, etc
m = milli, μ = micro, p = pico, etc
And it seems to be a convention that b = bit, B = byte.
Thank you for bring all this to my attention, I’ve deleted my comments since they were so factually incorrect.
Not known to be a problem 
…
Never knew that so it was worth repeating.
I do remember about GB v GIB though.
millibar surely? 
No, that’s hPa 
It really cheeses me off when people who one would expect to know better write about UHF frequencies in Mhz. Heinrich should be turning in his grave.
(Yes, I wasn’t thinking - comes of posting whilst watching TV.)
I’ve just got some more information about log2ram to share. I’m not sure where the best place to post it is: either here or maybe emonSD next steps - #20 by TrystanLea but I decided to post here. Please move it if appropriate.
OK, so a couple of things:
(1) I asked on the systemd list about how to configure journald to still write to persistent store even after /var/log is made volatile. See [systemd-devel] logging in RAM and journald configuration issue if you’re interested but TL;DR is to make another persistent directory just for journald and bind mount /var/log/journal to it (How about /var/log.journal ?) That gives us the best of both worlds and I suggest we implement it.
(2) In researching the above I looked at log2ram.service and noticed its Before= line and in particular ‘apache2.service’ on that line. Does that not suggest that every service that needs to log in /var/log needs adding to that line as well? In particular redis but also other things that get mentioned frequently. That makes the whole idea a bit more fragile, so it would be nice if it wasn’t true but then if not why is apache listed there?
That defeats the object of putting the log to volatile i.e minimising the number of writes to the SDcard to prolong its life.
So this may well be a vain attempt to ensure the log files are created before the other unit starts. Actually it is very difficult to do and probably futile. That Paul has found it to work is probably more luck than design if that is the purpose of the before= statement…
systemd-tmpfiles is a more robust mechanism to create tmpfiles and there was a script posted here somewhere to generate the right config file based on existing logs.
Please read my posts early in the thread where I describe the purpose and sanity of this.
You’re probably thinking of Better handling of files in tmpfs /var/log - #13 by pb66
Another hint from the systemd-devel mailing list is that the Before dependency of journald.service should instead be for systemd-journal-flush.service