A PCP client tool (such as pmchart, pmie, 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.

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.

Alternatively, there may be a firewall in-between the client tool and PMCD which is blocking the connection attempt.

Finally, PMCD may be running in a mode where it does not acept remote connections, or only listening on certain interface.

Establish that the PMCD on far-away-host is really alive, by connecting to its control port (TCP port number 44321 by default):

telnet far-away-host 44321

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:

${PCP_RC_DIR}/pmcd 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 client tool again.

Verify that PMCD is not running in local-only mode, by looking for an enabled value (one) from:

pminfo -f pmcd.feature.local

This setting is controlled from the PMCD_LOCAL environment variable usually set via ${PCP_SYSCONFIG_PATH}/pmcd.

If these techniques are ineffective, it is likely an intermediary firewall is blocking the client from accessing the PMCD port - resolving such issues is firewall-host platform-specific and cannot practically be covered here.