Perforce 2006.1 System Administrator's Guide | ||
<< Previous Chapter Tuning Perforce for Performance |
Table of Contents Index Perforce on the Web |
Next Chapter >> Perforce Proxy |
Note |
Unless otherwise specified, the material presented here applies equally to Windows NT, Windows 2000, and Windows XP. |
If you have Administrator privileges, it is usually best to install Perforce as a service. If you don't, install it as a server.
Under Windows 2000 or higher, you must have Administrator privileges to install Perforce as a service or as a server.
You are prompted to specify the location of the client executables, the port (P4PORT) on which the client should attempt to contact the Perforce server, the default editor, and the default username.
When specifying the port for the client to use, remember to include the hostname in the form hostname:port. See "Telling Perforce client programs which port to connect to" on page 13 for more about how to set P4PORT.
If the installer detects older versions of Perforce client or server software on the machine, you are given the option to rename the old executables to prevent PATH-dependent conflicts.
You are prompted to specify the directory for the client and server executables, the port on the local machine where the Perforce server or service will listen to client requests (P4PORT), the default editor, and the default username.
The installer selects default locations for the P4LOG error log file and the journal file. If an earlier version of Perforce was installed on the machine, these locations are based on those already in use.
If you have Administrator privileges, the installer installs Perforce and configures it to run as an auto-starting service. The service is set up and started after the installation is complete, and it automatically restarts whenever the machine is rebooted. If you do not have Administrator privileges, a shortcut to run Perforce as a server is placed into your Start menu.
If the installer detects older versions of Perforce client or server software on the machine, you are given the option to rename the old executables to prevent PATH-dependent conflicts.
As with the typical administrator install, you are prompted to specify the location of client and server executables, the port on the local machine where the Perforce server or service will listen to client requests, the default editor, and the default username.
Unlike the typical administrator install, you are prompted to optionally specify separate directories for the client and server executables, as well as server root, server port, and whether to set up Perforce as an auto-starting (or non-auto-starting) service or server process. The locations of any existing P4LOG file and journal file are displayed for reference, and they can be changed later using p4 set.
If you try to install a Perforce service while another Perforce server is running, the following error message is displayed:
As with the other installation options, if the installer detects older versions of Perforce client or server software on the machine, you are given the option to rename the old executables to prevent PATH-dependent conflicts.
The uninstall procedure removes everything except your server data; the Perforce server, service, and client executables, registry keys, and service entries are all deleted. The database and depot files in your server root, however, are always preserved.
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 learn more about how to automate a deployment of Perforce, see Tech Note 68 at:
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 you are running at Release 99.2 or above, you can also stop the Perforce service with the command:
You can also start the Perforce server manually from a command prompt. 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
If you want to start a server using settings different from those set by P4ROOT, P4PORT, P4LOG, or P4JOURNAL, use p4d command-line flags. For example:
Note that p4d command-line flags are case-sensitive.
If you are running at Release 99.2 or above, stop the Perforce service with the command:
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.
Warning! |
Setting up multiple services to increase the number of users you support without purchasing more user licenses is a violation of the terms of your Perforce End User License Agreement. |
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" on page 135.
To set up a second Perforce service:
You want to create a second Perforce service with a root in C:\p4root2 and a service name of
Perforce2. The svcinst executable is in the server root of the first Perforce installation you
installed in C:\perforce.
Verify that your p4d.exe executable is at Release 99.1/10994 or greater:
(If you are running an older release, you must first download a more recent release from
http://www.perforce.com and upgrade your server before continuing.)
Create a P4ROOT directory for the new service:
Copy the server executables, both p4d.exe (the server) and p4s.exe (the service), and your
license file into the new directory:
Use Perforce's svcinst.exe (the service installer) to create the "Perforce2" service:
After you create the Perforce2 service, set the service parameters for the Perforce2
service:
Finally, use the Perforce service installer to start the Perforce2 service:
The second service is now running, and both services will start automatically the next time
you reboot.
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.
Perforce is supported on Windows NT 4.0 sp6a and higher, including Windows 2000 Intel x86, Windows XP Intel x86, and Windows Server 2003.
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.
As a last resort, it might pay to install Perforce on another system to see if the same failures occur, or even to reinstall the OS and Perforce on the faulty system.
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.
You can get around this problem in two ways:
Perforce 2006.1 System Administrator's Guide | ||
<< Previous Chapter Tuning Perforce for Performance |
Table of Contents Index Perforce on the Web |
Next Chapter >> Perforce Proxy |