Indeed it should, I had some vague recollection that it was being run as pi not root but when I looked the other day I couldn’t find where that was the case. However I did find reference to the idea it wasn’t being run as root at some point due to these 2 lines
Why would the logrotate log need to be pi:pi unless logrotate was being run as pi? and
Why do we need to switch to the root user mid rotate if it was already being run as root?
I have no idea why logrotate would need running as anything other than root from a cronjob.
When logrotation is working as I believe was intended by the emonSD mods, all logs are rotated at 1M and checked hourly. Depending on how updated your emonSD is (assuming it is an emonSD) you might have a daily check, which is obviously not enough, a lot can happen even in an hour let alone a day, or you might have a logrotate that fails altogether in which case the /var/log filling up is just inevitable, whether it be a hour, a day, a month or a year.
Even with the 1M “limit” a runaway error can cause mayhem as if the limit isn’t hit on one rotation eg 999K then a fault condition raises many messages, it might not last til the next check when the file size will be over 1M (it could be 30M by then!)
The issue with the emonhub.log being mis-directed since being changed to systemd has just brought this “/var/log error” error to the forefront, but it’s always been there and fixing emonhub logs and/or the daemon/syslogs etc will not “fix the issue”, that’s in the hands of a better logrotation strategy (and backed up by monit?). I have been banging on about this since the “rock solid gateway” days (pre-emonhub which itself pre-dates the emonPi and emonSD’s).
Also in connection with this and possibly your other post too (How to recover emontx inputs after log full) what has changed with the change to systemd or more specifically using stdout over proper logs, is that services tend to fall over when /var/log is full, previously the services would soldier on and the data was held in ram and recoverable once there was some room in /var/log, this seems to no longer be the case, now a “stop due to /var/log full” is apparently no longer recoverable without data loss.
it’s only worth logging for indepth debugging purposes and should have a “debug” or “info” loglevel, it should not be a “warning” level event.