Upgrade stuck at Initializing Change Management

rwatt
New Contributor II

I tried posting this yesterday, but the forums flagged it as spam for some reason. So I created a support case (JAMF-3163676), but have not heard anything.

I upgraded our JAMF 10.30.0 server to 10.31.1 last night. Everything went fine except now it's stuck at Initializing Change Management and I don't know how to fix it. There is one single error in /usr/local/jss/logs/JAMFSoftwareServer.log.

The /usr/local/jss/logs/JAMFChangeManagement.log exists and the "jamftomcat" account has permissions to modify it.

 

JAMFSoftwareServer.log:

2021-08-11 19:26:00,457 [ERROR] [erverThread] [gUncaughtExceptionHandler] - Uncaught Exception from thread InitializeServerThread - ManagerFactory [org.apache.logging.log4j.core.appender.rolling.RollingFileManager$RollingFileManagerFactory@6bfb2009] unable to create manager for [/var/log/JAMFChangeManagement.log] with data [org.apache.logging.log4j.core.appender.rolling.RollingFileManager$FactoryData@5330f439[pattern=/var/log/JAMFChangeManagement.log.%i, append=true, bufferedIO=true, bufferSize=8192, policy=SizeBasedTriggeringPolicy(size=10485760), strategy=DefaultRolloverStrategy(min=1, max=7, useMax=true), advertiseURI=null, layout=%m%n, filePermissions=null, fileOwner=null]]

 

JAMFChangeManagement.log:

[Jamf Pro System (ID: -1)] [READ] [Jamf App Settings] [Tue Jun 22 17:03:37 CDT 2021]
null
[Jamf Pro System (ID: -1)] [READ] [Jamf App Settings] [Tue Jun 22 17:03:37 CDT 2021]
null

1 ACCEPTED SOLUTION

roger_crawford
New Contributor II

The issue is noted in the release notes. It's indeed because the path specified for the Change Management logs doesn't exist. If you create the path, or change it before upgrade it'll go through just fine. 

View solution in original post

4 REPLIES 4

rwatt
New Contributor II

Sorry, I forgot to mention, but this is on CentOS 7. Also, while I was re-reading my post I noticed that the error references /var/log/JAMFChangeManagement.log, but that's wrong. All of the JAMF log files are under /usr/local/jss/logs/. Maybe the installer has a bug?

roger_crawford
New Contributor II

The issue is noted in the release notes. It's indeed because the path specified for the Change Management logs doesn't exist. If you create the path, or change it before upgrade it'll go through just fine. 

View solution in original post

rwatt
New Contributor II

Perfect! Thank you @roger_crawford! That's all I had to do. <facepalm> For anyone else:

touch /var/log/JAMFChangeManagement.log
chown jamftomcat:jamftomcat /var/log/JAMFChangeManagement.log
restart services

Much easier and simpler than rolling back with a database restore.

I will sheepishly admit that I knew that answer because I did the exact same thing! Read the release notes? Blasphemy! 😀