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
From build 3044 the development baton passed to Mark Crossley. Mark has been responsible for all the Builds since. He has made the code available on GitHub. It is Mark's hope that others will join in this development, but at the very least he welcomes your ideas for future developments (see Cumulus MX Development suggestions).
I am having an issue with viewing the info on the dashboard and I can't use it much. I can load the main dashboard page fine but on many of the other pages there is missing information. I often get a error 500 also ( Failing module name: StaticFilesModule The method or operation is not implemented). which goes away with a page refresh.
This trouble seemed to happen after i did a sudo apt-get update and installed VNC Server. I can't seem to figure out what is going on but it looks like the date/time settings somehow changed.
I tried a fresh install of Cumulus MX with no improvement and also uninstalling and reinstalling VNC Server.
I notice that for the monthly log file for this month, it started writing to Aug.19log.txt instead of Aug19log.txt.
All my data is uploading to the website except for the following has changed:
Aug. instead of August
Mon. instead of Mon
Any ideas? I am not sure what is going on here. Assistance would be appreciated.
Interesting. Just a few hours ago I posted a similar issue.
Mine is definitely related to an installation of monodevelop (and thus probably a reinstallation of Mono). After refreshing all the pages, the problem was gone. But the question remains if it were only to prevent problems in future.
Matt.j5b wrote: ↑Mon 26 Aug 2019 12:04 pmThis trouble seemed to happen after i did a sudo apt-get update and installed VNC Server. I can't seem to figure out what is going on but it looks like the date/time settings somehow changed.
I notice that for the monthly log file for this month, it started writing to Aug.19log.txt instead of Aug19log.txt.
All my data is uploading to the website except for the following has changed:
Aug. instead of August
Mon. instead of Mon
Any ideas? I am not sure what is going on here. Assistance would be appreciated.
Looks like your system locale has changed. That would explain the different date/time strings.
You can start Cumulus using a specific locale, otherwise it will use the system locale. There have been a few posts about it on here.
Strangely I had not noticed the change from 'aug19log.txt' to 'aug.19log.txt', but is is the same on my installationas on that of matt.j5b.
Also after an apt-get (in my case the monodevelop but apparently that appears to be irrelevant) and after a system 'apt update'.
Well, my locale has not changed (checked with bash command 'locale', let me know if you want another check). The contents of the logfile holds the same separators and decimal point as before. I would not know with which locale to startup cumulus with. I think I will leave it like this, as long as I am not sure. It was not a change of locale.
But in addition can you give a hint what I can expect at a rollover of the month? Because now I have two logs and the first appears not to exist anymore for the cumulus system and that does not feel good. Are they used for something at the change of month? Day? Year? Or is it just backup? Should I transfer the data from the old file to the new one (during a shutdown of cumulus).
Have a look for "Current culture" around the time of start-up with your new setup in the Mxdiags file. Compare with what the old setup reports.
This looks very similar to problems people had when upgrading to Windows 10. Have a look on the forum, as there were a few posts about it. I think parts of the locale settings changed during the upgrade - but that is from memory, so I would search to confirm.
And I would like to add, that when i give the command 'date' in the shell, no point comes after aug: "ma 26 aug 2019 20:13:05 CEST". This means, that it probably has nothing to do with the locale from the OS point of view. My guess is - since I updated the whole thing including Mono - that somewhere in mono or some library somebody added a point to the month (and will probably at sometime remove it) with big consequences. Unfortunately, cumulus uses the month name from the locale to create a filename.
Would there be a way to revert the updates I did (apart from restoring a backup)?
2019-08-26 10:27:43.689 Mono version: 6.0.0.319 (tarball Tue Aug 13 01:24:21 UTC 2019)
2019-08-26 10:27:43.689 Current culture: Dutch (Netherlands)
2019-08-26 10:27:43.689 Directory separator=[/] Decimal separator=[,] List separator=[;]
2019-08-26 10:27:43.689 Date separator=[-] Time separator=[:]
2019-08-26 10:27:43.689 Standard time zone name: CET
2019-08-26 10:27:43.689 Daylight saving time name: CEST
2019-08-26 10:27:43.693 Daylight saving time? True
2019-08-26 10:27:43.693 26-8-2019 10:27:43
Please note, that I already had another problem with locale: I was programming something in C and the scanf uses the locale to estomate the decimal point (as far as I understand it). So I queried the decimal point value from the call to locale and I found point (.) Surprisingly. All other characters were OK. So I skipped the locale for determination of the separators and the decimal point and went for what I found in the file.
In summary: no change in locale according to the MXdiags. The problem must be somewhere in the middle between the OS and CumulusMX.
I agree, and I would point the finger at mono. Perhaps it uses a different locale or does something with it? When you did your update was there any change to something called "tzdata"? Did your update involve a reboot?
Where do I find tzdata? Ah, the package is installed but I don't no how that works, I set TZ that through the Raspbian menu. But TZ seems to be OK so far. Want details? Tell me where to look.
And no I did not reboot this morning. I just did, and cumulus just carries on with the aug.log.txt.
So, thinking clearly: I think it is best to transfer my data from the old logfile to the new one and continue until the point magically will disappear some day.
I do not see another option.
And btw, I think everybody who updates his/her system regularly gets to deal with this issue.
HansR wrote: ↑Mon 26 Aug 2019 6:55 pmAnd btw, I think everybody who updates his/her system regularly gets to deal with this issue.
Yes, the point you made makes me think perhaps some of your locale settings have changed, or perhaps are being changed by something. What does the "locale" output say?
if you ask a question like that you must specify what you want to know exactly and where you want me to get it, maybe even how.
As far as I can see, nothing has changed in the locale settings or retrievals (apart the strange thing with the decimal point as I noted, but that was long before this all started to happen).
HansR wrote: ↑Mon 26 Aug 2019 7:10 pmif you ask a question like that you must specify what you want to know exactly and where you want me to get it, maybe even how.
Type "locale" on the command line and copy/paste the results on here.
Looking at diags file from a few week back I had "2019-08-10 23:15:02.439 Current culture: English (United Kingdom)" and now I have "2019-08-26 23:34:13.555 Current culture: English (Australia)". I remember when I set this up I had "en_AU.UTF-8", so I not sure how this had changed.
I had to move the data from Aug19log to Aug19.log so that the graphs could read the log files.
Running the date command there is no Aug. : "Tue 27 Aug 07:01:39 AEST 2019"