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

P4 Server Administration Documentation | 2025.1

# P4 Server (p4d) reference

Start the Perforce service, perform checkpoint/journaling, or perform certain system administration tasks.

## Syntax

    p4d [ options ]
    p4d.exe [ options ]
    p4s.exe [ options ]
    p4d -j? [-z | -Z] [ args ... ]
    p4d [-z] -R service -jr file
    p4d [-z] [-R service | -P server-id] -jd file
    p4d -Fm | Fs

## Description

Command | Use Case
--- | ---
p4d [ options ] p4d.exe [ options ] p4s.exe [ options ] | Invoke the background process that manages the P4 Server versioning service.
p4d -j? [ -z | -Z ] [ args ... ] | For certain system administration tasks, including some that are related to checkpointing and journaling. See Checkpoint files.
p4d -Fm | Fs | Failback options

Journal rotation The process of renaming the current journal to a numbered journal file as part of a checkpoint. means saving the existing journal and creating a new, empty journal for future transactions.

"Truncating" a journal refers to the new journal file starting out as an empty file.

On UNIX and macOS, the executable is `p4d`.

On Windows, the executable is `p4d.exe` (running as a server) or `p4s.exe` (running as a service).

### These commands should be run during quiet periods

Run the following commands during production downtime or quiet periods. These commands lock tables and therefore might block user commands.

Option | Table locking behavior
--- | ---
`-jd`, `-jc`, `-jcp`, -jcpm | All tables are locked while the command runs and are unlocked as it completes.
`-xu` | Tables are locked and unlocked one at a time as preparation for the upgrade is done.
`-xv` | Tables are locked and unlocked one at a time as they are being validated.
`-xx` | Tables are locked and unlocked as they are being checked against each other. More than two tables might be locked. For example, the check for `db.have` against `db.rev` also locks `db.revtx`
`-xvU` | Tables are locked and unlocked as they are being checked.

## Exit status

After successful startup, `p4d` does not normally exit. It merely outputs the following startup message:

    Perforce server starting...

and runs in the background.

On failed startup, `p4d` returns a nonzero error code.

Also, if invoked with any of the `-j` checkpointing or journaling options, `p4d` exits with a nonzero error code if any error occurs.

## Options

This section includes the following types of options: Server options, General options, Checkpoint and journal options, Journal restore options, Replication and multi-server options, Journal dump and restore filtering, Certificate handling, Configuration options, and Failback options.

### Server options

Server option | Meaning
--- | ---
`-d` | Run as a daemon (in the background).
`-f` | Run as a single-threaded (non-forking) process.
`-i` | Run from `inetd` on UNIX.
`-q` | Run quietly (no startup messages).
`-n` | Start the server in maintenance mode, which means that: the server is only able to perform commands that do not require a client the user and file count restrictions listed in the license file are not enforced
`--pid-file[=file]` | Write the PID of the server to a file named `server.pid` in the directory specified by `P4ROOT`, or write the PID to the file specified by `file`. This makes it easier to identify a server instance among many. The `file` parameter can be a complete path specification. The file does not have to reside in `P4ROOT`.
`--daemonsafe` | Is like `-d` and forks the `p4d` into the background, but also closes the stdio (standard input output) files.
`-xi` | Irreversibly reconfigure the P4 Server (and its metadata) to operate in Unicode mode. Do not use this option unless you know you require Unicode mode. For details, see the Release Notes and the Internationalization Notes.
`-xj` | Directly dump the db.ckphist table (see the schema of the P4 Server). This option is similar to the p4 journals command. The use case for `-xj` is to allow you to create a script that determines when a particular checkpoint has completed because it displays the `db.ckphist` table. For an example of such a script, see Poll for the ckphist record under How to know the parallel checkpoint has completed. `-xj [--limit num] [--jfield flist] [--fieldname fieldvalue]` display checkpoint history records from `db.ckphist` `--limit` restricts the output to the first `num` entries `--jfield` selects the record fields to be displayed from `flist` `flist` is a comma separated list of field names. Valid field names are: `start`, `startDate`, `end`, `endDate`, `pid`, `type`, `flags`, `jnum`, `jfile`, `jdate`, `jdateDate`, `jdigest`, `jsize`, `jtype`, `failed`, `errmsg` Note that the `failed` and `errmsg` fields are only present in failed operations. `--fieldname fieldname` is one of the valid record fields, such as `--jnum` or `--type` Select only those records where the `fieldname` field matches `fieldvalue` A `jnum` value of `0` matches any record with an unset `jnum` field (displayed as `-1`). The special `fieldname` of `result` with a value of `pass` selects only successful operations, whereas a value of `failed` selects only unsuccessful operations.
`-xu` | Run database upgrades and quit. Upgrades must be run manually unless the server is a DVCS personal server, which runs upgrade steps automatically. Prepare to run a later major release of the server. See Upgrade the server. Tables are locked and unlocked one at a time as preparation for the upgrade is done.
`-xv` | Run low-level database validation and quit. With no table arguments, validates all tables. If one or more table arguments are provided, only the specified tables are validated. For example: `p4d -xv db.rev db.change db.have` Tables are locked and unlocked one at a time as they are being validated. See also `p4 dbverify` in the P4 CLI Reference.
`-xx [-q -o output] [table1 [table2]]` | Check consistency between table pairs, producing a `jnl.fix` file. To restrict output to show only inconsistent tables, use the `-q` option. If table names are specified, only those tables are checked. Check the `jnl.fix` file for accuracy before attempting any updates. To specify a filename other than `jnl.fix`, use the `-o` option. Tables are locked and unlocked as they are being checked against each other. More than two tables might be locked. The `db.integed`/`db.rev` table pair appears twice in the command output because this table pair check is done in both the `toFile` direction and in the `fromFile` direction. Do not attempt to replay the `jnl.fix` file into your depot without consulting Perforce Support.
`-xvU` | Run fast verification. Does not lock database tables, and verifies only that the unlock count for each table is zero. See also `p4 dbverify` in the P4 CLI Reference.
`-xD [serverID]` | Display (or set) the server’s `serverID` (stored in the `server.id` file) and exit.
-xU CleanServerLocks | Safely cleans up the server locks directory, which can help avoid the possible issue of running out of inodes. (See also the Perforce Knowledge Base article about possible causes of the message No space left on device.)

