Cumulus Support

Seems to have been down since the midnight reboot.
Only just starting to look at diags now.

Looking at the backup directories that are created with each attempted start, they all appear to be Ok & have the same 10 files as all other backup.

Coincidentally it is the 1st of August.
Unchanged things have been fine up till now.

No file system errors. Rebooting the PC made no change.

Creating the backup folder is always the first error.

Cheers

Phil.

Ok,

Further info.

It's back up again now.
I just left it @ 8:45am with it's window open displaying the errors.

My Task Scheduler would have closed it down & restarted it just after 9:00am (Roll-over Time).
It's been running fine since then.

The Diags file created at the post 9:00 start does not display the Unhandled Exception related to the backup folder creation.

Seems it had an issue running between midnight & the 9:00am rollover into the new month.

Will add the pre & post 9:00 diags for further investigation if required.

Cheers.

Phil23 wrote: ↑Fri 31 Jul 2020 10:40 pm Looking at the backup directories that are created with each attempted start, they all appear to be Ok & have the same 10 files as all other backup.

Coincidentally it is the 1st of August.
Unchanged things have been fine up till now.

No file system errors. Rebooting the PC made no change.

Creating the backup folder is always the first error.

Cheers

Phil.

Code: Select all

2020-08-01 00:01:02.301 Cumulus start date: 29/09/2016
2020-08-01 00:01:02.316 Data path = data\
2020-08-01 00:01:02.379 Creating backup folder backup\20200801000102\
!!! Unhandled Exception !!!
System.IO.IOException: The file 'backup\20200801000102\Jul20log.txt' already exists.
   at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
   at System.IO.File.InternalCopy(String sourceFileName, String destFileName, Boolean overwrite, Boolean checkHost)
   at System.IO.File.Copy(String sourceFileName, String destFileName)
   at CumulusMX.Cumulus.Backupdata(Boolean daily, DateTime timestamp)
   at CumulusMX.Cumulus..ctor(Int32 HTTPport, Boolean DebugEnabled, Mutex appMutex)
   at CumulusMX.Program.Main(String[] args)
2020-08-01 00:01:03.160 You are not running the latest version of CumulusMX, build 3089 is available.
Exiting system due to external: Ctrl-C

A few pointers in that
* Coincidentally it is the 1st of August
* The file 'backup\20200801000102\Jul20log.txt' already exists.
* The same 10 files as all other backup.

Patch release 3.6.11 - b3087 is available for download
....
Add previous months log files (monthly and extra) to the backup on the first of the month

* This is first month change after that release announcement that suggests one extra file should be being saved on first day of month.
* You restarted MX after midnight, but before rollover.

Note - I have renamed the subject of this topic - check what word I added....
Enough said.

Well mine worked perfectly at the midnight rollover.

Found the problem. It only occurs if MX is started between midnight and 9am on the first of the month and you use a 9am rollover. After 9am on the 1st it will start OK again.

mcrossley wrote: ↑Sat 01 Aug 2020 8:40 am Found the problem. It only occurs if MX is started between midnight and 9am on the first of the month and you use a 9am rollover. After 9am on the 1st it will start OK again.

I assume you have corrected it now, but you have 30 days before you need to release the correction!

As an aside, Steve Loft used 9am/10am rollover (not the midnight rollover you use), but I recall that several of his edits also gave rise to problems when a user was restarting between midnight and a later rollover on the first day of a month!

water01 wrote: ↑Sat 01 Aug 2020 8:34 am Well mine worked perfectly at the midnight rollover.

I actually viewed your web site this morning as part of my conclusion it was related to Phil23's 9am rollover after his reboot.

At that time my 10am rollover had not happened, but when it did it also worked perfectly, 11 files (two of the standard logs) saved, but I have not closed MX since I installed the current release, so I had no reason to restart it this morning.

Phil23 wrote: ↑Fri 31 Jul 2020 10:11 pm Seems to have been down since the midnight reboot.

Going back to Phil's first post, I don't think a regular midnight reboot is a good idea. MX should not need a daily restart.

Given there are various MX actions hourly (and possibly more actions at midnight then than actions at other hours), better to restart MX at something like 12 minutes to midnight for example, when there is less potential for conflict .

sfws wrote: ↑Sat 01 Aug 2020 9:37 am

mcrossley wrote: ↑Sat 01 Aug 2020 8:40 am Found the problem. It only occurs if MX is started between midnight and 9am on the first of the month and you use a 9am rollover. After 9am on the 1st it will start OK again.

I assume you have corrected it now, but you have 30 days before you need to release the correction!

Yes fixed the code already, though as you say the problem is nearly over until next month now!

sfws wrote: ↑Sat 01 Aug 2020 9:37 am As an aside, Steve Loft used 9am/10am rollover (not the midnight rollover you use), but I recall that several of his edits also gave rise to problems when a user was restarting between midnight and a later rollover on the first day of a month!

Yep - so many pitfalls in those 9/10 hours!

sfws wrote: ↑Sat 01 Aug 2020 9:37 am Going back to Phil's first post, I don't think a regular midnight reboot is a good idea. MX should not need a daily restart.

As previously mentioned my repeated restarts are to allow Weatherlink to download data periodically.

I know 4 times a day is a bit excessive, but that how I started out & it's remained that way.
Part of that logic as keeping the WL download time small & for a period keeping it current.

Although I rarely look at WeatherLink now, I still figure why not have two separate sets of data,
particularly given that WL has a few interesting charting options that I have used occasionally.

Phil.