Helix Core is now P4. Product user interfaces will be updated soon. Learn more >>

P4 CLI Documentation | 2026.1

# p4 admin

Perform administrative operations on the server.

## Syntax

    p4 [g-opts] admin checkpoint [-z | -Z] [-p [-N threads] [-m]] [prefix]
    p4 [g-opts] admin journal [-z] [prefix]
    p4 [g-opts] admin stop
    p4 [g-opts] admin restart
    p4 [g-opts] admin updatespecdepot [-a | -s type]
    p4 [g-opts] admin resetpassword {-a | -u user} [-l]
    p4 [g-opts] admin setldapusers
    p4 [g-opts] admin end-journal
    p4 [g-opts] admin sysinfo
    p4 [g-opts] admin resource-monitor
    p4 [g-opts] admin replica-filter-reconcile [--restrict-only | --expand-only] [table ...]

Syntax and naming conventions

## Description

The `p4 admin` command allows P4 Server users with the `super` permission level to perform administrative tasks, even when working from a different machine than the one running the shared P4 Server service.

To stop the service, use `p4 admin stop`. This locks the database to ensure that it is in a consistent state upon restart, and then shuts down the background process.

To restart the service, use `p4 admin restart`. The database is locked, the service restarts, and some of the `p4 configure` settings that require a restart are applied.

Some configurables under Configurables reference indicate that a complete server shutdown and restart is required for a change to take effect.

### Checkpoint and journal

To take a checkpoint, use `p4 admin checkpoint [prefix]`

`p4 admin checkpoint [prefix]` is equivalent to logging in to the server machine and taking a checkpoint with `p4d -jc [prefix]`. A checkpoint is taken and the journal is copied to a numbered file. If a prefix is specified, the files are named ``prefix`.ckp.`n`` or ``prefix`.jnl.`n-1`` respectively, where `n` is a sequence number. The MD5 checksum of the checkpoint is written to a separate file, `checkpoint.`n`.md5`, and the `lastCheckpointAction` counter is updated to reflect successful completion.

Regarding the `-p` option:

- `-p` is the option for parallel processing and has sub-options for `-N numberOfThreads` and `-m` for multifile checkpointing.

- If `-N` is omitted, a checkpoint uses the number of threads specified by `db.checkpoint.threads` configurable

- If `-m` is omitted, a checkpoint will use parallel threads, but not multifile parallel threads

Checkpoints and journals use Unix epoch time. See the Timestamp and Unix epoch information.

You can store checkpoints and journals in the directory of your choice by specifying the directory as part of the prefix. (Rotated journals are stored in the `P4ROOT` directory, regardless of the directory in which the current journal is stored.) If no prefix is specified, the default filenames `checkpoint.`n`` and `journal.`n-1`` are used.

The `p4 admin journal` command is equivalent to `p4d -jj`. For details, see Triggering on journal rotation in the P4 Server Administration Documentation. The files are created in the server root specified when the Perforce service was started.

#### Alternative to p4 admin checkpoint with p4d utility

You must be connected to the server to issue the `p4 admin checkpoint` command, and P4 Server must be running.

For an alternative that does not require P4 Server to be running, see Checkpoint and journal options of the p4d utility in the P4 Server Administration Documentation.

### Spec depot

The `p4 admin updatespecdepot` command causes the service to archive stored forms into the spec depot.

If the `-a` option is used, all of the form specification types are archived.

If the `-s` option option is used:

- Only those of the specified type are archived
- The other types are created in the spec depot

### LDAP

The `p4 admin setldapusers` command allows you to convert all existing non-super users to use LDAP authentication. The command changes the `AuthMethod` field in the user specification for each user from `perforce` to `ldap`. If `super` users want to use LDAP authentication, they must set their `AuthMethod` manually.

## Options

### p4 admin resetpassword

The `p4 admin resetpassword` command forces specified users with existing passwords to change their passwords before they can run another command. To force all users with legacy passwords to reset their passwords and upgrade to scrypt storage, a super user can run the p4 admin resetpassword -a -l command. The password storage type is shown in the output of the p4 -ztag users -l command.

Since 2025.1, passwords stored by P4 are hashed with the scrypt key derivation function. For users with passwords stored with the stronger hashing algorithm, plaintext and prehashed passwords will no longer be accepted by means of the -P global flag, the P4PASSWD environment variable, or setters in the P4 API for C/C++. These were previously only accepted up to security level 2. Users with passwords stored prior to upgrading to 2025.1 or above will be unaffected. The legacy password storage and behaviors at low security levels will continue to work until the users reset their passwords.

`-a` | All users
`-u user` | The specified user
-l | Super user

This command works only for users whose `authMethod` is set to `perforce`. However, you can use it in a mixed environment, that is an environment in which authentication is based both on P4 Server and LDAP.

- To force password reset of all users with passwords (including the user with `super` permission who issued the command), use `p4 admin resetpassword -a`.
- To force a single users to reset their password, use `p4 admin resetpassword -u user`.

### p4 admin checkpoint

Option | Description
--- | ---
`-p` | Requests a parallel checkpoint.
`-N threads` | Specifies the number of threads to use during the parallel request.
`-m` | Uses multiple files if there are multiple parallel threads because db.checkpoint.threads is greater than `1` or the `-N` option is greater than `1`. See Parallel checkpointing, dumping and recovery in the P4 Server Administration Documentation. See also Checkpoint examples.
`-z` | Save the checkpoint and journal file in compressed format. The `.gz`suffix is appended to compressed journals and checkpoint files, which are in gzip format. If you do not specify `-z` or `-Z`, no compression occurs.
`-Z` | For `p4 admin checkpoint -Z`, save the checkpoint in compressed format, but leave the journal uncompressed for use by replica servers. The `.gz`suffix is appended to compressed journals and checkpoint files, which are in gzip format. If you do not specify `-z` or `-Z`, no compression occurs.
`prefix` | If a `prefix` is specified, the files are named ``prefix`.ckp.`n``, where `n` is a sequence number.

