My thinking was to take the trigger out of the hands of cron so that it cannot be blocked by a full log partition. If the new script had an inbuilt timer/sleep and did it’s checks and found the log partition full, it could still rotate out the files when cron might not run. And if it was on it’s own “shorter” timer loop, it could discover the 95% limit much sooner than an hourly rotation cron.
I really must do some proper tests to see if this is still an issue in both Stretch and whatever the emonPi is running after a (full?) update. Although I’m tempted to just develop for the latest OS and assume the emonSD/emonPi will get revised at some point, it seems foolish to develop for an out of date OS.
Already covered in the answer above?
Just to add a note here about the emonSD log files in general, IMO they need tidying up somewhat. Whilst looking into something else I fired up a emonpi (older image) and this was the log folder
pi@emonpi(rw):~$ ls -la /var/log
total 1920
drwxr-xr-x 11 root root 640 Apr 30 11:17 .
drwxr-xr-x 12 root root 4096 Nov 7 2016 ..
drwxr-xr-x 2 root adm 60 Mar 8 17:17 apache2
-rw-r----- 1 root adm 36044 Apr 30 11:26 auth.log
-rw-r--r-- 1 root root 8997 Apr 30 10:14 boot.log
-rw------- 1 root utmp 0 Mar 8 17:17 btmp
-rw-r----- 1 root adm 56899 Apr 30 11:17 daemon.log
-rw-r--r-- 1 root root 1344 Apr 30 10:14 dataplicity.log
-rw-r----- 1 root adm 1093 Mar 8 17:17 debug
-rw-rw-rw- 1 root root 318915 Apr 30 11:26 emoncms.log
-rw-rw-rw- 1 root root 1325267 Apr 30 11:17 emoncms.log.1
drwxr-xr-x 2 emonhub root 80 Apr 30 11:17 emonhub
drwxr-xr-x 2 pi root 60 Mar 8 17:17 emonpilcd
-rw-r----- 1 root adm 32712 Apr 30 11:25 kern.log
drwxr-xr-x 2 pi pi 80 Apr 30 11:17 logrotate
-rw-r----- 1 root adm 251 Apr 30 11:17 mail.err
-rw-r----- 1 root adm 545 Apr 30 11:17 mail.info
-rw-r----- 1 root adm 545 Apr 30 11:17 mail.log
-rw-r----- 1 root adm 251 Apr 30 11:17 mail.warn
-rw-r----- 1 root adm 31619 Apr 30 11:25 messages
drwxr-xr-x 2 mosquitto mosquitto 60 Apr 30 10:14 mosquitto
-rw-rw-rw- 1 root root 0 Mar 8 17:17 mqtt_input.log
drwxr-xr-x 2 mysql adm 60 Mar 8 17:17 mysql
-rw-rw-rw- 1 root root 0 Mar 8 17:17 mysql.log
-rw-rw-rw- 1 root root 0 Mar 8 17:17 ntp_update.log
drwxr-xr-x 2 openhab openhab 80 Apr 30 10:14 openhab
drwxr-xr-x 2 redis redis 60 Mar 8 17:17 redis
-rw-rw-rw- 1 root root 1898 Apr 30 11:26 service-runner.log
drwxr-xr-x 2 dataplicity dataplicity 60 Mar 8 17:17 supervisor
-rw-r----- 1 root adm 100992 Apr 30 11:26 syslog
-rw-r----- 1 root adm 5373 Apr 30 11:25 ufw.log
-rw-rw-r-- 1 root utmp 2304 Apr 30 10:17 wtmp
IMO there should be a wider use of sub folders eg
emoncms.log
emoncms.log.1
mqtt_input.log (not sure if this is still used)
should be in a emoncms folder (there is an unfinished discussion about emoncms file structure at Move data & settings file to a common location?)
and
service-runner.log
emonpilcd/emonpilcd.log
emonpiupdate.log
wificheck.log
should probably all be in a single “emonsd” subfolder, since the logs will be persisted across reboots, there would no longer be a need to put any logs on the writable “data” partition (unless they are backups) but this isn’t directly the responsibility of the log rotate/persist script, although I guess it is related due to the “template”.