Chapter 2. Installing and Configuring Performance Co-Pilot
Prev |  | Next

## Chapter 2. Installing and Configuring Performance Co-Pilot

The sections in this chapter describe the basic installation and configuration steps necessary to run Performance Co-Pilot (PCP) on your systems. The following major sections are included:

- “Product Structure” describes the main packages of PCP software and how they must be installed on each system.

- “Performance Metrics Collection Daemon (PMCD)”, describes the fundamentals of maintaining the performance data collector.

- “Installing and Removing PMDAs”, describes how to install or remove a PMDA.

- “PCP Environment Variables”, describes the environment variables supported by PCP tools.

- “Troubleshooting”, offers advice on problems involving the PMCD.

## Product Structure

In a typical deployment, Performance Co-Pilot (PCP) would be installed in a collector configuration on one or more hosts, from which the performance information could then be collected, and in a monitor configuration on one or more workstations, from which the performance of the server systems could then be monitored.

PCP is packaged into a number of basic subsystem types that reflect the functional role of the product components. These subsystems may be installed using the `inst` or `swmgr` command:

Core |  | The `pcp_eoe.sw.eoe` subsystem must be installed on every PCP enabled host, that is, on both PCP monitor and PCP collection systems.
Monitor |  | The `pcp_eoe.sw.monitor` subsystem must be installed on every PCP monitor host. The subystem `pcp_eoe.books.help` should be installed to provide help support for the GUI monitoring tools; see the `sgihelp(1)` man page.
Collector |  | No additional installation is required because the Performance Metrics Collection Daemon (`pmcd`) is in the `pcp_eoe.sw.eoe` subsystem.

For complete information on the installable software packages, see the Performance Co-Pilot release notes. For additional information, see the `relnotes(1)` or `grelnotes(1)` man pages.

## Performance Metrics Collection Daemon (PMCD)

On each Performance Co-Pilot (PCP) collection system, you must be certain that the `pmcd` daemon is running. This daemon coordinates the gathering and exporting of performance statistics in response to requests from the PCP monitoring tools.

### Starting and Stopping the PMCD

To start the daemon, enter the following commands as `root` on each PCP collection system:

    chkconfig pmcd on
    /etc/init.d/pcp start

These commands instruct the system to start the daemon immediately, and again whenever the system is booted. It is not necessary to start the daemon on the monitoring system unless you wish to collect performance information from it as well.

To stop `pmcd` immediately on a PCP collection system, enter the following command:

    /etc/init.d/pcp stop

### Restarting an Unresponsive PMCD

Often, if a daemon is not responding on a PCP collection system, the problem can be resolved by stopping and then immediately restarting a fresh instance of the daemon. If you need to stop and then immediately restart PMCD on a PCP collection system, use the `start` argument provided with the script in `/etc/init.d`. The command syntax is, as follows:

    /etc/init.d/pcp start

On startup, `pmcd` looks for a configuration file named `/etc/pmcd.conf`. This file specifies which agents cover which performance metrics domains and how PMCD should make contact with the agents. A comprehensive description of the configuration file syntax and semantics can be found in the `pmcd(1)` man page.

If the configuration is changed, `pmcd` reconfigures itself when it receives the `SIGHUP` signal. Use the following command to send the `SIGHUP` signal to the daemon:

    killall -HUP pmcd

This is also useful when one of the PMDAs managed by `pmcd` has failed or has been terminated by `pmcd`. Upon receipt of the `SIGHUP` signal, `pmcd` restarts any PMDA that is configured but inactive.

### PMCD Diagnostics and Error Messages

If there is a problem with `pmcd`, the first place to investigate should be the `pmcd.log` file. By default, this file is in the `/var/adm/pcplog` directory, although setting the `PCPLOGDIR` environment variable before running `/etc/init.d/pcp` allows the file to be relocated.

### PMCD Options and Configuration Files

