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.
Welcome to the Cumulus Support forum.
Latest Cumulus MX V3 release 3.28.6 (build 3283) - 21 March 2024
Cumulus MX V4 beta test release 4.0.0 (build 4018) - 28 March 2024
Legacy Cumulus 1 release v1.9.4 (build 1099) - 28 November 2014 (a patch is available for 1.9.4 build 1099 that extends the date range of drop-down menus to 2030)
Download the Software (Cumulus MX / Cumulus 1 and other related items) from the Wiki
Latest Cumulus MX V3 release 3.28.6 (build 3283) - 21 March 2024
Cumulus MX V4 beta test release 4.0.0 (build 4018) - 28 March 2024
Legacy Cumulus 1 release v1.9.4 (build 1099) - 28 November 2014 (a patch is available for 1.9.4 build 1099 that extends the date range of drop-down menus to 2030)
Download the Software (Cumulus MX / Cumulus 1 and other related items) from the Wiki
Option to *Append* to ServiceConsoleLog.txt
- radilly
- Posts: 123
- Joined: Fri 17 Jul 2015 11:01 am
- Weather Station: Ambient WS-2080
- Operating System: Raspberry Pi 3, OS Buster Lite
- Location: McMurray, PA, US
- Contact:
Option to *Append* to ServiceConsoleLog.txt
You do not have the required permissions to view the files attached to this post.
Cheers,
Bob
Bob
- mcrossley
- Posts: 12695
- Joined: Thu 07 Jan 2010 9:44 pm
- Weather Station: Davis VP2/WLL
- Operating System: Bullseye Lite rPi
- Location: Wilmslow, Cheshire, UK
- Contact:
Re: Option to *Append* to ServiceConsoleLog.txt
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.
** Though new builds are now logging console output to that file even when run interactively.
- radilly
- Posts: 123
- Joined: Fri 17 Jul 2015 11:01 am
- Weather Station: Ambient WS-2080
- Operating System: Raspberry Pi 3, OS Buster Lite
- Location: McMurray, PA, US
- Contact:
Re: Option to *Append* to ServiceConsoleLog.txt
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!!!
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!!!
You do not have the required permissions to view the files attached to this post.
Cheers,
Bob
Bob