Description:
Customers may see a few different scenarios;
Solution:
This is caused by a non-recommended setting of autoreboot=yes or =y in the <$SPECROOT>/lib/SDPM/SS.idb file.
It is strongly recommended to always set the parameter for this field to the default value, which is "no" (or "n").
If the SpectroSERVER process terminates, it is never a good practice to just start it up automatically without first running through database recovery steps. This is because corruption may occur in the active SpectroSERVER database if the SpectroSERVER terminates while threads are actively interacting with the live database (and therefore interrupted before completed).
In the event that the SpectroSERVER terminates, is best to use the Spectrum Control Panel to restore a previously saved SSdb or save and reload the current database. You will be prompted to remove the database lock file that was left behind as the result of the termination. After database recovery steps have been taken, the administrator should then manually start the SpectroSERVER via the Control Panel.
If the problem described occurs, you will need to modify the <specroot>/lib/SDPM/SS.idb to autoreboot=n. Then kill the problematic SpectroSERVER processes, do the database recovery steps as described above, then restart the SpectroSERVER.
It may be necessary to also restart the Spectrum tomcat service on the OneClick server when this occurs, to allow it to reconnect to the SpectroSERVER.