I would recommend starting a new thread about that “issue” then. whilst log2ram may alleviate or even resolve that issue, it’s not a given since we do not know if it’s “correct behaviour” or if it’s a fault since it has only started happening very recently and regularly to a select few (just you?).
There has always been a possibility of filling /var/log, it only really ever happened to my non-emonsd installs when there was a fault condition that produced a vast amount of logs, each time I have located and remedied the source of the rush of logs. I have also seen on very rare occasions that a /var/log partition would fill up over time (6mths+) which were addressed by increasing the partition size marginally so that the size and rotation better fitted the rate of log generation. I could have also reduced the log levels to the same ends, but I prefer to have the log data for debugging and improving systems.
The emonpi/sd however has a different approach. That tries to tackle the issue by rapidly rotating logs and not retaining more than the single last rotation (previously the last 2 until very recently). Prior to the more recent changes (maybe specifically the changes to emonhub systemd service unit and logging) this “filling up” wasn’t an issue and/or certainly not a daily issue.
Using log2ram will give us the log folder structure required at boot, it will retain logs across reboots for debugging and it will better manage the space in ram by putting rotated logs to disk rather than holding them in ram. All these things are essential and also helpful in resolving the issue you have but using log2ram has not been suggested over the last year or so to directly address an issue that has popped up in the last couple of weeks.
Think about what the current emonpi logging regime is doing when there is a lot of log traffic. If it is filling up when only a single set of rotated logs are retained (in ram) then effectively (and approximately!) you only have half of the 50mb log space after each rotation for new logs, so just by moving the rotated logs out of ram you would have double the space, this is what my mod to log2ram aims to do.
Retaining the logs longer (across boots) is very useful for debugging and the fact it removes the need for all that insanity in rc.local is a no brainier IMO. log2ram is not the reason you are having issues, even if it was working correctly which yours obviously isn’t, it only might resolve the issue. We need to work out if/why you logging has increased.
I hear what you say, but we need to stop focusing on the bits that clearly do work and try and fix the bits that don’t first and foremost.
So does/did the emonSD, have you restored normal logging before installing log2ram? You cannot just install it on something that already has /var/log in ram/tmpfs.
No they are not both in ram and you are right something is very wrong, possibly caused by installing over an existing logging to ram set up?
That is correct, but log.bak should be on disk not in ram!!!
I have no idea what the current emonSD is like, with no buildguide and then recent changes added to the unknown, I’m not sure what to suggest to remedy this. I did start to try and figure that out but the emonsd failed to update on firstboot and the reaction here on the forum was less than useful so I gave up, I have better things to do with my time since I do not use the emonSD myself, I do not have these issues.
Are the changes to emonhub logging live on the emonsd updates? Is that the cause of the increased logging?
I will try and help you install and try log2ram if you want!
I will also try and help you find why your log is filling up as a separate thing (certainly initially until we know better)
There will definitely be overlapping area there, but it would be daft to try and fix log2ram for the sole aim of fixing the log filling up, it might not do it and that is not how you gauge log2rams effectiveness.
To get this right we need to balance (with ample headroom) the generation of logs, the rotation of logs and the space for logs. I am not keen on stemming the flow of log data, that is the easy option and means we are not improving on the previous setup that just dumped the logs older than a couple of hours. But that doesn’t mean we shouldn’t take a hard look at the logs for duplication and/or unuseful logs and/or fault conditions.
[edit]
Here’s a df -h and a ls /var/log* on a basic Raspbian image plus log2ram and a few other bit’s and bobs, no emoncms or emonhub.
pi@raspberrypi:~ $ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/root 7.2G 3.1G 3.8G 46% /
devtmpfs 460M 0 460M 0% /dev
tmpfs 464M 64K 464M 1% /dev/shm
tmpfs 464M 460K 464M 1% /run
tmpfs 5.0M 4.0K 5.0M 1% /run/lock
tmpfs 464M 0 464M 0% /sys/fs/cgroup
/dev/mmcblk0p1 44M 22M 22M 50% /boot
log2ram 40M 6.6M 34M 17% /var/log
tmpfs 93M 0 93M 0% /run/user/1000
pi@raspberrypi:~ $ ls /var/log*
/var/log:
alternatives.log boot.log daemon.log faillog kern.log log2ram.log messages rotated_logs user.log Xorg.0.log.old
apt bootstrap.log debug fontconfig.log lastlog mail.info monit.log samba wtmp
auth.log btmp dpkg.log journal lightdm mail.log netdata syslog Xorg.0.log
/var/log.bak:
alternatives.log boot.log daemon.log faillog kern.log log2ram.log messages rotated_logs user.log Xorg.0.log.old
apt bootstrap.log debug fontconfig.log lastlog mail.info monit.log samba wtmp
auth.log btmp dpkg.log journal lightdm mail.log netdata syslog Xorg.0.log
/var/log.old:
access.log.1 auth.log.3.gz dpkg.log.1 error.log.5.gz log2ram.log.1 messages.3.gz user.log.1
access.log.2.gz auth.log.4.gz dpkg.log.2.gz error.log.6.gz log2ram.log.2.gz messages.4.gz user.log.2.gz
access.log.3.gz btmp.1 error.log.1 error.log.7.gz log2ram.log.3.gz syslog.1 user.log.3.gz
access.log.4.gz daemon.log.1 error.log.10.gz error.log.8.gz log2ram.log.4.gz syslog.2.gz user.log.4.gz
access.log.5.gz daemon.log.2.gz error.log.11.gz error.log.9.gz log2ram.log.5.gz syslog.3.gz wtmp.1
access.log.6.gz daemon.log.3.gz error.log.12.gz history.log.1.gz log2ram.log.6.gz syslog.4.gz
access.log.7.gz daemon.log.4.gz error.log.13.gz history.log.2.gz log2ram.log.7.gz syslog.5.gz
alternatives.log.1 debug.1 error.log.14.gz kern.log.1 mail.info.1 syslog.6.gz
alternatives.log.2.gz debug.2.gz error.log.2.gz kern.log.2.gz mail.log.1 syslog.7.gz
auth.log.1 debug.3.gz error.log.3.gz kern.log.3.gz messages.1 term.log.1.gz
auth.log.2.gz debug.4.gz error.log.4.gz kern.log.4.gz messages.2.gz term.log.2.gz
pi@raspberrypi:~ $
PPS - I do like the concept of adding monit to force a rotation as a backstop (omg I didn’t just say that did i?) but again it shouldn’t be the fix, it should be there to ensure when there is an unexpected fault condition increasing the log traffic, it is managed in a graceful way so the info needed to fix that issue is not lost. NOT to manage the everyday log traffic.
