Stopping and Starting Conventional Service Desk Services from the Command Line

Products

• CA Service Desk Manager
• CA Service Management - Service Desk Manager

Issue/Introduction

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.

Environment

Release: All releases

Resolution

Windows

To stop: net stop pdm_daemon_manager
To start: net start pdm_daemon_manager

To start secondary server or application server: net start pdm_daemon_proctor
To start primary server or Background/Standby server: net start pdm_daemon_manager

UNIX

To stop service: pdm_halt
To start service: pdm_init

Additional Information

Please note that the command pdm_init cannot be used on Windows.
The command pdm_halt is valid though.

Refer to the following documentation for additional information:

How to Start the CA SDM Servers

How to Stop the CA SDM Servers

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.

1. 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.
   
   
2. 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.