Perforce 2003.1 System Administrator's Guide
<< Previous Chapter
Tuning Perforce for Performance
Table of Contents
Index
Perforce on the Web
Next Chapter >>
Perforce Proxy

Chapter 8
Perforce and Windows

This chapter describes certain information of specific interest to administrators who set up and maintain Perforce servers on Windows.

Note

Unless otherwise specified, the material presented here applies equally to Windows NT, Windows 2000, and Windows XP.

Using the Perforce installer

The Perforce installer program, perforce.exe, gives you the option to install either as a user (the Perforce client), a typical administrator (Perforce installed as a Windows service), a custom administrator (Perforce installed as a service with additional customization options), or to uninstall Perforce from your system.

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 need Administrator privileges to install Perforce as a service, and Power User privileges to install Perforce as a server.

Upgrade notes

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 will stop the upgrade, and you will still be able to use your old server (or service).

Installation options

When you invoke the installer, it presents an initial screen that lists the revisions of the Perforce software you're about to install. You are offered the choice between:

User install

The "user install" installs only the Perforce Comnand-Line Client (p4.exe), Perforce Windows Client (P4Win), and (optionally) the third-party SCM plug-in. If you are running on Windows 95 or Windows 98, this will be the only installation option available to you. Under Windows 2000 or higher, this option requires Power User privileges.

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, don't forget to include the hostname in the form hostname:port. See "Telling Perforce client programs which port to talk to" on page 13 for details on 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.

Administrator typical

The "typical administrator install" allows the installation of both client and server software for Perforce. This option requires administrator privileges.

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 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.

Administrator custom

The "custom administrator install" allows the installation of both client and server software for Perforce. This option requires administrator privileges.

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 allowed 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 may be changed later using p4 set.

If you try to install a Perforce service while another Perforce server is running, you will see the error message:

Failure to shut down the running Perforce server(s) will result in conflicts between the newly installed service and the existing server.

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.

Uninstalling Perforce

Should you wish to remove Perforce from a Windows machine, run perforce.exe and select the Uninstall option. This option requires administrator privileges.

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.

Windows services vs. Windows servers

To run any task as a Windows server, a user account must be logged in, as 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 will invoke a service and a server, respectively.

Starting and stopping the Perforce service

If Perforce was installed as a service, a user with Administrator privileges can start and stop it using the Services applet in the Control Panel.

If you are running at Release 99.2 or above, you can also use the command:

to stop the Perforce service.

Starting and stopping the Perforce server

If Perforce was installed as a server, there should be a "Perforce Server" shortcut in your Start menu. To start the server, double-click on the shortcut. To stop the server, right-click on the "Perforce Server" button in the taskbar and select "Close".

You can also start the Perforce server manually from an MS-DOS window. 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 than those set by P4ROOT, P4PORT, P4LOG, or P4JOURNAL, you can use p4d command line flags. For example:

will start 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.

Note that p4d command line flags are case sensitive.

If you are running at Release 99.2 or above, use the following command:

to stop the Perforce server.

Note

If you are running Release 99.1 or earlier, type Ctrl-C in the MS-DOS window, or simply Close the MS-DOS window.

Although this works in all versions of Perforce, this method of shutting down the server is not necessarily "clean", and with the availability of the p4 admin stop command in 99.2, is no longer recommended.

Installing the Perforce service on a network drive

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 will also run as this user, rather than System)

While the Perforce NT service will run reliably using a network drive as the server root, there is still a marked performance penalty due to of increased network traffic and slower file access. For this reason, we recommend that the depot files and Perforce database be on a drive local to the machine on which the Perforce service is running.

Multiple Perforce services under Windows

By default, the Perforce installer for Windows installs a single Perforce server as a single service. If you wish to host more than one Perforce installation on the same machine (for instance, one for production and one for testing), then the additional Perforce servers must be started manually.

You can, however, install additional services to start up additional Perforce servers (that is, running as Windows services) automatically.

Note

You must download Perforce 99.1/10994 or a later release in order to use this procedure.

If your intent is to set up multiple services to increase the number of users you support without purchasing more user licenses, you are violating the terms of your Perforce License Agreement.

Before you begin, you should read and understand "Windows configuration parameter precedence" on page 116. Once you understand the precedence of environment variables in determining Perforce configuration, you'll find setting up multiple Perforce services to be straightforward. To add a new service, you need to:

  1. Create a new directory for the Perforce service.

  2. Copy the server executable, service executable, and your license file into this directory.

  3. Create the new Perforce service using the svcinst.exe utility, as described in the example below.

  4. Set up the environment variables and start the new service.

We recommend that you install your first Perforce service using the Perforce installer. This first service will be called "Perforce" and its server root directory will contain a few files which are required for the other Perforce services.

Windows configuration parameter precedence

Under Windows, Perforce configuration parameters may be set in many different ways. When a Perforce client program (such as p4 or P4Win), or a Perforce server program (p4d) starts up, it reads its configuration parameters according to the following precedence:

  1. The program's command line flags have the highest precedence.

  2. The P4CONFIG file, if P4CONFIG is set.

  3. User environment variables.

  4. System environment variables.

  5. The Perforce user registry (set by p4 set).

  6. The Perforce system registry (set by p4 set -s).

As of Release 99.1/10994, when a Perforce service (p4s) starts up, it reads its configuration parameters from the environment according to the following precedence:

  1. Windows service parameters (set by p4 set -S servicename) have the highest precedence.

  2. System environment variables.

  3. The Perforce system registry (set by p4 set -s).

User environment variables can be set with any of the following:

System environment variables can be set with:

Resolving Windows-related instabilities

There are many large sites running Perforce on Windows without incident. There are also sites in which 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.

While not all Perforce failures are caused by OS-level problems, a number of symptoms may 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 NT service not starting properly.

Many of these problems may be resolved by installing Service Packs. A machine running NT 4.0 with Service Pack 6 and a plain VGA video driver is very stable.

In particular, Perforce support personnel have also found that many sites have been able to reduce or eliminate OS-level instability problems by re-installing NT Service Pack 6; consequently, we recommend that SP6 be installed on any NT system running the Perforce server or service.

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 will 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 may 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.

Users having trouble with P4EDITOR or P4DIFF

Your Windows users may experience difficulties using the Perforce Comnand-Line Client (p4.exe) if they use the P4EDITOR or P4DIFF environment variables.

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, the DOS shell knows that when a Windows command is run (such as a GUI-based editor like notepad.exe), it doesn't have to wait for the command to complete before terminating. When this happens, the Perforce client then mistakenly believes that 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 errors about temporary files not being found, or other strange behavior.

You can get around this problem in two ways:

where program is the name of the editor or diff utility you wish to invoke. The /wait flag instructs the system to wait for the editor or diff utility to terminate, and the Perforce client will then behave properly.

Some Windows editors (most notably, Wordpad) do not behave properly, even when instructed to wait. There is presently no workaround for such programs.


Perforce 2003.1 System Administrator's Guide
<< Previous Chapter
Tuning Perforce for Performance
Table of Contents
Index
Perforce on the Web
Next Chapter >>
Perforce Proxy
Please send comments and questions about this manual to [email protected].
Copyright 1999-2003 Perforce Software. All rights reserved.
Last updated: 07/07/03