Upgraded from 4063 to 4067 and it failed to start

[mwittl]

Not sure if anyone else had this problem or not? I upgraded my 4063 build to 4067 and it would not start for the 1st time ever. Looked at the .ini....it erased it and replaced it with a blank one. Restored a backup .ini and same thing...Windows service would not start. Looked at .ini again and nothing pertaining to my site was there again? Thoughts?

[Mapantz]

Looks related to viewtopic.php?t=22789

[mwittl]

Yes...never saw that before but that is the issue. It didn't look like a solution was found or did I miss that? Going to stay with my 4063 until I hear something.

[SamiS]

The resolution was kind of provided in that thread Mapantz linked earlier, but not easy to spot. Check the filesystem permissions of the CumulusMX folder. Probably for some reason the user running the service does not correctly have the ”modify” permission for files and folders. You may want to disable inheritance from root (retain the existing permissions instead of removing them).

[mwittl]

Well, gave that a try. Set permissions to Full Control for all users...(Windows 11). Didn't work.....same result as before. Had to roll back to 4043 again. Thank God for Acronis.....

[freddie]

Would you be able to upload your log files from the MXdiags folder, please? Sure would help with diagnosis.

[mwittl]

Hopefully this helps! This was generated with file system set for Full Control for all users.

[SamiS]

Well, gave that a try. Set permissions to Full Control for all users...(Windows 11). Didn't work.....same result as before. Had to roll back to 4043 again. Thank God for Acronis.....

This is bad news, since it suggests that the root cause isn’t file permissions. The actual reason may be hard to find, since Mark said that the code handling the ini hasn’t changed for several versions.

FWIW you do not need Acronis, since CMX does automatic backups daily and at every restart (located under subfolder backups). But in any case it is a good practise to make a manual backup before upgrade.

And actually, if you follow the recommended upgrade method, you have a working copy ready anyway. (See the end of the post)

viewtopic.php?t=22051

[freddie]

From the log:

Code: Select all

2024-12-23 13:16:30.658 Command line: C:\CumulusMX\CumulusMX.dll 

Don't you start MX on Windows with CumulusMX.exe?

[PaulMy]

Code: Select all

Don't you start MX on Windows with CumulusMX.exe?

Yes that is how I start the program in my Windows, and select "Run as administrator".

Enjoy,
Paul

[mcrossley]

From the log:

Code: Select all

2024-12-23 13:16:30.658 Command line: C:\CumulusMX\CumulusMX.dll 

Don't you start MX on Windows with CumulusMX.exe?

On Windows you can use either the .exe, or start it the same way as on Linux, using dotnet to run the dll directly.

[mcrossley]

Though the code has not changed for a long time, the part that is failing is not invoked very often - only when a new version of MX needs to delete an obsolete entry in the Cumulus.ini file.

It does this by setting the content to be empty, then writing the new content. It looks like on some installs of Windows there is an issue doing this.

I'll look into this some more...

[mcrossley]

Could you see if the attached build fixes this?

[freddie]

From the log:

Code: Select all

2024-12-23 13:16:30.658 Command line: C:\CumulusMX\CumulusMX.dll 

Don't you start MX on Windows with CumulusMX.exe?

On Windows you can use either the .exe, or start it the same way as on Linux, using dotnet to run the dll directly.

You learn something new every day! So is the exe just a wrapper that calls dotnet to run the dll?

[mcrossley]

Sort of, it doesn't actually call the dotnet executable, but ultimately it just runs the dll where the real code resides.