The Perforce installer program, perforce.exe, gives you the option to install or upgrade the Perforce Server, Perforce Proxy, or the Perforce Command-Line Client.
The Perforce installer also automatically upgrades all types of Perforce servers (or services), even versions prior to 97.3. The upgrade process is extremely conservative; if anything fails at any step in the upgrade process, the installer stops the upgrade, and you are still able to use your old server (or service).
Scripted installations are controlled by a configuration file that comes with the scriptable version of the Perforce installer. You can edit this file to preconfigure Perforce environment variables (such as
P4PORT) for your environment, to automatically select Perforce client programs in use at your site, and more.
To run any task as a Windows server, a user account must be logged in, because shortcuts in a user's
Startup folder cannot be run until that user logs in. A Windows
service, on the other hand, is invoked automatically at boot time and runs regardless of whether or not a user is logged in to the machine.
Throughout most of the documentation set, the terms Perforce server or
p4d are used to refer to "the process at the back end that manages the database and responds to requests from Perforce clients". Under Windows, this can lead to ambiguity; the back-end process can run as either a service (
p4s.exe, which runs as a thread) or as a server (
p4d.exe, which runs as a regular process). From a Windows administrator's point of view, these are important distinctions. Consequently, the terminology used in this chapter uses the more precise definitions.
The Perforce service (p4s.exe) and the Perforce server (
p4d.exe) executables are copies of each other; they are identical apart from their filenames. When run, they use the first three characters of the name with which they were invoked (that is, either
p4s or
p4d) to determine their behavior. For example, invoking copies named
p4smyserver.exe or
p4dmyservice.exe invokes a service and a server, respectively.
If Perforce was installed as a service, a user with Administrator privileges can start and stop it using the applet under the . You can also stop the Perforce service from the command line with the command:
The server executable, p4d.exe, is normally found in your
P4ROOT directory. To start the server, first make sure your current
P4ROOT,
P4PORT,
P4LOG, and
P4JOURNAL settings are correct; then run:
%P4ROOT%\p4d
To start a server with settings different from those set by P4ROOT,
P4PORT,
P4LOG, or
P4JOURNAL, use
p4d command-line flags. For example:
starts a Perforce server process with a root directory of c:\test, listening to port
1999, logging errors to
c:\test\log, and with a journal file of
c:\test\journal. The
p4d command-line flags are case-sensitive.
By default, the Perforce service runs under the local System account. Because the
System account has no network access, a real userid and password are required in order to make the Perforce service work if the metadata and depot files are stored on a network drive.
If you are installing your server root on a network drive, the Perforce installer (
perforce.exe) requests a valid combination of userid and password at the time of installation. This user must have administrator privileges. (The service, when running, runs under this user name, rather than
System)
Although the Perforce service runs reliably using a network drive as the server root, there is still a marked performance penalty due to increased network traffic and slower file access. Consequently, Perforce recommends that the depot files and Perforce database reside on a drive local to the machine on which the Perforce service is running.
By default, the Perforce installer for Windows installs a single Perforce server as a single service. If you want to host more than one Perforce installation on the same machine (for instance, one for production and one for testing), you can either manually start Perforce servers from the command line, or use the Perforce-supplied utility
svcinst.exe, to configure additional Perforce services.
Understanding the precedence of environment variables in determining Perforce configuration is useful when configuring multiple Perforce services on the same machine. Before you begin, read and understand
Windows configuration parameter precedence.
|
3.
|
Create the new Perforce service using the svcinst.exe utility, as described in the example below. (The svcinst.exe utility comes with the Perforce installer, and can be found in your Perforce server root.)
|
We recommend that you install your first Perforce service using the Perforce installer. This first service is called
Perforce and its server root directory contains files that are required by any other Perforce services you create on the machine.
Create a P4ROOT directory for the new service:
Use Perforce's svcinst.exe (the service installer) to create the "
Perforce2" service:
Under Windows, Perforce configuration parameters can be set in many different ways. When a Perforce client program (such as
p4 or P4V), or a Perforce server program (
p4d) starts up, it reads its configuration parameters according to the following precedence:
|
2.
|
The P4CONFIG file, if P4CONFIG is set
|
When a Perforce service (p4s) starts up, it reads its configuration parameters from the environment according to the following precedence:
|
•
|
The tab under the dialog box in the Control Panel
|
|
•
|
The tab under the dialog box in the Control Panel
|
Many large sites run Perforce servers on Windows without incident. There are also sites in which a Perforce service or server installation appears to be unstable; the server dies mysteriously, the service can't be started, and in extreme cases, the system crashes. In most of these cases, this is an indication of recent changes to the machine or a corrupted operating system.
Though not all Perforce failures are caused by OS-level problems, a number of symptoms can indicate the OS is at fault. Examples include: the system crashing, the Perforce server exiting without any error in its log and without Windows indicating that the server crashed, or the Perforce service not starting properly.
In some cases, installing third-party software after installing a service pack can overwrite critical files installed by the service pack; reinstalling your most-recently installed service pack can often correct these problems. If you've installed another application after your last service pack, and server stability appears affected since the installation, consider reinstalling the service pack.
The reason for this is that Perforce clients sometimes use the DOS shell (cmd.exe) to start programs such as user-specified editors or diff utilities. Unfortunately, when a Windows command is run (such as a GUI-based editor like
notepad.exe) from the shell, the shell doesn't always wait for the command to complete before terminating. When this happens, the Perforce client then mistakenly behaves as if the command has finished and attempts to continue processing, often deleting the temporary files that the editor or diff utility had been using, leading to error messages about temporary files not being found, or other strange behavior.
|
•
|
Unset the environment variable SHELL. Perforce clients under Windows use cmd.exe only when SHELL is set; otherwise they call spawn() and wait for the Windows programs to complete.
|
|
•
|
Set the P4EDITOR or P4DIFF variable to the name of a batch file whose contents are the command:
|
where program is the name of the editor or diff utility you want to invoke. The
/wait flag instructs the system to wait for the editor or diff utility to terminate, enabling the Perforce client program to behave properly.
Copyright 1997-2009 Perforce Software.
