Key thing to remember is that we are concerned over SD Card write.
syslog logging is fine but requires some careful setup to prevent /var/log filling up as we know from bitter experience. I’ll have a play and see if that does the job for me.
My reason for the request is that, on occasions, if a user is having issues, you really need more than the few hours of DEBUG logs, the current setup allows for. Asking a user to simply disable rotation for 24Hr say, would safely increase the amount of logged information for debugging.
Absolutely. I’ve burned a few SD cards over the years. Quite tedious!
My emonpi has enough RAM that increasing the size of the /var/log tmpfs was sufficient. I’m now running with 100M (although only 13M is used).
Another (potential) advantage of rsyslog is that it can send logs to a remote server. I’m not aware of any free syslog hosts on the internet but it would be technically quite easy for emoncms.org to host one. The logistics, finances and security of such a setup would be harder, but it might be worth exploring.
Is it worth putting a bit of effort into trimming the logs to what is actually useful? I haven’t spent a lot of time helping users here but lines like Sent to channel(start)' : ToEmonCMS and its partner (end) might just be noise… Could the timestamps just be unix time in seconds? Reducing the size of the logs would improve SNR without requiring end users to do anything. Just a thought.
Please will a moderator split this discussion about logging into a separate thread, as previously requested. It has nothing specific to do with python upgrades.
I don’t understand why log rotation prevents access to older logs? That’s the point of log rotation - to keep older logs accessible but compressed.
I’d also suggest sticking with standard logging facilities rather than trying to customise formats. I’d also suggest once again to look closely at journald and see if there’s anything needed that it can’t do, because I can’t think of anything.
Because the rotation happens at 500MB (IIRC) and with DEBUG enabled, that does not equate to very long. Also, by default, there is only one iteration.
It does. It uses the ‘standard’ logging package built into Python.
Yes you do keep saying that and I keep saying it is an option that has previously been discussed at length (as you can see by searching) and we have made a decision not to go that route because:
The internal logging mechanism works perfectly well for 99.9% of cases. It is a proven solution.
Journald/syslog requires additional system setup that can (and has) caused problems in the past (search the forum for the problems).
Additional logging is only needed occasionally. On those rare occasions, if there was an easy method for a user to be asked to produced some enhanced logs (i.e. change an option in the emonhub.cfg), then that would be very useful.
Changing how logging is done is not up for discussion.
Close, the rotation happens at 5000 kB (5000 * 1024 bytes so 4.8 MB, probably the author meant 5 * 1024 * 1024).
The number of iterations could be increased easily. The cost to the SD card is zero since this is on a tmpfs so we only have to consider the space required. If the default is 50M tmpfs for /var/log/ then we could use half of that for emonhub, or 5 iterations.
The python logging module is indeed standard but the configuration all ends up in the code, unless one makes a config system to drive it. In contrast, handing logs off to rsyslog allows the configuration to be in config files instead.
I don’t feel strongly enough about this to argue for/against. I’m merely presenting options with a sprinkle of opinion. I’m conscious that tone comes across badly on the internet and I don’t want to rub anyone the wrong way!
My suggestion is to provide a simple mechanism, that a user could be asked to do, that increased the volume of logs available for debugging. That could be a simple flag that increased the size of the logs (and the code then increased the logs/rotations or stopped rotations) and could then easily be reverted once the issue had been resolved.
Which we already have to a large extent - I’m just looking for a minor extension to fill a gap that exists in the capability.
That’s fine and it hasn’t. I’m possibly getting frustrated when the same point is repeatedly made and is repeatedly pushed back. Oddly enough, I’ve advocated the rsyslog route in the past. Discussion was had; a decision was made to stick with what we do; end of.
OK I’ve given this some thought and I think potentially the least intrusive mechanism is to add a setting to emonhub.conf which controls backupCount (i.e. the number of rotated log files). A user can easily change the setting, it will be picked up immediately and gives a reasonable amount of control with an easy intuition about how much space the logs will require.
OK I’ve made an attempt, here is a branch with a bunch more fixes and the logging feature as described above:
There will almost certainly be bugs in there, so please test and report back. If it runs, you should be able to change log_backup_count and log_max_bytes in the “hub” section and it should emit a log message saying that these settings changed.
I also pushed a new emonhub.service file which you can test if you like, remember to sudo systemctl daemon-reload before restarting the service.
or 
emoji
or 
etc. can help avoid confusion / misunderstanding.