### General options

General option | Meaning
--- | ---
`-h`, `-?` | Print help message.
`-V` | Print version number, and other information, such as which memory manager the server uses.
`-A auditlog` | Specify an audit log P4 Server supports the standard log, which is human-readable, as well as structured logs in a comma-separated value (CSV) format. The P4LOG environment variable specifies the log file for events, including errors. The human-readable P4AUDIT environment variable specifies the log file that records file transfers to users. Structured log files are typically processed by external tools. To learn more, see 'Logging" in P4 Server Administration Documentation. file. Overrides `P4AUDIT` setting. Default is null.
`-Id description` | A server description displayed by the `p4 -z tag info` command. Overrides `P4DESCRIPTION` setting.
`-J journal` | Specify a journal file. Overrides `P4JOURNAL` setting. Default is `journal`. (Use `-J off` to disable journaling.)
`-L log` | Specify a log file. Overrides `P4LOG` setting. Default is `STDERR`.
`-p port` | Specify a port to listen to. Overrides `P4PORT`. Default `1666`.
`-r root` | Specify the server root directory. Overrides `P4ROOT`. Default is current working directory.
`-v subsystem=level` | Set debug level. Overrides value `P4DEBUG` setting. Default is null.
`-C1` | Force the service to operate in case-insensitive mode on a normally case-sensitive platform.
`--pid-file[=name]` | Write the server’s PID to the specified file. Default name for the file is `server.pid`.
`--show-realtime` | Display Monitor the server in real-time monitoring on the command line. For details of this feature, see `p4 monitor realtime` in the P4 CLI Reference.

### Checkpoint and journal options

We assume you have read the Backup procedure topic.

To improve performance, consider Parallel checkpointing, dumping, and recovery, which is available in checkpoint options that support parallel threads: `-jcp`, `-jcpm`, `-jdp`, `-jdpm`, and `-jvp`

