Just to be clear here, emonHub will only handle it’s own rotation at 5M if the emonSD’s logrotate fails to rotate the logs sooner and this can only prevent emonhub from filling the log partition if IT is causing excesive logs and reaches 5M between the hourly >1M checks.
If another log is growing rapidly (for example emoncms.log as seen in How to recover emontx inputs after log full) the partition will still fill up if logrotate isn’t able to keep on top of it. Due to the way the logrotate is currently configured on emonSD, it will fail to rotate the logs if the partition is already full (or very close to full).
Since the logrotate will rotate the emonhub.log at >1M the emonhub.log sizes will remain small, so the likelyhood of emonhub.log reaching 5M to rotate itself when something else is filling the log partition is unlikely.
This “fix” is very much welcomed, but it only puts us (roughly) back where we were before emonhub was converted to systemd. There is still a real risk of the log partition filling up and stopping emoncms from working, and logrotate is still not really helping much with that.
[edit]
. . . and what happened to
That would negate any need to create the log dir in rc.local (ref /var/log still filling up - #27 by pb66)