JAMF 10.30.0 upgrade to 10.31.1 stuck at Initializing Change Management.

[rwatt]

Update 2021-09-22: Please check my other thread for the solution: https://community.jamf.com/t5/jamf-pro/upgrade-stuck-at-initializing-change-management/td-p/244134. This thread was stuck in admin approval and got released later.

I upgraded tonight from 10.30.0 to 10.31.1 and it freezes at Initializing Change Management. I'm running on CentOS 7. I have not restarted any services or rebooted yet. I use jamfproinstaller.run like always. Everything went normal at the terminal – no errors.

I checked the /usr/local/jss/logs/JAMFSoftwareServer.log and there is this one error:

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]]
java.lang.IllegalStateException: 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]]
	at org.apache.logging.log4j.core.appender.AbstractManager.getManager(AbstractManager.java:115) ~[log4j-core-2.13.3.jar:2.13.3]
	at org.apache.logging.log4j.core.appender.OutputStreamManager.getManager(OutputStreamManager.java:100) ~[log4j-core-2.13.3.jar:2.13.3]
	at org.apache.logging.log4j.core.appender.rolling.RollingFileManager.getFileManager(RollingFileManager.java:205) ~[log4j-core-2.13.3.jar:2.13.3]
	at org.apache.logging.log4j.core.appender.RollingFileAppender$Builder.build(RollingFileAppender.java:146) ~[log4j-core-2.13.3.jar:2.13.3]
	at com.jamfsoftware.logging.change.impl.ChangeManagementConfigurationServiceImpl.createRollingFileAppender(ChangeManagementConfigurationServiceImpl.java:235) ~[change-management-impl-10.31.1-t1628520988.jar:?]
	at com.jamfsoftware.logging.change.impl.ChangeManagementConfigurationServiceImpl.reset(ChangeManagementConfigurationServiceImpl.java:157) ~[change-management-impl-10.31.1-t1628520988.jar:?]
	at com.jamfsoftware.jss.server.initialization.InitializeServerThread.run(InitializeServerThread.java:534) ~[classes/:?]
	at org.springframework.security.concurrent.DelegatingSecurityContextRunnable.run(DelegatingSecurityContextRunnable.java:84) ~[spring-security-core-5.3.3.RELEASE.jar:5.3.3.RELEASE]
	at java.lang.Thread.run(Thread.java:829) [?:?]

Any ideas on what to do next?

[roger_crawford · Accepted solution]

Your change management log directory setting is set to a path that doesn't exist or the installer has no rights to. If you have access to the console you can change that path, or you can create that path on the server directly. Seems like this one's bitten a lot of us that didn't read the release notes, me included. 

[riverajo]

how do we change that path?

[rwatt]

Check my other thread: https://community.jamf.com/t5/jamf-pro/upgrade-stuck-at-initializing-change-management/td-p/244134

This message was stuck in admin approval and was released later.

[riverajo]

Thanks, I actually already have a path, I've had the path setup, configured and in use from 10.31. I was able to truncate the changemanagement entry in the DB and it allowed me access back into JAMF so I can reset the path in the configuration, but I am getting an access denied when adding that path. I suspect it may be tomcat simply doesnt have access to that file path, even though its been using it