Checkpointing option | Meaning
--- | ---
`-c command` | Lock database tables, run `command`, unlock the tables, and exit.
`-jc [-Z | -z] [prefix]` | Create checkpoint and rotate the journal. All tables are locked while the command runs and are unlocked as it completes. Rotating the journal means saving the existing journal and creating a new journal for future transactions. `p4d -jc` creates a new `checkpoint.n` and rotates the current journal to a numbered journal that corresponds to the now previous checkpoint, `journal.n-1` In this case, your checkpoint and journal files are named `prefix.ckp.n` and `prefix.jnl.n` respectively, where `prefix` is as specified on the command line and `n` is a sequence number. If no `prefix` is specified, the default file names `checkpoint.n` and `journal.n` are used. Setting the `journalPrefix` configurable overrides the default prefix and directory location for rotated journals and checkpoints. You can store checkpoints and journals in the directory of your choice by specifying the directory as part of the prefix. With `-z`, both the checkpoint and the journal are compressed. With `-Z`, only the checkpoint is compressed. The journal is left uncompressed. Without `-z` or `-Z`, the checkpoint and journal files are not compressed.
`-jcp [-Z | -z] [prefix]` or `-jcp [-N numberOfThreads] [-Z | -z] [prefix]` or `-jcpm [-N numberOfThreads] [-Z | -z] [prefix]` | Same as the `-jc` row above, except that including `p` supports parallel threads, and using `-N numberOfThreads` overrides the `db.checkpoint.threads` configurable. `m` is the multifile option. See Parallel checkpointing, dumping, and recovery. See also Checkpoints for database tree rebalancing.
`-jd [-z] file` | Create checkpoint without saving or rotating the journal. With `-z`, the checkpoint is compressed. All tables are locked while the command runs and are unlocked as it completes.
`-jdp [-N numberOfThreads] [-z] directory` or `-jdpm [-N numberOfThreads] [-z] directory` | Same as the `-jd` row above, except that including `p` supports parallel threads, and using `-N numberOfThreads` overrides the `db.checkpoint.threads` configurable. `m` is the multifile option. See Parallel checkpointing, dumping, and recovery.
`[-R service | -P server-id] -jd [-z] file` | Similar to `-jd [-z] file`, but create a checkpoint:
If using -R service | If using -P server-id
--- | ---
appropriate for a server providing the services specified by the `-R service` option, such as `-R commit-server` or `-R edge-server` | with data relevant to the configured server that has the server ID specified using `-P`, which causes a journal header to be written containing the server ID
All tables are locked while the command runs and are unlocked as it completes.
`-jj [-z] [ prefix ]` | Rotate the journal, and no checkpointing occurs. Including `-z` causes the journal to be compressed. Your journal file is named `prefix.jnl.n`, where `prefix` is as specified on the command line and `n` is a sequence number. If no `prefix` is specified, the default filename `journal.n` is used. You can store journals in the directory of your choice by specifying the directory as part of the prefix.
`-jv file` or `-jvp [-N numberOfThreads] directory` | Verify the integrity of the checkpoint or journal specified by `file` as follows: Can the checkpoint or journal be read from start to finish? If it is zipped, can it be successfully unzipped? If it has an MD5 file with its MD5, does it match? Does it have the expected header and trailer? This command does not replay the journal. Including `p` supports parallel threads, and using `-N numberOfThreads` overrides the `db.checkpoint.threads` configurable. See Parallel checkpointing, dumping, and recovery.
`-z` | Compress (in `gzip` format) checkpoints and journals. When you use this option with the `-jd` option, P4 Server automatically adds the `.gz` extension to the checkpoint file. So, the command: `p4d -jd -z myCheckpoint` creates two files: `myCheckpoint.gz` and `myCheckpoint.md5`. Downstream replicas cannot read from a compressed journal. Therefore, if you have downstream replicas, use -Z instead of -z. Add more content if needed
`-Z` | Compress (in `gzip` format) checkpoint, but leave journal uncompressed for use by replica servers. That is, it applies to `-jc`, not `-jd`. Can be used when taking a checkpoint that rotates the journal: p4d -jc -Z The -Z option is not used for recovery: p4d -jr

### Journal restore options