### p4 admin journal

`-z` | Save the journal file in compressed format. The `.gz`suffix is appended to compressed journals and checkpoint files, which are in gzip format. If you do not specify `-z`, no compression occurs.
`prefix` | If a `prefix` is specified, the files are named ``prefix`.jnl.`n-1``, where `n` is a sequence number.

### p4 admin updatespecdepot

`-a` | For `p4 admin updatespecdepot -a`, update the spec depot with all current forms.
`-s type` | For `p4 admin updatespecdepot -s`, update the spec depot with forms of the specified type, where type is one of `client`, `depot`, `repo`, `branch`, `label`, `typemap`, `group`, `user`, `job`, `stream`, `triggers`, `protect`, `server`, `license`, `jobspec`.

### p4 admin resource-monitor

This command monitors resources on the host operating system that the P4 Server is running on. This is the command that provides the information the P4 Server uses to throttle incoming client commands in order to keep itself responsive and from overloading the operating system. This command is intended to be run as a server startup command, one per server instance. Setting the `sys.pressure.os.[mem|cpu].high` configurables to zero disables checking for the given resource. To learn more, see System resources in the P4 Server Administration Documentation.

### p4 admin replica-filter-reconcile

By default, if the filtering rules change in a replica A P4 Server that automatically maintains a full or partial copy of the central server's metadata and that might contain related file content. The replica copies by using 'p4 pull' or 'p4 journalcopy'. A replica can be used as a backup server for disaster recovery. or edge server A server that is part of a commit-edge environment that can independently support work in progress for locally-bound clients, thereby reducing the load on the commit server. spec, replication adjusts automatically. A set of `rpl.filter.*` configurables controls the behavior.To learn more, see Automatic replica filter reconciliation in P4 Server Administration Documentation.

It is also possible to manually perform the replica filter reconciliation with the `p4 admin replica-filter-reconcile` command, which provides these options.

- `--restrict-only` reconcile the replica database by only removing applicable database records.

- `--expand-only` reconcile the replica database by only adding applicable database records.

- `[table ...]` allows specifying one or more tables the reconciliation applies to, which is not possible with the default automatic reconciliation. For example:
  `p4 admin replica-filter-reconcile db.have db.rev`

An expansions of the database of a replica or edge server might impact replication performance while the upstream server Any server in the inward direction, that is, toward the central server. For example, in an edge-to-edge configuration with a commit, edge1, and edge2, both edge1 and the commit server are upstream servers for edge2. See also 'central server'. creates additional journal records and transfers them to the downstream server.

### p4 admin sysinfo

`p4 admin sysinfo` dumps the output of reporting commands as run on the server host operating system. This is intended for use under guidance of Perforce Support to gather information about the environment of P4 Server.

`g-opts` | See Global options.

## Usage notes

Can file arguments use revision specifier? | Can file arguments use revision range? | Minimal access level required | Command alias
--- | --- | --- | ---
N/A | N/A | super the `checkpoint`, `journal`, `stop`, and `restart` options are available to an operator user | `p4 admin journal` is equivalent to `p4d -jj` p4 admin checkpoint is equivalent to `p4d -jc` `p4 dbstat`, `p4 lockstat`, and `p4 logstat` are standalone commands but the old `p4 admin` syntax remains as an alias for backward compatibility.

- To require all newly-created users with passwords to reset their passwords before invoking their first command, set the dm.user.resetpassword configurable:

  `p4 configure set dm.user.resetpassword=1`

  Running `p4 admin resetpassword -a` resets only the passwords of users who presently exist (and who have passwords).

- Because `p4 admin stop` shuts down the Perforce service, you might see an error message indicating that the connection was closed unexpectedly. You can ignore this message.
- The spec depot must exist before running `p4 admin updatespecdepot`.

## Examples

`p4 admin stop`
Stop the shared service

`p4 admin restart`
This form of server restart is adequate for some, but not all, configurable changes to take effect. See the "Server restart required?" column of the tables of the Configurables reference.

### Checkpoint examples

`p4 admin checkpoint`
Create a checkpoint named `checkpoint.`n``, and start a new journal named `journal`, copying the old journal file to `journal.`n-1``, where `n` is a sequence number.

`p4 admin checkpoint name`
Create a checkpoint named `name.ckp.`n``, and start a new journal named `journal`, copying the old journal file to `name.jnl.`n-1``, where `n` is a sequence number.

`p4 admin checkpoint -Z -p -N 8 -m /mnt/p4depot/BACKUP/checkpoint/checkpoint_dir`
Create a checkpoint, compressing the checkpoint (not the journal), in multifile (`-m`) parallel (`-p`), with 8 threads, and using the prefix specified in the final argument.

### Journal examples

`p4 admin journal`
Rotates the active journal for an incremental backup between checkpoints.

`p4 admin end-journal`
In a failover scenario, this command: Ends journal replication at the most recent successfully replicated consistency point Returns the journal number and the offset of that consistency point Stops the standby server's `journalcopy` thread

## Related commands

To see the status of the last checkpoint | `p4 counter` lastCheckpointAction

Your search for returned results