Cumulus.ini corruption

[Vegit8]

Has anyone else suffered odd corruption of the Cumulus.ini file.
I have had a couple of instances where the extra web files page has had altered data.
I’m wondering if it has anything to do with the fact that these pages are ‘self saving’, in other words they don’t need updating via a save button.
Additionally I think it happens if the MX application is not exited cleanly.

[mcrossley]

I doubt it has anything to do with the "self saving". Those values are written to a new copy of Cumulus.ini every time they are changed.

Cumulus writes out a copy of the Cumulus.ini when it shuts down (controlled). But of course it writes the file in the order you see it. If the write was being terminated then I'd expect the file to incomplete. If you just have corrupted entries, then you would think the values Cumulus is holding in memory must be corrupt too - as that is what it writes out.

Were your files being processed correctly up to the point of shutdown? Does the MXdiags log confirm this?

Assuming Cumulus had been running longer than a day - are the rollover backup copies of Cumulus.ini corrupted as well?

[Vegit8]

The corruption idea was my attempt to understand what was happening with my friends new site.
The static pages were updating but the gauges page was not.
I have now got hold of his .ini file and all seems to be as I left it when I set it up.

Having looked at his site via Filezilla, there are two files that have not updated since yesterday afternoon gauges-ss.htm and betel_datasummary.php
All the others are updating successfully.
I will try to get the diags file from him next.
It's all a bit odd, everything was working fine for a few days.
I doubt whether he will have changed anything he is not IT literate.
More to follow

[Vegit8]

MX Diags info

File (system) started at 11:40 on the 12/03/20
First instance of an error occurred at 14:27 on the 14th

2020-03-14 14:27:10.500 ERROR: No broadcast data received from the WLL for 30 seconds
2020-03-14 14:46:51.846 Warning, previous realtime ftp still in progress, skipping this period.
2020-03-14 14:46:53.072 ERROR: No broadcast data received from the WLL for 30 seconds
2020-03-14 14:47:13.968 SFTP: Error uploading realtime.txt to /public_html/weather/realtime.txt : Channel was closed.
2020-03-14 14:47:13.970 SFTP: Error uploading web/realtimegauges.txt to /public_html/weather/realtimegauges.txt : The session is not open.
2020-03-14 14:47:13.970 SFTP: Error uploading /Users/charlesdowding/CumulusMX/web/realtimegaugesT.txttmp to public_html/weather/realtimegauges.txt : The session is not open.
2020-03-14 14:47:13.970 SFTP: Error uploading /Users/charlesdowding/CumulusMX/web/gauges-ssT.htmtmp to public_html/weather/gauges-ss.htm : The session is not open.
2020-03-14 14:47:13.970 SFTP: Error uploading /Users/charlesdowding/CumulusMX/web/betel_datasummaryT.htmtmp to public_html/weather/betel_datasummary.php : The session is not open.

After this these lines keep repeating themselves.
The .json files, all the htm files are being updated with current data.
The charts display current data.
the dayfile.txt is uploaded regularly (I forgot to switch it to 'end of day')

The FTP permissions for the 2 files that are erroring are the same as the other files..

I'm at a loss.

[water01]

The files that are failing, are there by any chance zero length files for those files on the web site server. For some reason sometimes if there is a zero length file present the upload fails. Just delete those files and on the next upload they will work correctly.

[Vegit8]

No... All files are longer than zero bytes.

[Vegit8]

Restarted Cumulus
All seems OK.
Wonder if this is some sort of error that needs to be trapped and exited from.

[mcrossley]

The symptom is similar to this one - caused by Windows update KB4540673, which I haven't got to the bottom of yet.

There is a problem with the Cumulus real-time FTP recovery after a failure - depending on the failure mode, it may never try to reconnect. That is fixed in the next release.

I see you haven't sorted out the WLL broadcasts being blocked yet...

ERROR: No broadcast data received from the WLL for 30 seconds

[Vegit8]

Hi Mark
This system is running under MONO on an iMac, so I am guessing the problem is not quite the same as the windows update one.

As for the WLL error... the answer is no.
I have not been able to get back to the users house yet.
I'll need to get into his router and open up ports.
I think he has a BT router, and I know from past experience that these are not the easiest to configure.
As you said the other day UDP packets should just get through, but obviously they are not.
IS WLL live pushing data or is Cumulus pulling it?

[mcrossley]

Cumulus sends a command to the WLL to start broadcasting for 300 minutes. The WLL then just sends out a UDP multi-cast every 2.5 seconds. Cumulus gives it a poke for another 300 minutes every 150 minutes to make sure it doesn't stop.