Kill a Perforce process safely

Update It should be noted that killing a Perforce process, in particular a submit, is not generally recommended. Use only when other alternatives (such as stopping the submit on the client side) or p4 monitor terminate <pid> is either not an option or doesn't appear to work.

It's nearly midday and people are complaining that the Perforce service is slow. You do a ps -ef on the server and realize that a single p4d process is consuming nearly all the memory and has been processing a monstrous submit.

Yes, it's true - a new user's gone and submitted the contents of his workstation because he set his client root to C:\ and didn't bother altering the View. Worse, he's offsite and you don't have access to his machine.

What to do? Dare you kill the Perforce process? You can't let the submit continue, the server is thrashing. But you don't want to spend the evening restoring from your checkpoint and journal file, which is a possibility if the submit is in a database update state when you kill it.

Fear not. You have other options.

First, find out what the PID of the offending process is. You can glean this from tools such as ps on Linux/Unix. Or if you have monitoring enabled on your Perforce service, a p4 monitor show all will show the offending command and its PID.

Note that the following command is for Linux/Unix/Mac. See further below for a possible Windows solution.

Once you have the PID, try the following:

p4d -c "kill <PID>"

What's the difference between doing this and simply terminating the process? When you terminate the process directly (using kill) there's a high chance that you will leave the Perforce database in an inconsistent state, requiring a checkpoint restore to fix it.

Using 'p4d -c' forces the command that follows it to execute only when the database is in a consistent state.

On Windows, the situation is more grim. Because p4s runs commands in separate threads of execution, you can't rely on 'p4d -c' because shutting down the PID will shut down the server itself.

Instead, try using p4 monitor terminate <PID> after noting the PID from p4 monitor show all. The p4 monitor terminate command instructs the offending process to terminate itself, which can take a bit longer than p4d -c but should happen in a safe manner as well.

Regardless of how you stop the submit or other command, you should always follow up with a p4d -r <P4ROOT> -xv to make sure that the database is indeed consistent.

Preferably on downtime. With the offending user splicing cat5 cable to keep you company.