Perforce Server (p4d) Reference
Synopsis
Start the Perforce service or perform checkpoint/journaling (system administration) tasks.
Syntax
p4d
[options
]p4d.exe
[options
]p4s.exe
[options
]p4d
-j? [ -z | -Z ] [args
... ]
Description
The first three forms of the command invoke the background process that manages the Perforce versioning service. The fourth form of the command is used for system administration tasks involving checkpointing and journaling.
On UNIX and Mac OS X, the executable is p4d
.
On Windows, the executable is p4d.exe
(running as a server) or
p4s.exe
(running as a service).
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
Server options | Meaning |
---|---|
|
Run as a daemon (in the background) |
|
Run as a single-threaded (non-forking) process |
|
Run from |
|
Run quietly (no startup messages) |
|
Write the PID of the server to a file named The |
|
Irreversibly reconfigure the Perforce server (and its metadata) to operate in Unicode mode. Do not use this option unless you know you require Unicode mode. See the Release Notes and Internationalization Notes for details. |
|
Run database upgrades and exit. This will no longer run automatically if there are fewer than 1000 changelists. Upgrades must be run manually unless the server is a DVCS personal server; in this case, any upgrade steps are run automatically. |
|
Run low-level database validation and quit. |
|
Run fast verification; do not lock database tables, and verify only that the unlock count for each table is zero. |
|
Display (or set) the server’s |
General options | Meaning |
---|---|
|
Print help message. |
|
Print version number. |
|
Specify an audit log file. Overrides |
|
A server description for use with |
|
A server name for use with |
|
Specify a journal file. Overrides |
|
Specify a log file. Overrides |
|
Specify a port to listen to. Overrides |
|
Specify the server root directory. Overrides |
|
Set trace options. Overrides value |
|
Force the service to operate in case-insensitive mode on a normally case-sensitive platform. |
|
Write the server’s PID to the specified file. Default name for the file is |
Checkpointing options | Meaning |
---|---|
|
Lock database tables, run |
|
Journal-create; checkpoint and In this case, your checkpoint and journal files are named
WarningIf you use this option, it must be the last option on the command line. |
|
Journal-checkpoint; create checkpoint and |
|
Journal-only; save and truncate journal without checkpointing. |
|
Journal-restore; restore metadata from a checkpoint and/or journal file. If you specify the |
|
Verify the integrity of the checkpoint or journal specified by
This command does not replay the journal. Use the |
|
Compress (in When you use this option with the
creates two files: |
|
Compress (in |
Journal restore options | Meaning |
---|---|
|
Journal-restore with integrity-checking. Because this option locks the
database, this option is intended only for use by replica servers
started with the |
|
Allow replaying a checkpoint over an existing database.
(Bypass the check done by the |
|
Read |
|
Ignore failures to delete records; this meaning of As with all journal-restore commands, if you specify the |
|
Schedule new revisions for replica network transfer. Required only in
environments that use |
|
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 technical support. |
Replication and multi-server options | Meaning |
---|---|
|
In multi-server environments, specify an authentication server for
licensing and protections data. Overrides |
|
In multi-server environments, specify a changelist server from which
to obtain changelist numbers. Overrides |
|
For replicas, specify the target (master) server from which to pull
data. Overrides |
|
For replicas, authenticate as the specified |
Journal dump/restore filtering | Meaning |
---|---|
|
Dump This command can also be used with non-journaled tables. |
|
Dump a set of named tables to a single dump |
|
Dump all tables except the named tables to the dump |
|
Specify filter patterns for This option is useful for seeding a filtered replica. |
|
Restore from |
|
Restore from |
Certificate Handling | Meaning |
---|---|
|
Generate SSL credentials files for the server: create a private key
and certificate file in Requires that |
|
Display the fingerprint of the server’s public key, and exit. Administrators can communicate this fingerprint to end users, who can
then use the |
Configuration options | Meaning |
---|---|
|
Display the contents of |
|
Set a Perforce configurable without starting the service, optionally specifying the server for which the configurable is to apply. For example, p4d -r . "-cset replica#P4JOURNAL=off" p4d -r . "-cset replica#P4JOURNAL=off replica#server=3" It is best to include the entire |
|
Unset the specified configurable. |
Usage Notes
- On all systems, journaling is enabled by default. If
P4JOURNAL
is unset whenp4d
starts, the default location for the journal is$P4ROOT
. If you want to manually disable journaling, you must explicitly setP4JOURNAL
tooff
. - Take checkpoints and truncate the journal often, preferably as part of your nightly backup process.
- Checkpointing and journaling preserve only your Perforce 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 Perforce database.
- If your users use triggers, don’t use the
-f
(non-forking mode) option; the Perforce service needs to be able to spawn copies of itself ("fork") in order to run trigger scripts. - 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 fromP4ROOT
. This way, in the event of corruption of the filesystem containingP4ROOT
, the journal is likely to remain accessible. - The database upgrade option (
-xu
) can require considerable disk space. See the Release Notes for details when upgrading.