Shutting down the Server

The effect of shutting down on the server using various methods

Info & Tags

Article #:
521
Created:
06/23/06
Modified:
01/09/08

TASK

How can I safely shut down the Perforce server run on a Unix based OS?
How can I safely shut down the Perforce server running as a  Windows service?

SOLUTION

  • p4 admin stop (requires super level access)
  • kill -SIGTERM <parent PID> (or kill -15 <parent PID>)
  • kill <parent PID> (equivalent to kill -SIGTERM)
Since the "p4 admin stop" command sends a SIGTERM to the parent process ID (PID), "kill -SIGTERM <parent PID>" and "kill <parent PID>" are essentially equivalent to the "p4 admin stop" command. Any of these three can be used to gracefully shut down the server. These terminate the child processes before they complete their work, but do so only after the parent has acquired read locks on all of the database (db.*) files, which ensures that no child is writing to the database when the server is shut down, thus ensuring data integrity.
  • kill -SIGHUP <parent PID> (or kill -1 <parent PID>)
  • kill -SIGINT <parent PID> (or kill -2 <parent PID>)
  • kill -SIGKILL <parent PID> (or kill -9 <parent PID>)
These commands abruptly terminate the parent process, but allow the child processes to run to completion. While this may look attractive, it violates the principle of least surprise. Suppose that you've "shut down" the server using "kill -SIGINT <parent PID>" and are then upgrading the server. The command did not kill, for example, a child process that is connected to a submit form that was not completed because the user wanted to think on it overnight. When the user comes in the next morning and completes the form, the still-connected child process attempts to complete the submit using a now-obsolete p4d binary, with unpredictable results.

Command Details

  • p4 admin stop

    • The "admin stop" child sends SIGTERM to the parent process.
    • The "admin stop" child exits while the parent starts shutdown.
    • Parent takes read locks on all database files, in lock order.
    • With read locks held on all database files, the parent sends SIGTERM to all remaining children.
    • All remaining children exit without completing their work.
    • After all children have exited, parent unlocks all database files, in lock order.
    • The parent exits.

  • kill -SIGTERM <parent PID> or kill <parent PID>

    • Parent takes read locks on all database files, in lock order.
    • With read locks held on all database files, the parent sends SIGTERM to all remaining children.
    • All remaining children exit without completing their work.
    • After all children have exited, parent unlocks all database files, in lock order.
    • The parent exits.

  • kill -SIGHUP <parent>, kill -SIGINT <parent>, or kill -SIGKILL <parent>

    • Parent exits abruptly.
    • Remaining children each exit as they complete their work.

Special cases for Windows

If you are running the Perforce Server as a Windows Service, the process is slightly different. If you are running the Perforce Server as p4d in a command prompt, the control signals normally sent from the Service Control Manager are not available. You'll probably have to use the MKS tools or the GNU tools to perform the application kill as you would on Unix.

To kill a Windows service from the command line:
  • svcinst stop -n Perforce
  • net stop Perforce
  • sc stop Perforce
  • Rebooting the system.
Using any of the above mechanisms, the Perforce Server will begin a graceful shutdown process in virtually the same way signals are caught for the Unix SIGTERM signal.

Note:
We tell the Service Control Manager, SCM, that we expect to take 30 seconds to stop our Windows Service. In case our 30 seconds expire, we increment a checkpoint value and ask for another 30 seconds each time the SCM queries our Service for further shutdown status. As long as this checkpoint value increases, the SCM knows we are still responsive. Although at some point Windows and/or the SCM is going to get impatient and potentially kill our Server process if a pending client command takes too long. If we take too long and the SCM gets upset, you may see an "Application not responding dialog" during service stop or system shutdown.