There are two files that control PMCD operation. These are the `/etc/pmcd.conf` and `/etc/config/pmcd.options` files. The `pmcd.options` file contains the command line options used with PMCD; it is read when the daemon is invoked by `/etc/init.d/pcp`. The `pmcd.conf` file contains configuration information regarding domain agents and the metrics that they monitor. These configuration files are described in the following sections.

#### The `pmcd.options` File

Command line options for the PMCD are stored in the `/etc/config/pmcd.options` file. The PMCD can be invoked directly from a shell prompt, or it can be invoked by`/etc/init.d/pcp` as part of the boot process. It is usual and normal to invoke it using `/etc/init.d/pcp`, reserving shell invocation for debugging purposes.

The PMCD accepts certain command line options to control its execution, and these options are placed in the `pmcd.options` file when `/etc/init.d/pcp` is being used to start the daemon. The following options are available:

`-f` |  | Causes the PMCD to be run in the foreground. The PMCD is usually run in the background, as are most daemons.
`-i` address |  | For hosts with more than one network interface, this option specifies the interface on which this instance of the PMCD accepts connections. Multiple `-i` options may be specified. The default in the absence of any `-i` option is for PMCD to accept connections on all interfaces.
`-l` file |  | Specifies a log file. If no `-l` option is specified, the log file name is `pmcd.log` and it is created in the directory `/var/adm/pcplog` or in a directory as specified by the `PCPLOGDIR` environment variable.
`-t` seconds |  | Specifies the amount of time, in seconds, before PMCD times out on protocol data unit (PDU) exchanges with PMDAs. If no time out is specified, the default is five seconds. Setting time out to zero disables time outs. The time out may be dynamically modified by storing the number of seconds into the metric `pmcd.control.timeout` using `pmstore`.
`-T` mask |  | Specifies whether connection and PDU tracing are turned on for debugging purposes.

See the `pmcd(1)` man page for complete information on these options.

The default `pmcd.options` file shipped with PCP is similar to the following:

    # command line options to pmcd, uncomment/edit lines as required
    # longer timeout delay for slow agents
    # -t 10
    # suppress timeouts
    # -t 0
    # make log go someplace else
    # -l /some/place/else
    # enable event tracing (1 for connections, 2 for PDUs, 3 for both)
    # -T 3

