How is this looking on your emonPi @jsroques?
Apologies (again) for the lack of engagement. I haven’t had the time to look at your work in depth and felt it demanded a proper evaluation rather than a “quick look” especially as I do not use the emonSD or anything else from the emonpi repo, so I will have to pick out the bits and build an image to fit them to to try this out properly.
I have come back here today just to add a couple of notes that maybe of interest following on from the “Data not logged locally” discussion.
Firstly it might be worth while having the log-rotation triggered by something other than cron. If the log partition fills up, cron can fail, so the bloated logs will not get rotated out. If (for example) a service (perhaps the same one as the log backups so they are sync’d?) was to time one hour and trigger, in a loop rather than using cron, even if the log partition fills up to the point cron doesn’t work, the files will still get rotated on the hourly timer service. This would have a minor benefit of removing some of the lorotate mods for RO OS as the original daily cron can remain, we do not need to add an hourly one.
Secondly, since this log file management is pretty much all related and all required if and only if the OS is RO, perhaps it could check the log partition usage and trigger a rotation at 90 or 95%, yes theoretically we lose 5-10% of the space but I’m thinking headroom for runaway errors, if it’s only checked every few secs it could fill up before the next check, this then presents the question over whether we need to rotate hourly if we are monitoring the partition size? perhaps just run rotate at 80% full and forget hourly rotations, just back up hourly instead?
These are not finished thoughts or feature requests, just some observations and related thoughts for possible consideration.