This issue has now been resolved and the fix is available via emonPi/emonbase update.
The emonhub logs have now been removed from syslog and daemon.log, they are being written to /var/log/emonhub/emonhub.log instead as per original implementation. EmonHub handles it’s own log rotation preventing the log partition from filling up.
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.
At a minimum of 1M (in reality they are larger than that as logrotate triggers hourly and they are usually larger than that by then) I suggest that the files are not much use. An hours worth of emonhub logs will not tell you much I’d suggest. I’ve suggested previously using a postrotate directive to concatenate these out of the log folder to generate daily logs but YMMV.