Hi John, I think you may be tying yourself up in a knot.
The reason I suggested sudo was because the cron job is executed by the root system user, when you tried to run it as pi, it was expected to fail, by running with sudo you were closer to mimiking the way it actually gets run by cron.
The additional script you have added is not required and to be honest, I do not know for sure what the outcome maybe for the root user running a command using sudo would be exactly.
The forced logrotate would indeed require sudo.
What is the owner of the /var/log/logrotate folder? The folder and content should be all root so try issuing a sudo chown -R /var/log/logrotate that will also change the status file to root ownership as it should not be pi:pi.
The warnings you saw are nothing to worry about. The emonpiupdate.log is located in ~/data so it doesn’t need rotating out of /var/log only the symlink resides in the tmp folder and uses negligible space. The duplicated rules for the auth.log is due to the wildcard’s as I’ve explained earlier in this thread.
TBH I don’t think you need to be doing any of this now, IIRC Trystan added the ammendment to the master repo so you shouldn’t even need the custom cron entry let alone another script to trigger that cron script as root.
Try updating (unless you have other reasons not to do so) and NOT doing the symlink command previously suggested, worst case scenario (with regard to logrotate) is you will get an email if the repo code wasn’t amended, at which point you can just add the symlink to our custom cron (not the new intermediate script).
Then we can look to see if logrotate is working as expected. One major failing of the current setup is that once the partition is full, logrotate cannot function and therefore will not resolve until you intervene.
In the mean time any log that can fill the partition in between hourly checks can gum things up. Should this happen again, you should copy the /var/log folder to your hdd for further investigation before truncating any files so that we can get a look at what was going on when the partition filled up and hopefully apply a fix.
If and when log2ram gets rolled out to the emonSD I’m hoping much of this will be resolved. Meaning that log2ram will manage the possibility of unexpected runaway logs and act accordingly with both action and notifications. No solution can actually stop that possibility entirely without reducing log activity and that is counter productive, no error logs doesn’t mean no errors and working blind there is no way to locate and resolve said errors.
