emonSD next steps

[pb66 (Paul)]

We seem to have jumped threads, this is really part of the longer “logrotation” discussion in emonSD next steps: filesystem & logrotate, which IMO should have actually been in the emonSD next steps: log2ram thread to keep that all together, but one might argue the emonhub log question should be in emonSD next steps: emonhub logging. This has become a bit crazy and foggy too. I’m not sure any of these threads are going to make sensible reading at a later date, unless you read them all at once in chronological order (ie as one thread).

@borpin

@pb66, there is more than one file in the tree called error.log

 pi@emonpi:/var/log $ ls -lah /var/log/*/error*
-rw-r----- 1 root  adm  243 Apr 27 00:17 /var/log/apache2/error.log
-rw-r----- 1 mysql adm    0 Apr 27 00:17 /var/log/mysql/error.log

When they rotate you don’t know which is which in the rotated_logs folder and the subsequent rotation could be all at sea.

As previously stated.

@pb66

The olddir is currently set for a global "log,old` folder, so all logs will get dumped in the one folder. If you want to preserve the folder structure you can define olddir in each conf so that olddir for apache2 (for example) is /var/log.old/apache2.

I didn’t get as far as exploring what might happen to similarly named log files, I didn’t like the “all in one pot” approach regardless of how that might pan out. But that said. logrotation might be able to distinguish between the logs by file meta (ownership etc) and the different extn’s, I don’t know for sure, but either way, I would rather see the folder structure retained by using more than one olddir path. The alternative would be to instruct logrotation to add a prefix identifier, but that would also require a per conf edit, so no gain over the separate olddirs option.

@borpin

Secondly, I’m still not finding a set of emonhub logs that could be used for debugging. Where should they be?

They should be where the logrotation config defines where they should be

@pb66

What logrotation command and/or config are you using? The default (by packages) config will not catch emonhub, wildcard “catch all’s” are discouraged in logrotation, the original emonsd logrotation conf did cast a very wide net and it limited everything to 1M.

you know logrotation is working because there are other files rotated, so the question is what is logrotation doing (or not doing) with the emonhub logs? Has emonhub been catered for in what you have installed?

My opinion on how the configs should work seems to differ to both your’s and Trystan’s opinion, I do not know what has/hasn’t been decided or coded, nor do I know if whatever might have been coded has installed correctly, or is functioning correctly.

So what do YOU have in the way of config? If it’s just the packaged default config’s, no further logrotation for emonhub beyond it’s own >5M rule would be the expected behaviour. Are you confirming the expected behaviour or is there something in the config that makes you expect something different?