Cumulus Support

No doubt this is a personal preference, but in almost all the code I write log files are only ever appended to. The "pruning" of the logs is a separate operation; sometime built in, sometimes external like Unix logrotate (https://linux.die.net/man/8/logrotate).

That preference comes out of considerable experience debugging seemingly nondeterministic bugs, often between collaborative asynchronous systems. (I've also encountered bugs that behaved differently when a debugger was attached - impossible to catch in that way).

As an example - while tinkering around for viewtopic.php?f=40&t=18805 I'm looking through some logging to wrap my head around when CMX knows an update is waiting and the interaction with the Upgrade Available indicator (which I find helpful ... or will). Of the ServiceConsoleLog.txt files I happened to have an image of I did note that the "You are not running the latest..." shows up in a different place - which confirms the 2 different paths we've been discussing.

I'd also welcome the option to treat the other logs, e.g. the main MXdiags log the same way, and I'd be OK with the option affecting both.

I'm not sure of the benefit of retaining that log file. There is nothing in it that isn't in the full log file, and it is the equivalent of the console when not running as a service which is lost immediately when you close Cumulus.** The service console log file isn't lost until next time you start Cumulus, so in that respect it is an improvement.

** Though new builds are now logging console output to that file even when run interactively.

Mark-

Yeah, your point is well taken. I did investigate 2 things quickly. The same information may be in both logs - perhaps using different terms. I didn't find exact parity, but close enough. I still see value in the ServiceConsoleLog.txt**, which I've made available from the admin dashboard in my install because the notices about a newer version showed up prominently at the bottom. Not sure what other critical messages are logged in ServiceConsoleLog.txt but for me it was a backup for the new alarm. The main log equivalent messages don't stand out as well without looking more carefully - perhaps using a filter.

Here 'grep' displays the matching strings in red.
FYI - When I first started running Cumulus under SystemD quite some time ago, I wasn't aware of the -service flag, or maybe it didn't yet exist. I ran it using "nohup . . . &" (without the flag) out of habit mostly, from prior experience running codes without a terminal. I haven't tried this since recently updating from a very much older version and having merged the 2 .service file where I saw the -service flag used. I do notice a difference when using "systemctl status" or "journalctl" which is my habit; I had gotten used to the console information being displayed there. BUT - with the addition of the Upgrade alarm this is less of an issue for me.

** I've not started seriously on it yet, but I started to tinker with a filter for the main log to color-code certain entries, and perhaps not display other lines - using the shell and ASCII terminal codes. That could be done through cgi easily enough. Hmmm...

Thanks for considering this, and the hard work to improve features and stability!!!