The most commonly used options have been placed in this file for your convenience. To uncomment and use an option, simply remove the pound sign (#) at the beginning of the line with the option you wish to use. Restart `pmcd` for the change to take effect; that is, as superuser, enter the command:

    /etc/init.d/pcp start

#### The `pmcd.conf` File

When the PMCD is invoked, it reads its configuration file, which is `/etc/pmcd.conf`. This file contains entries that specify the PMDAs used by this instance of the PMCD and which metrics are covered by these PMDAs. Also, you may specify access control rules in this file for the various hosts on your network. This file is described completely in the `pmcd(1)` man page.

With standard PCP operation (even if you have not created and added your own PMDAs), you might need to edit this file in order to add any access control you wish to impose. If you do not add access control rules, all access for all operations is granted to all hosts. The default `pmcd.conf` file shipped with PCP is similar to the following:

    # Name  Id   IPC   IPC Params   File/Cmd
    irix    1    dso   irix_init    libirixpmda.so
    pmcd    2    dso   pmcd_init    pmda_pmcd.so
    proc    3    dso   proc_init    pmda_proc.so

| Note: Because the PMCD runs with `root` privilege, you must be very careful not to configure PMDAs in this file if you are not sure of their action. Pay close attention that permissions on this file are not inadvertently downgraded to allow public write access.

Each entry in this configuration file contains rules that specify how to connect the PMCD to a particular PMDA and which metrics the PMDA monitors. A PMDA may be attached as a Dynamic Shared Object (DSO) or by using a socket or a pair of pipes. The distinction between these attachment methods is described below.

An entry in the `pmcd.conf` file looks like this:

    label_name   domain_number   type   path

The label_name field specifies a name for the PMDA. The domain_number is an integer value that specifies a domain of metrics for the PMDA. The type field indicates the type of entry (DSO, socket, or pipe). The path field is for additional information, and varies according to the type of entry.

The following rules are common to DSO, socket, and pipe syntax:

label_name |  | An alphanumeric string identifying the agent.
domain_number |  | An unsigned integer specifying the agent's domain.

DSO entries follow this syntax:

    label_name   domain_number dso entry-point   path

The following rules apply to the DSO syntax:

`dso` |  | The entry type.
entry-point |  | The name of an initialization function called when the DSO is loaded.
path |  | Designates the location of the DSO. If path begins with a slash (/), it is taken as an absolute path specifying the DSO; otherwise, the DSO is located in one of the directories `/usr/pcp/lib` or `/var/pcp/lib`.

Socket entries in the `pmcd.conf` file follow this syntax:

    label_name   domain_number socket addr_family   address   command [args]

The following rules apply to the socket syntax:

`socket` |  | The entry type.
addr_family |  | Specifies if the socket is `AF_INET` or `AF_UNIX`. If the socket is `INET`, the word `inet` appears in this place. If the socket is `UNIX`, the word `unix` appears in this place.
address |  | Specifies the address of the socket. For INET sockets, this is a port number or port name. For UNIX sockets, this is the name of the PMDA's socket on the local host.
command |  | Specifies a command to start the PMDA when the PMCD is invoked and reads the configuration file.
args |  | Optional arguments for command.

Pipe entries in the `pmcd.conf` file follow this syntax:

    label_name   domain_number pipe protocol   command [args]

The following rules apply to the pipe syntax:

`pipe` |  | The entry type.
protocol |  | Specifies whether a text-based or a binary PCP protocol should be used over the pipes. Values for this parameter may be “text” and “binary.” The text-based protocol is provided for backwards compatibility, but otherwise its use is discouraged.
command |  | Specifies a command to start the PMDA when the PMCD is invoked and reads the configuration file.
args |  | Optional arguments for command.

#### Controlling Access to PMCD with `pmcd.conf`

You can place this option extension in the `pmcd.conf` file to control system access to performance metric data. To add an access control section, begin by placing the following line at the end of your `pmcd.conf` file:

    [access]

Below this line, you can add entries of the following forms:

    allow hostlist : operations ;  disallow hostlist : operations ;

The hostlist is a comma-separated list of host identifiers; the following rules apply:

- Host names must be in the local system's `/etc/hosts` file or known to the local DNS (domain name service).

- IP addresses may be given in the usual four-field numeric notation. Subnet addresses may be specified using three or fewer numeric components and an asterisk as a wild card for the last component in the address.

For example, the following hostlist entries are all valid:

    whizkid
    gate-wheeler.eng.com
    123.101.27.44
    localhost
    155.116.24.*
    192.*
    *

The operations field can be any of the following:

- A comma-separated list of the operation types described below.

- The word all to allow or disallow all operations as specified in the first field.

- The words all except and a list of operations. This entry allows or disallows all operations as specified in the first field except those listed.

The operations that can be allowed or disallowed are as follows:

`fetch` | Allows retrieval of information from the PMCD. This may be information about a metric (such as a description, instance domain, or help text) or an actual value for a metric.
`store` | Allows the PMCD to store metric values in PMDAs that permit store operations. Be cautious in allowing this operation, because it may be a security opening in large networks, although the PMDAs shipped with the PCP product typically reject store operations, except for selected performance metrics where the effect is benign.

For example, here is a sample access control portion of an `/etc/pmcd.conf` file:

    allow whizkid :  all ;
    allow 192.127.4.* : fetch ;
    disallow gate-inet : store ;

Complete information on access control syntax rules in the `pmcd.conf` file can be found in the `pmcd(1)` man page.

## Installing and Removing PMDAs

PCP can be expanded with new client tools and new Performance Metrics Domain Agents (PMDAs). The installation of PMDAs depends from one agent to the next, however, there are common installation and removal conventions which apply to most if not all PMDAs. The installation of some PMDAs may include configuration options which are applied to the agent at installation time. The removal of PMDAs is straight forward, where no additional parameters are required during the removal process.

Optional PCP PMDAs may be packaged as IRIX products that require `pcp_eoe` as a prerequisite. When a new PMDA product is installed on your host, the new PMDA is located in the `/var/pcp/pmdas` directory. Use the `inst` tool to install the new product as you would any other IRIX software package.

Installing a PMDA introduces it to the PCP framework, and may include the following operations:

- The creation of an entry in`/etc/pmcd.conf` to start the new PMDA and specify how the PMDA is to communicate with `pmcd(1)`, among other things.

- The specification of the extension to the PMNS in which new metrics exported by the new PMDA appear.

- The configuration of the new PMDA where configuration options are available. The user is expected to provide additional information about how a PMDA is to work for a particular installation, but often, defaults to configuration options are provided.

Example 2-1. Installing and Removing a PMDA

This example shows how to install the `mmv` PMDA (the Memory-Mapped Values PMDA) as follows:

    % su -
    Password: # cd /var/pcp/pmdas/mmv

To install a PMDA into the PCP framework, use the following command:

    # ./Install

Make sure you are in the directory where the PMDA is located when you run the `Install` script.

When `Install` is run, the following prompt appears:

    You will need to choose an appropriate configuration for installation of
    the "mmv" Performance Metrics Domain Agent (PMDA).

      collector     collect performance statistics on this system
      monitor       allow this system to monitor local and/or remote systems
      both          collector and monitor configuration for this system

    Please enter c(ollector) or m(onitor) or b(oth) [b]

The selection you make at this prompt determines whether or not the PMDA is able to collect metrics for remote systems. Details on how this affects PMDA operation are found in the documentation for the PMDA itself.

At this point, there may be other configuration options that the `Install` script presents to you. To configure the PMDA for use, use the documentation for the PMDA.

The following messages appear to indicate a successful PMDA installation:

    Updating the Performance Metrics Name Space (PMNS) ...
    Compiled PMNS contains
              497 hash table entries
             2116 leaf nodes
              359 non-leaf nodes
            21285 bytes of symbol table
    Installing pmchart view(s) ...
    Terminate PMDA if already installed ...
    Installing files ...
    Updating the PMCD control file, and notifying PMCD ...
    Check mmv metrics have appeared ... 1 warnings, 1 metrics and 0 values
    # _

The `Install` script will tell you whether the namespace has been successfully expanded to accommodate the new metrics and whether the PMDA is exporting values for those metrics.

In this example, 0 values are being exported. This is not necessarily an error; it could simply be the case that measurements could not be taken because the sources of the performance metrics may not be available (as is the case with the `mmv` PMDA). Further configuration of the PMDA may be necessary or the sources of the metrics may need to be prepared.

To remove a PMDA (using `mmv` again), perform the following:

    # ./Remove
    Culling the Performance Metrics Name Space ...
    mmv ... done
    Updating the PMCD control file, and notifying PMCD ...
    Removing files ...
    Check mmv metrics have gone away ... OK
    # _

In this example, there are no other operations that need to be performed on removal. Other PMDAs may present prompts during the removal process to which you may need to respond.

## PCP Environment Variables

When you are using PCP tools and utilities and are calling PCP library functions, a standard set of defined environment variables are available in the `/etc/pcp.conf` file. These variables are generally used to specify the location of various PCP pieces in the file system and may be loaded into shell scripts by sourcing the `/etc/pcp.env` shell script. They may also be queried by C and C++ programs using the `__pmGetConfig` library function. If a variable is already defined in the environment, the values in the `pcp.conf` file do not override those values; that is, the values in `pcp.conf` serve only as installation defaults. For additional information, see the `/etc/pcp.conf(4)`, `/etc/pcp.env(4)`, and `__pmGetConfig` man pages.

The following environment variables are recognized by PCP (these definitions are also available on the `PCPIntro(1)` man page):

`PCP_COUNTER_WRAP`
| Many of the performance metrics exported from PCP agents expect that counters increase monotonically. Under some circumstances, one value of a metric may be smaller than the previously fetched value. This can happen when a counter of finite precision overflows, when the PCP agent has been reset or restarted, or when the PCP agent exports values from an underlying instrumentation that is subject to asynchronous discontinuity. If set, the `PCP_COUNTER_WRAP` environment variable indicates that all such cases of a decreasing counter should be treated as a counter overflow; and hence the values are assumed to have wrapped once in the interval between consecutive samples. Counter wrapping was the default in versions before the PCP release 1.3.
`PCP_STDERR`
| Specifies whether `pmprintf()` error messages are sent to standard error, an `xconfirm` dialog box, or to a named file; see the `pmprintf(3)` man page. Messages go to standard error if `PCP_STDERR` is unset or set without a value. If this variable is set to `DISPLAY`, then messages go to an `xconfirm` dialog box; see the `xconfirm(1)` man page. Otherwise, the value of `PCP_STDERR` is assumed to be the name of an output file.
`PCP_TRACE_HOST`
| The `pmdatrace` library routines use this variable when connecting to the `trace` PMDA to determine on which host it is running; see the `pmdatrace(3)` man page.
`PCP_TRACE_PORT`
| This variable is used by both the `trace` PMDA and client programs using the `pmdatrace` library to obtain the Internet port through which the client programs and the PMDA communicate; see the `pmdatrace(3)` man page.
`PCP_TRACE_TIMEOUT`
| When `pmdatrace` client programs are connecting to the `trace` PMDA, this variable can be set to specify how long the clients should wait before cancelling their attempt to connect with the PMDA; see the `pmdatrace(3)` man page.
`PMCD_CONNECT_TIMEOUT`
| When attempting to connect to a remote PMCD on a system that is booting or at the other end of a slow network link, some PMAPI routines could potentially block for a long time until the remote system responds. These routines abort and return an error if the connection has not been established after some specified interval has elapsed. The default interval is 5 seconds. This may be modified by setting this variable in the environment to a larger number of seconds for the desired time out. This is most useful in cases where the remote host is at the end of a slow network, requiring longer latencies to establish the connection correctly.
`PMCD_PORT`
| This TCP/IP port is used by PMCD to create the socket for incoming connections and requests. The default is port number 4321, which you may override by setting this variable to a different port number. If a non-default port is in effect when PMCD is started, then every monitoring application connecting to that PMCD must also have this variable set in its environment before attempting a connection.
`PMCD_RECONNECT_TIMEOUT`
| When a monitor or client application loses its connection to a PMCD, the connection may be reestablished by calling the `pmReconnectContext()` PMAPI function. However, attempts to reconnect are controlled by a back-off strategy to avoid flooding the network with reconnection requests. By default, the back-off delays are 5, 10, 20, 40, and 80 seconds for consecutive reconnection requests from a client (the last delay is repeated for any further attempts after the last delay in the list). Setting this environment variable to a comma-separated list of positive integers redefines the back-off delays. For example, setting the delays to `1,2` will back off for 1 second, then back off every 2 seconds thereafter.
`PMCD_REQUEST_TIMEOUT`
| For monitor or client applications connected to PMCD, there is a possibility of the application hanging on a request for performance metrics or metadata or help text. These delays may become severe if the system running PMCD crashes or the network connection is lost or the network link is very slow. By setting this environment variable to a real number of seconds, requests to PMCD timeout after the specified number of seconds. The default behavior is to wait 10 seconds for a response from every PMCD for all applications.
`PMDA_PATH`
| This environment variable may be used to modify the search path used by PMCD and `pmNewContext()` (for `PM_CONTEXT_LOCAL` contexts) when searching for a daemon or DSO PMDA. The syntax follows the syntax for shell `PATH`: a colon-separated list of directories. The default search path is `/var/pcp/lib:/usr/pcp/lib`.
`PM_LAUNCH_PATH`
| A launching tool searches for its script in the directory specified by this variable, rather than `/var/pcp/config/pmlaunch`; see the `pmlaunch(5)` man page.
`PMLOGGER_PORT`
| This environment variable may be used to change the base TCP/IP port number used by `pmlogger` to create the socket to which `pmlc` instances try to connect. The default base port number is 4330. If used, this variable should be set in the environment before `pmlogger` is executed. If `pmlc` and `pmlogger` are on different hosts, then obviously `PMLOGGER_PORT` must be set to the same value in both places.
`PMNS_DEFAULT`
| If set, this value is interpreted as the full pathname to be used as the default PMNS for `pmLoadNameSpace()`. Otherwise, the default PMNS is located at `/var/pcp/pmns/root` for base PCP installations.

## Troubleshooting

The following sections offer troubleshooting advice on the Performance Metrics Name Space (PMNS), missing and incomplete values for performance metrics, and IRIX metrics and the PMCD.

Advice for troubleshooting the archive logging system is provided in Chapter 6, “Archive Logging”.

### Performance Metrics Name Space

To display the PMNS, use the `pminfo` command; see the `pminfo(1)` man page.

The PMNS at the collector host is updated whenever a PMDA is installed or removed, and may also be updated when new versions of the PCP or PCP add-on products are installed. During these operations, the ASCII version of the PMNS is typically updated, then the binary version is regenerated.

### Missing and Incomplete Values for Performance Metrics

Missing or incomplete performance metric values are the result of their unavailability.

#### Metric Values Not Available

The following symptom has a known cause and resolution:

Symptom: |  | Values for some or all of the instances of a performance metric are not available.
Cause: |  | This can occur as a consequence of changes in the installation of modules (for example, a DBMS or an applications package) that provide the performance instrumentation underpinning the PMDAs. Changes in the selection of modules that are installed or operational, along with changes in the version of these modules, may make metrics appear and disappear over time. In simple terms, the PMNS contains a metric name, but when that metric is requested, no PMDA at the collector host supports the metric. For archive logs, the collection of metrics to be logged is a subset of the metrics available, so utilities replaying from a PCP archive log may not have access to all of the metrics available from a live (PMCD) source.
Resolution: |  | Make sure the underlying instrumentation is available and the module is active. Ensure that the PMDA is running on the host to be monitored. If necessary, create a new archive log with a wider range of metrics to be logged.

### IRIX Metrics and the PMCD

The following issues involve the IRIX operating system and the PMCD:

- No IRIX metrics available

- Cannot connect to remote PMCD

- PMCD not reconfiguring after hang-up

- PMCD does not start

#### No IRIX Metrics Available

The following symptom has a known cause and resolution:

Symptom: |  | Some of the IRIX metrics are unavailable.
Cause: |  | PMCD (and therefore the IRIX PMDA) does not have permission to read `/dev/kmem`, or the running kernel is not the same as the kernel in `/unix`.
Resolution: |  | Check `/var/adm/pcplog/pmcd.log`. An error message of the following form means that PMCD cannot access `/dev/kmem`.
    kmeminit: cannot open "/dev/kmem": ...
Ensure that `/dev/kmem` is readable by group `sys`. For example, you should see something similar to this:
    ls -lg /dev/kmem
    crw-r-----   1 sys    1,  1 May 28 15:16 /dev/kmem
Restart PMCD after correcting the group and/or file permissions, and the problem should be solved. If the running kernel is not the same as the kernel in `/unix`, the IRIX PMDA cannot access raw data in the kernel. A message like this appears in `/var/adm/pcplog/pmcd.log`:
    kmeminit: "/unix" is not namelist for the running kernel
The only resolution to this is to make the running kernel the same as the one in `/unix`. If the running kernel was booted from the filesystem, then renaming files to make `/unix` the booted kernel and restarting PMCD should resolve the problem. If the running kernel was booted over the network, then PMCD cannot access the kernel's symbol table and hence the metrics extracted by reading `/dev/kmem` directly are not available.

#### Cannot Connect to Remote PMCD

The following symptom has a known cause and resolution:

Symptom: |  | A PCP client tool (such as `oview`, `pminfo`, or `pmlogger`) complains that it is unable to connect to a remote PMCD (or establish a PMAPI context), but you are sure that PMCD is active on the remote host.
Cause: |  | To avoid hanging applications for the duration of TCP/IP time outs, the PMAPI library implements its own time out when trying to establish a connection to a PMCD. If the connection to the host is over a slow network, then successful establishment of the connection may not be possible before the time out, and the attempt is abandoned.
Resolution: |  | Establish that the PMCD on far-away-host is really alive, by connecting to its control port (TCP port number 4321 by default):
    telnet far-away-host 4321
This response indicates the PMCD is not running and needs restarting:
    Unable to connect to remote host: Connection refused
To restart the PMCD on that host, enter the following command:
    /etc/init.d/pcp start
This response indicates the PMCD is running:
    Connected to far-away-host
Interrupt the `telnet` session, increase the PMAPI time out by setting the `PMCD_CONNECT_TIMEOUT` environment variable to some number of seconds (60 for instance), and try the PCP tool again.

#### PMCD Not Reconfiguring after `SIGHUP`

The following symptom has a known cause and resolution:

Symptom |  | PMCD does not reconfigure itself after receiving the `SIGHUP` signal.
Cause: |  | If there is a syntax error in `/etc/pmcd.conf`, PMCD does not use the contents of the file. This can lead to situations in which the configuration file and PMCD's internal state do not agree.
Resolution: |  | Always monitor PMCD's log. For example, use the following command in another window when reconfiguring PMCD, to watch errors occur:
    tail -f /var/adm/pcplog/pmcd.log

#### PMCD Does Not Start

The following symptom has a known cause and resolution:

Symptom: |  | If the following messages appear in the PMCD log (`/var/adm/pcplog/pmcd.log`), consider the cause and resolution:
    pcp[27020] Error: OpenRequestSocket(4321) bind: Address already in
    use
    pcp[27020] Error: pmcd is already running
    pcp[27020] Error: pmcd not started due to errors!
Cause: |  | PMCD is already running or was terminated before it could clean up properly. The error occurs because the socket it advertises for client connections is already being used or has not been cleared by the kernel.
Resolution: |  | Start PMCD as `root` (superuser) by typing:
    /etc/init.d/pcp start
Any existing PMCD is shut down, and a new one is started in such a way that the symptomatic message should not appear. If you are starting PMCD this way and the symptomatic message appears, a problem has occurred with the connection to one of the deceased PMCD's clients. This could happen when the network connection to a remote client is lost and PMCD is subsequently terminated. The system may attempt to keep the socket open for a time to allow the remote client a chance to reestablish the connection and read any outstanding data. The only solution in these circumstances is to wait until the socket times out and the kernel deletes it. This `netstat` command displays the status of the socket and any connections:
    netstat -a | grep 4321
If the socket is in the `FIN_WAIT` or `TIME_WAIT` state, then you must wait for it to be deleted. Once the command above produces no output, PMCD may be restarted. Less commonly, you may have another program running on your system that uses the same Internet port number (4321) that PMCD uses. Refer to the `PCPIntro(1)` man page for a description of how to override the default PMCD port assignment using the `PMCD_PORT` environment variable.

Prev | Table of Contents | Next
Chapter 1. Introduction to Performance Co-Pilot |  | Chapter 3. Common Conventions and Arguments