Hi Stuart, Thanks for that,
I like your approach using syslog memory buffer (I need to do that) or use the syslog to a syslog server I need to get better at the Syslog agreed that the loss of logs on unscheduled / power related reboots is a problem with my approach of mfs mounting /var/log I like your idea chmod 000 reorder_kernel ... perhaps reordering after patching and upgrading would be enough instead of at every boot time I have left the reorder_kernel alone up to now... but I can see the benefit in your approach... Thanks again, On Thu, 4 Sept 2025 at 15:25, Stuart Henderson <[email protected]> wrote: > On 2025/09/04 15:14, Tom Smyth wrote: > > The biggest issue I have seen is where you have a chatty daemon > > talking to /var/log we find that wears out the flash quite > > quickly... and the probabilty it will be writing to disk during a > > power event was approaching 100% > > > > so I wanted to reduce the probability of a write to the disk during > > a power event (as a lot of these devices are in less than ideal > > locations beside users / customers even :) and without any power > > backup / conditioning ... > > fwiw, though I mostly stopped using openbsd on that type of device > anyway, for the ones that still remain I normally use syslog's memory > buffer logging for anything chatty, but keep mounting /var/log as > normal and have more important things written there. this can help > when I'm diagnosing a failure (there's a higher chance of a log entry > getting to disk if it doesn't rely on e.g. rsync in rc.shutdown). > > (for those, I also modify /etc/rc to force -y for fsck, disable > library_aslr, and "chmod 000 reorder_kernel" in rc.local so that it's > disabled in normal conditions but easily reenabled if needed) > > -- Kindest regards, Tom Smyth.