Journal restore option | Meaning
--- | ---
`-jr file` | Restore metadata from a checkpoint and/or journal file. If the journal header in the checkpoint file contains a server ID and the checkpoint file was created by `p4d -P serverID -jd file`, a `server.id` file will be created containing that server ID. If you specify the `-r $P4ROOT` option on the command line, the `-r` option must precede the `-jr` option. When using a relative path to identify the file, the path is relative to the `P4ROOT` folder, not the location from which you ran the command.
`-jrp [-N numberOfThreads] directory` | Same as the row above, except that the p option supports parallel threads. Using `-N numberOfThreads` overrides the `db.checkpoint.threads` configurable. See Parallel checkpointing, dumping, and recovery.
`-R service -jr file` | Similar to `-jr` for restoring metadata from a checkpoint and/or journal file, but only restore metadata appropriate for the service type that is specified by the `-R service` option, such as `-R commit-server` or `-R edge-server` The `-R edge-server` option is useful for the initial seeding of edge servers. If the journal header in the checkpoint file contains a server ID and the checkpoint file was created by `p4d -P serverID -jd file`, a `server.id` file will be created containing that server ID.
`-jrc file` | Journal-restore with integrity-checking. Because this option locks the database, this option is intended only for use by replica servers started with the `p4 replicate` command.
`-jrF file` | Allow replaying a checkpoint over an existing database. (Bypass the check done by the `-jr` option to see if a checkpoint is being replayed into an existing database directory by mistake.)
`-jro file` | With the `o` suboption, override the setting of the `client.readonly.dir` configurable with the value in the journal for partitioned-jnl client recovery.
`-b batch -jr file` | Read `batch` lines of journal records, sorting and removing duplicates before updating the database. The default is `5000`, but can be set to `1` to force serial processing. This combination of options is intended for use with replica servers started with the `p4 replicate` command.
`-f -jr file` | Ignore failures to delete records. This meaning of `-f` applies only when `-jr` is present. This combination of options is intended for use with replica servers started with the `p4 replicate` command. By default, journal restoration halts if record deletion fails. As with all journal-restore commands, if you specify the `-r $P4ROOT` option on the command line, the `-r` option must precede the `-jr` option.
`-m -jr file` | Schedule new revisions for replica network transfer. Required only in environments that use `p4 pull -u` for archived files, but `p4 replicate` for metadata. Not required in replicated environments based solely on `p4 pull`.
`-s -jr file` | Record restored journal records into regular journal, so that the records can be propagated from the server’s journal to any replicas downstream of the server. This combination of options is intended for use in conjunction with Perforce Support.
`-S -jr file` | Ignores all storage records in the replay file and instead recalculates the net storage reference count change from the revision records. Applies the recalculated reference count at the end of the replay or the end of each transaction. Like the `-s` option, the `-S` option cannot be combined with the `-m` option. This combination of options impacts the performance of journal replay. It is intended for small fixes under the guidance of Perforce Support.

### Replication and multi-server options

Replication and multi-server option | Meaning
--- | ---
`-a host:port` | In multi-server environments, specify an authentication server for licensing and protections data. Overrides `P4AUTH` setting. Default is null.
`-g host:port` | In multi-server environments, specify a changelist server from which to obtain changelist numbers. Overrides `P4CHANGE` setting. Default is null.
`-t host:port` | For replicas, specify the target server The immediately upstream server for replica servers, edge servers, standby servers, proxies and brokers. See also 'upstream server' and 'central server'. from which to pull data. Overrides `P4TARGET` setting. Default is null.
`-u serviceuser` | For replicas, authenticate as the specified `serviceuser` when communicating with the target server. The service user must have a valid ticket before replica operations will succeed.

### Journal dump and restore filtering

Journal dump/restore filtering | Meaning
--- | ---
`-jd file db.table` or `-jdp -N n` or `-jdpm -N n]` | Dump `db.table` by creating a checkpoint `file` that contains only the data stored in `db.table`. This command can also be used with non-journaled tables. `p` supports parallel threads, and [`-N n`] is the number of threads `m` is the multifile option See Parallel checkpointing, dumping, and recovery
`-k db.table1,db.table2,... -jd file` | Dump a set of named tables to a single dump `file`.
`-K db.table1,db.table2,... -jd file` | Dump all tables except the named tables to the dump `file`.
`-P serverid -jd file` | Specify filter patterns for `p4d -jd` by specifying a `serverid` from which to read filters (see `p4 help server`, or use the older syntax described in `p4 help export`). This option is useful for seeding a filtered replica.
`-R service -jd file` | This option is useful for the initial seeding of edge servers. Filter tables based on the `service` specified: `edge-server` excludes the tables that are specific to edge servers `commit-server` includes all tables
`-R service -jd -l` | Information only: The -l option lists the files that would be excluded from a database dump for the initial seeding of an edge server.
`-k db.table1,db.table2,... -jr file` | Restore from `file`, including only journal records for the tables named in the list specified by the `-k` option.
`-K db.table1,db.table2,... -jr file` | Restore from `file`, excluding all journal records for the tables named in the list specified by the `-K` option.

### Certificate handling

Certificate Handling | Meaning
--- | ---
`-Gc` | Generate SSL credentials files for the server: create a private key and certificate file in `P4SSLDIR`, and then exit. Requires that `P4SSLDIR` be set to a directory that is owned by the user invoking the command, and that is readable only by that user. If `config.txt` is present in `P4SSLDIR`, generate a self-signed certificate with specified characteristics.
`-Gf` | Display the fingerprint of the server’s public key, and exit. Administrators can communicate this fingerprint to end users, who can then use the p4 trust command to determine whether or not the fingerprint (of the server to which they happen to be connecting) is accurate.

