Log Rotation Frequency ver 10.1.2

[pb66 (Paul)]

@TrystanLea

I’ve changed this in the emoncms master branch here as I think you suggest:

You seem to have dropped the redirection of stderr to stdout off the end so only stdout is being redirected to the logfile, any activity on stderr will still result in a entry on syslog (and an email to John).

As pointed out above, making these changes direct to the master branch has now caused a merge conflict for the other branch. Since you have again not commented on those changes, should I assume you are not interested in discussing those changes and just delete the branch?

Here is the original discussion back in May

@pb66

@TrystanLea

Im not sure if I need to make any logrotate modifications yet to fix this on existing systems.

I’ve looked through the logrotate install/update and it seems to be currently complete (as intended on previous emonSD images but absent on the Oct2018 image) but I wonder about how “multi-run safe” that script would be, surely the backed up files will get overwritten on every run as symlinks will pass the -f test. Also there is some confusion around the hourly vs daily cron (linking then moving?) so I was going to propose these changes https://github.com/emoncms/emoncms/compare/logrotate?expand=1 which will backup either daily or hourly cron files (but not symlinked copies) and forces a new cron symlink, just in case an existing incorrect symlink blocks a correct one being written.

I had also added the logrotate log folder check and create to the cron so that the folder is always found (ie not required in rc.local) and so that permissions are corrected even if it is there since the rc.local tries to change the ownership to pi:pi, which I didn’t understand as pi doesn’t have the authority to run logrotate properly unless using sudo and then root ownership is fine!

and there is an open github issue logrotate install - No check made on previous install · Issue #1309 · emoncms/emoncms · GitHub and it’s mentioned in Has /var/log Filling up Been Fixed? - #13 by pb66 and Error in log on update to 10.1.0.

As for the line to create the logrotate log file. I hadn’t suggested John make that change here. That was offered up as an alternative to adding logrotate to the list of log files created in the rc.local back in May, although I don’t think it would hurt having it there whilst the rc.local entry remains. That was hopefully going to be part of a larger edit to be the one place the logrotate log folder was managed to ensure the folder was always there and consistently the same, immediately before each logrotate run. It is also a single point to maintain.

I am also thinking the ownership would probably be better as root:adm so that users can access it without using sudo, but I haven’t tested that, and didn’t mention it on his thread to avoid confusing the outstanding changes already suggested and a more recent (untested) edit.

[edit] If you look at the diff side by side (rather than “unified”) it makes the changes much simpler to follow and you can see all I’ve really done is added a test so that only real (original?) files are backed up and not over-written on each subsequent run of the updater. (Comparing master...logrotate · emoncms/emoncms · GitHub)

The alternative is to not back up the files at all. There is no point in backing up whatever was there a couple of seconds ago on every click of the update button, 99 times out of 100 that’s just gonna be the same as the repo copy. It’s just needless confusion with no benefit in it’s current form.