I suggest you check again, we’ve had this discussion more than once! And you have repeated this error with Bruce too.
So, I’m at least glad you have struck out the value in your post above, because the line you have quoted to me, which by the way has been there pretty much since day one of original emonhub and is the line I have relentlessly pointed at over the last few years, is 5000 x 1024 bytes, which is 5000 kilobytes or a little shy of true 5 megabytes (5120 x 1024 or 5 x 1024 x 1024 would be 5 megabytes, but we are not here to split hairs, it’s a long way from “500mb”).
You are correct in “detecting” the count and size can now be set in the conf, this “feature” was slipped in amongst Bruce’s Python3 changes by Trystan 10mths ago.
following a discussion with you, later in the same thread linked above.
But since I’m not aware of these settings being provided in the current default conf I expect them to be at their original settings, 1 of 5mb.
Going back to what I said in my last post.
This stands!
5mb was plenty big enough during development, but G&T decided to globally set all rotations at 1 x 1mb in the emonSD images which crippled emonhub logging and set the precedent that you refer to where the logs are too small/short/few for any proper debugging. In the long log2ram discussions no decision was reached and then during testing Trystan experienced why we needed to set a log2ram (or rather a logrotate) limit for emonhub so that the 2 rotation systems are not working against each other, he chose 3mb, but I think 2mb would be better to remove that grey area in my example above.
What happens to the logs after rotation is managed by Logrotate, not emonhub or log2ram. Since the global count is set to 7, there should be 7 x 3mb = 21mb of logs, which should be ample.
Too improve logging the logrotate setting needs reducing to 2mb or the emonhub log_max_bytes needs increasing, not JUST to set the rotation size but rather to ensure emonhub is set to at least double the logrotate setting to avoid the example given.
To increase the number of logs retained, simply add a rotate 20 or what ever value suits better.
Indeed!
So, now going back to my first post, Ryan should have quite a few logs to look at, whether he has pulled the power or not will determine if any will be missing, and if that isn’t the case “something (else) is broke”.
Also don’t forget the log partition is just 40mb and has been since the days of the Pi B with 500mb ram despite my efforts to increase it to 50mb on Pi’s with less than 1GB and 100mb for 1GB and above. So emonhub’s 1 x 5mb (rotated) log settings could use upto 2x 5mb which is 25% of the ram limit (between log2ram iterations), where as the current settings could use less than 3mb (13%). So be warey of just upping the emonhub settings without looking at the partition size, we don’t want it filling up again.
I have no idea if setting backupCount to zero in emonhub would prevent a second file being produced, but that may not stop emonhub from “rotating” and effectively just clearing the log, I haven’t looked closely at Bruce’s code. However I would hate to see emonhub’s logging “fiddled with” until at least, the logrotate/log2ram is working 100% 100% of the time as it has been very stable and useful over the years, we need to fix the replacement before taking away the fallback.