### Configuration options

Configuration option | Meaning
--- | ---
`-cshow` | Display the contents of `db.config` without starting the service. (That is, run `p4 configure show allservers`, but without a running service.)
`-cset server#var=val` | Set a P4 Server configurable without starting the service, optionally specifying the server for which the configurable is to apply. For example,
    p4d -r . "-cset replica#track=1"
    p4d -r .  "-cset replica#track=1 replica#server=3"
It is best to include the entire `variable`=`value` expression in quotation marks.
`-cunset server#var` | Unset the specified configurable.

### Failback options

In regard to Failback after failover, we recommend that you first preview the commands and only include `-y` if the preview looks acceptable.

Command | Purpose
--- | ---
`p4d -r p4root -Fm targetServerID standbyServerID` | To preview the conversion of the original target server The immediately upstream server for replica servers, edge servers, standby servers, proxies and brokers. See also 'upstream server' and 'central server'. to a standby for the current target server.
`p4d -r p4root -y -Fm targetServerID standbyServerID` | To perform the conversion of the original target server to a standby for the current target server. The converted standby will then be ready for a later p4 failback command.
`p4d -r p4root -Fs targetServerID standbyServerID` | (Optional) To preview the conversion of the original standby server to a standby for the restored target server.
`p4d -r p4root -y -Fs targetServerID standbyServerID` | (Optional) To perform the conversion of the original standby server to a standby for the restored target server.

## Usage notes

- Do not run p4d as root. See Run the P4 Server (p4d) as an unprivileged user.
- On all systems, journaling is enabled by default. If `P4JOURNAL` is unset when `p4d` starts, the default location for the journal is `$P4ROOT`. If you want to manually disable journaling, you must explicitly set `P4JOURNAL` to `off`.
- Take checkpoints and truncate the journal often, preferably as part of your nightly backup process.
- Checkpointing and journaling preserve only your P4 Server metadata (data about your stored files). The stored files themselves (the files containing your source code) reside under `P4ROOT` and must be also be backed up as part of your regular backup procedure.
- It is best to keep journal files and checkpoints on a different hard drive or network location than the P4 Server database.
- If your users use triggers, don’t use the `-f` (non-forking mode) option. To run trigger scripts, the Perforce service needs to be able to "fork" (spawn copies of itself).
- After a hardware failure, the options required for restoring your metadata from your checkpoint and journal files can vary, depending on whether data was corrupted.
- Because restorations from backups involving loss of files under `P4ROOT` often require the journal file, we strongly recommend that the journal file reside on a separate filesystem from `P4ROOT`. This way, in the event of corruption of the filesystem containing `P4ROOT`, the journal is likely to remain accessible.
- The database upgrade option (`-xu`) can require considerable disk space. For details, see the Release Notes.

## Examples of typical tasks

Task | Command
--- | ---
To start the service, listening to port `1999`, with journaling enabled and written to `journalfile`. | `p4d -d -p 1999 -J /opt/p4d/journalfile`
To checkpoint a server with a non-default journal file, the `-J` option (or the environment variable `P4JOURNAL`) must match the journal file specified when the server was started. | Checkpoint with: `p4d -J /p4d/jfile -jc` or `P4JOURNAL=/p4d/jfile ; export P4JOURNAL; p4d -jc`
To compress checkpoints and journals, which creates two files: myCheckpoint.gz and myCheckpoint.md5. | p4d -jd -z myCheckpoint
To create a compressed checkpoint from a server with files in directory `P4ROOT`. | `p4d -r $P4ROOT -z -jc`
To create a compressed checkpoint with a user-specified prefix of “myCheckpoint” from a server with files in directory `P4ROOT`. | `p4d -r $P4ROOT -z -jc myCheckpoint`
To restore metadata from a checkpoint named `checkpoint.3` for a server with root directory `P4ROOT`. | `p4d -r $P4ROOT -jr checkpoint.3`
To restore metadata from a compressed checkpoint named `checkpoint.3.gz` for a server with root directory `P4ROOT`. | `p4d -r $P4ROOT -z -jr checkpoint.3.gz`
To list, with -l, which files would be excluded in a database dump to seed an edge server. (Information only.) | `p4d -R edge -jd -l`

Your search for returned results