Service Desk may be stopped and started from the Windows command line or UNIX terminal.
This may be useful if it is required to stop or start Service Desk by a task scheduler or batch file. For example, either side of a nightly backup routine.
On a Windows system, it is an alternate method to using Windows Services.
To stop: net stop pdm_daemon_manager
To start: net start pdm_daemon_manager
If there are primary and secondary servers and you need to stop both, please run the commands as below.
To stop primary server: net stop pdm_daemon_manager
To stop secondary server: pdm_halt pdm_proctor
Allow time for the services to stop. (Optionally, include checks to confirm that the services have stopped. This lies outside of the scope of this document.)
To start secondary server: net start pdm_daemon_proctor
To start primary server: net start pdm_daemon_manager
Please note that the command pdm_init cannot be used on Windows.
The command pdm_halt is valid though.
To stop: pdm_halt
To start: pdm_init
Refer to the Unicenter Service Desk Administrator Guide for details on these commands in Appendix E, Reference Commands.
The same notes for the order of stopping and starting if secondary servers exist applies equally to UNIX as it does for Windows.
Please test the above commands thoroughly on your system looking for abnormal effects, before incorporating them into an automated process.
Although the commands as provided will reliably work as described and are considered robust, adverse results can result from two areas.
- Incorrect use of commands eg syntax errors; or the wrong order of server shutdown/restart, are two common reasons for the failure of automated scripts.
- Failure to anticipate consequences in a "real world" environment. For example, Service Desk will be unable to be stopped if it has already been stopped for another reason. It may not start if not all processes have not been cleanly shut down.
Preventative action consists of anticipating what other system events will be occurring at the time of the script, and planning for unexpected outcomes through error catching. At a minimum, the script should be monitored the first few times it is run, and checked over the first week to ensure that all aspects of Service Desk are running as expected. For example, if Attachments are not working, then the Tomcat process may not have successfully restarted.