Provided by: pcp_3.5.11_amd64 bug

NAME

       pmcd - performance metrics collector daemon

SYNOPSIS

       pmcd  [-f]  [-i  ipaddress] [-l logfile] [-L bytes] [-n pmnsfile] [-p port[,port ...]  [-q
       timeout] [-T traceflag] [-t timeout] [-x file]

DESCRIPTION

       pmcd is the collector used  by  the  Performance  Co-Pilot  (see  PCPIntro(1))  to  gather
       performance  metrics on a system.  As a rule, there must be an instance of pmcd running on
       a system for any performance metrics to be available to the PCP.

       pmcd accepts connections from client applications running either on the  same  machine  or
       remotely  and  provides  them  with metrics and other related information from the machine
       that pmcd is executing on.  pmcd delegates most of this request servicing to a  collection
       of Performance Metrics Domain Agents (or just agents), where each agent is responsible for
       a particular group of metrics, known as the domain of the agent.  For example the  environ
       agent  is responsible for reporting information relating to the environment of a Challenge
       system, such as the cabinet temperature and voltage levels of the power supply.

       The agents may be processes started by  pmcd,  independent  processes  or  Dynamic  Shared
       Objects  (DSOs,  see  dso(5)) attached to pmcd's address space.  The configuration section
       below describes how connections to agents are specified.

       The options to pmcd are as follows.

       -f     By default pmcd is started as a daemon.  The -f option indicates that it should run
              in  the  foreground.   This  is  most  useful when trying to diagnose problems with
              misbehaving agents.

       -i ipaddress
              This option is usually only used on hosts with more than one network interface.  If
              no  -i  options are specified pmcd accepts connections made to any of its host's IP
              (Internet Protocol) addresses.  The -i option is used to specify explicitly  an  IP
              address  that  connections  should  be  accepted  on.   ipaddress  should be in the
              standard dotted form (e.g. 100.23.45.6).  The -i option may be used multiple  times
              to  define  a list of IP addresses.  Connections made to any other IP addresses the
              host has will be refused.  This can be used to limit  connections  to  one  network
              interface  if  the  host is a network gateway.  It is also useful if the host takes
              over the IP address of another host that has failed.  In such a situation only  the
              standard  IP addresses of the host should be given (not the ones inherited from the
              failed host).  This allows PCP applications to determine that a  host  has  failed,
              rather  than  connecting  to  the  host that has assumed the identity of the failed
              host.

       -l logfile
              By default a log file named pmcd.log is written in the directory $PCP_LOG_DIR/pmcd.
              The  -l option causes the log file to be written to logfile instead of the default.
              If the log file cannot be created or is not writable,  output  is  written  to  the
              standard error instead.

       -L bytes
              PDUs  received  by pmcd from monitoring clients are restricted to a maximum size of
              65536 bytes by default to defend against Denial of Service attacks.  The -L  option
              may be used to change the maximum incoming PDU size.

       -n pmnsfile
              Normally  pmcd  loads  the  default  Performance  Metrics  Name  Space  (PMNS) from
              $PCP_VAR_DIR/pmns/root, however if  the  -n  option  is  specified  an  alternative
              namespace is loaded from the file pmnsfile.

       -q timeout
              The pmcd to agent version exchange protocol (new in PCP 2.0 - introduced to provide
              backward compatibility) uses this timeout to specify  how  long  pmcd  should  wait
              before  assuming that no version response is coming from an agent.  If this timeout
              is reached, the agent is assumed to be an agent which does not understand  the  PCP
              2.0  protocol.   The  default  timeout  interval is five seconds, but the -q option
              allows an alternative timeout interval (which must be  greater  than  zero)  to  be
              specified.  The unit of time is seconds.

       -t timeout
              To   prevent  misbehaving  agents  from  hanging  the  entire  Performance  Metrics
              Collection System (PMCS), pmcd uses timeouts on PDU exchanges with  agents  running
              as  processes.   By  default  the  timeout interval is five seconds.  The -t option
              allows an alternative timeout interval in seconds to be specified.  If  timeout  is
              zero,  timeouts  are  turned  off.   It  is  almost  impossible to use the debugger
              interactively on an agent unless timeouts have been turned  off  for  its  "parent"
              pmcd.

              Once pmcd is running, the timeout may be dynamically modified by storing an integer
              value (the timeout in seconds) into the metric pmcd.control.timeout via pmstore(1).

       -T traceflag
              To assist with error diagnosis for agents and/or  clients  of  pmcd  that  are  not
              behaving  correctly,  an internal event tracing mechanism is supported within pmcd.
              The value of traceflag is interpreted as a bit field  with  the  following  control
              functions:

              1   enable client connection tracing
              2   enable PDU tracing
              256 unbuffered event tracing

              By  default, event tracing is buffered using a circular buffer that is over-written
              as new events are recorded.  The default buffer size  holds  the  last  20  events,
              although  this  number  may be over-ridden by using pmstore(1) to modify the metric
              pmcd.control.tracebufs.

              Similarly once pmcd is running,  the  event  tracing  control  may  be  dynamically
              modified    by   storing   1   (enable)   or   0   (disable)   into   the   metrics
              pmcd.control.traceconn, pmcd.control.tracepdu and  pmcd.control.tracenobuf.   These
              metrics  map  to  the  bit fields associated with the traceflag argument for the -T
              option.

              When operating in buffered mode, the event trace buffer will be dumped whenever  an
              agent connection is terminated by pmcd, or when any value is stored into the metric
              pmcd.control.dumptrace via pmstore(1).

              In unbuffered mode, every event will be reported when it occurs.

       -x file
              Before the pmcd logfile can be opened, pmcd  may  encounter  a  fatal  error  which
              prevents it from starting.  By default, the output describing this error is sent to
              /dev/tty but it may redirected to file.

       If a PDU exchange with an agent times out, the agent has violated the requirement that  it
       delivers metrics with little or no delay.  This is deemed a protocol failure and the agent
       is disconnected from pmcd.  Any subsequent requests for information from  the  agent  will
       fail with a status indicating that there is no agent to provide it.

       It  is  possible to specify host-level access control to pmcd.  This allows one to prevent
       users from certain hosts from accessing the metrics provided by pmcd and is  described  in
       more detail in the Section on ACCESS CONTROL below.

CONFIGURATION

       On  startup  pmcd  looks  for  a  configuration  file named $PCP_PMCDCONF_PATH.  This file
       specifies which agents cover which performance metrics domains and how  pmcd  should  make
       contact  with  the  agents.  An optional section specifying host-based access controls may
       follow the agent configuration data.

       Warning: pmcd is usually started as part of the boot  sequence  and  runs  as  root.   The
       configuration  file may contain shell commands to create agents, which will be executed by
       root.  To prevent security breaches the configuration file  should  be  writable  only  by
       root.  The use of absolute path names is also recommended.

       The  case  of  the reserved words in the configuration file is unimportant, but elsewhere,
       the case is preserved.

       Blank lines and comments are permitted (even encouraged) in  the  configuration  file.   A
       comment  begins with a ``#'' character and finishes at the end of the line.  A line may be
       continued by ensuring that the last character on the  line  is  a  ``\''  (backslash).   A
       comment on a continued line ends at the end of the continued line.  Spaces may be included
       in lexical elements by enclosing the entire  element  in  double  quotes  (there  must  be
       whitespace  before the opening and after the closing quote).  A double quote preceded by a
       backslash is always a literal double quote.  A ``#'' in double quotes  or  preceded  by  a
       backslash  is  treated literally rather than as a comment delimiter.  Lexical elements and
       separators are described further in the following sections.

AGENT CONFIGURATION

       Each line of the agent configuration section of the configuration file contains details of
       how  to  connect  pmcd  to  one of its agents and specifies which metrics domain the agent
       deals with.  An agent may be attached as a DSO, or via a socket, or a pair of pipes.

       Each line of the agent configuration section of the configuration file must be  either  an
       agent  specification,  a  comment,  or  a  blank  line.  Lexical elements are separated by
       whitespace characters, however a single agent specification may not be broken across lines
       unless a \ (backslash) is used to continue the line.

       Each  agent  specification must start with a textual label (string) followed by an integer
       in the range 1 to 510.  The label is a tag used to refer to  the  agent  and  the  integer
       specifies  the  domain  for  which  the  agent  supplies  data.   This  domain  identifier
       corresponds to the domain portion of the PMIDs handled by the agent.  Each agent must have
       a unique label and domain identifier.

       For DSO agents a line of the form:

              label domain-no dso entry-point path

       should appear.  Where,

       label         is a string identifying the agent
       domain-no     is an unsigned integer specifying the agent's domain in the range 1 to 510
       entry-point   is  the name of an initialization function which will be called when the DSO
                     is loaded
       path          designates the location of the DSO. This field  is  treated  differently  on
                     Irix and on Linux. Later expects it to be an absolute pathname, while former
                     uses some heuristics to find an agent. If path begins with a / it  is  taken
                     as  an  absolute  path  specifying  the  DSO. If path is relative, pmcd will
                     expect to find the agent in a file with  the  name  mips_simabi.path,  where
                     simabi  is either o32, n32 or 64.  pmcd is only able to load DSO agents that
                     have  the  same  simabi  (Subprogram  Interface  Model   ABI,   or   calling
                     conventions)  as  it  does  (i.e.  only  one  of the simabi versions will be
                     applicable).  The simabi version of a running  pmcd  may  be  determined  by
                     fetching  pmcd.simabi.   Alternatively,  the  file(1) command may be used to
                     determine the simabi version from the pmcd executable.

                     For a relative path the environment variable PMCD_PATH defines a  colon  (:)
                     separated list of directories to search when trying to locate the agent DSO.
                     The default search path is $PCP_SHARE_DIR/lib:/usr/pcp/lib.

       For agents providing socket connections, a line of the form

              label domain-no socket addr-family address [ command ]

       should appear.  Where,

       label         is a string identifying the agent
       domain-no     is an unsigned integer specifying the agent's domain in the range 1 to 510
       addr-family   designates whether the socket is in the AF_INET or AF_UNIX domain,  and  the
                     corresponding values for this parameter are inet and unix respectively.
       address       specifies  the  address  of the socket within the previously specified addr-
                     family.  For unix sockets, the address should be  the  name  of  an  agent's
                     socket  on  the  local host (a valid address for the UNIX domain).  For inet
                     sockets, the address may be either a port number or a port name which may be
                     used  to  connect  to  an  agent  on the local host.  There is no syntax for
                     specifying an agent on a remote host as a pmcd deals only with agents on the
                     same machine.
       command       is  an  optional parameter used to specify a command line to start the agent
                     when pmcd initializes.  If command is not present,  pmcd  assumes  that  the
                     specified  agent  has  already  been  created.  The command is considered to
                     start from the first non-white character after the socket address and finish
                     at the next newline that isn't preceded by a backslash.  After a fork(2) the
                     command is passed unmodified to execve(2) to instantiate the agent.

       For agents interacting with the pmcd via stdin/stdout, a line of the form:

              label domain-no pipe protocol command

       should appear.  Where,

       label         is a string identifying the agent
       domain-no     is an unsigned integer specifying the agent's domain
       protocol      The value for this parameter should be binary.

                     Additionally, the protocol can include the notready keyword to indicate that
                     the  agent  must be marked as not being ready to process requests from pmcd.
                     The agent will explictily notify the pmcd when it is ready  to  process  the
                     requests by sending PM_ERR_PMDAREADY PDU.

       command       specifies  a  command  line  to start the agent when pmcd initializes.  Note
                     that command is mandatory for pipe-based agents.  The command is  considered
                     to start from the first non-white character after the protocol parameter and
                     finish at the next newline that isn't preceded  by  a  backslash.   After  a
                     fork(2)  the  command  is  passed unmodified to execve(2) to instantiate the
                     agent.

ACCESS CONTROL CONFIGURATION

       The access control section of the configuration file is optional, but if present  it  must
       follow the agent configuration data.  The case of reserved words is ignored, but elsewhere
       case is preserved.  Lexical elements in  the  access  control  section  are  separated  by
       whitespace  or the special delimiter characters: square brackets (``['' and ``]''), braces
       (``{'' and ``}''), colon (``:''),  semicolon  (``;'')  and  comma  (``,'').   The  special
       characters are not treated as special in the agent configuration section.

       The access control section of the file must start with a line of the form:

       [access]

       Leading  and trailing whitespace may appear around and within the brackets and the case of
       the access keyword is ignored.  No other text may appear on the  line  except  a  trailing
       comment.

       Following  this  line,  the  remainder of the configuration file should contain lines that
       allow or disallow operations from particular hosts or groups of hosts.

       There are two kinds of operations that occur via pmcd:

       fetch          allows retrieval of information from pmcd.  This may be information about a
                      metric  (e.g. its description, instance domain or help text) or a value for
                      a metric.

       store          allows pmcd to be used to store metric values in agents that  permit  store
                      operations.

       Access to pmcd is granted at the host level, i.e. all users on a host are granted the same
       level of  access.   Permission  to  perform  the  store  operation  should  not  be  given
       indiscriminately; it has the potential to be abused by malicious users.

       Hosts  may  be  identified  by name, IP address or a wildcarded IP address with the single
       wildcard character ``*'' as the last-given component of the IP address.   Host  names  may
       not be wildcarded.  The following are all valid host identifiers:

            boing
            localhost
            giggle.melbourne.sgi.com
            129.127.112.2
            129.127.114.*
            129.*
            *

       The following are not valid host identifiers:

            *.melbourne
            129.127.*.*
            129.*.114.9
            129.127*

       The  first  example  is  not  allowed  because  only  (numeric) IP addresses may contain a
       wildcard.  The second example is not  valid  because  there  is  more  than  one  wildcard
       character.   The  third contains an embedded wildcard, the fourth has a wildcard character
       that is not the last component of the IP address (the last component is 127*).

       The name localhost is given special treatment to make the  behavior  of  host  wildcarding
       consistent.   Rather  than  being  127.0.0.1,  it  is  mapped  to  the  primary IP address
       associated with the name of the host on which  pmcd  is  running.   Beware  of  this  when
       running pmcd on multi-homed hosts.

       Access for hosts are allowed or disallowed by specifying statements of the form:

              allow hostlist : operations ;
              disallow hostlist : operations ;

       hostlist      is a comma separated list of host identifiers.

       operations    is a comma separated list of the operation types described above, all (which
                     allows/disallows  all  operations),  or   all   except   operations   (which
                     allows/disallows all operations except those listed).

       Where  no  specific allow or disallow statement applies to an operation for some host, the
       default is to allow the operation from that host.  In the trivial case when  there  is  no
       access  control  section  in  the  configuration  file,  all operations from all hosts are
       permitted.

       If a new connection to pmcd is attempted from a host that is not permitted to perform  any
       operations,   the   connection   will  be  closed  immediately  after  an  error  response
       PM_ERR_PERMISSION has been sent to the client attempting the connection.

       Statements with  the  same  level  of  wildcarding  specifying  identical  hosts  may  not
       contradict  each  other.   For  example  if  a  host  named  clank  had  an  IP address of
       129.127.112.2, specifying the following two rules would be erroneous:

            allow clank : fetch, store;
            disallow 129.127.112.2 : all except fetch;

       because they both refer to the same host, but disagree as to whether the  fetch  operation
       is permitted from that host.

       Statements  containing  more  specific  host  specifications  override  less specific ones
       according to the level of wildcarding.  For example a rule of the form

            allow clank : all;

       overrides

            disallow 129.127.112.* : all except fetch;

       because the former contains a specific host name  (equivalent  to  a  fully  specified  IP
       address), whereas the latter has a wildcard.  In turn, the latter would override

            disallow * : all;

       It  is  possible to limit the number of connections from a host to pmcd.  This may be done
       by adding a clause of the form

              maximum n connections

       to the operations list of an allow statement.  Such a clause may not be used in a disallow
       statement.   Here, n is the maximum number of connections that will be accepted from hosts
       matching the host identifier(s) used in the statement.

       An access control statement with a list of host identifiers is equivalent to  a  group  of
       access  control  statements,  with each specifying one of the host identifiers in the list
       and all with the same  access  controls  (both  permissions  and  connection  limits).   A
       wildcard should be used if you want hosts to contribute to a shared connection limit.

       When  a  new  client  requests  a  connection, and pmcd has determined that the client has
       permission to connect, it searches the matching list of access control statements for  the
       most  specific  match containing a connection limit.  For brevity, this will be called the
       limiting statement.   If  there  is  no  limiting  statement,  the  client  is  granted  a
       connection.   If  there  is  a  limiting  statement and the number of pmcd clients with IP
       addresses that match the host identifier in  the  limiting  statement  is  less  than  the
       connection  limit  in  the statement, the connection is allowed.  Otherwise the connection
       limit has been reached and the client is refused a connection.

       The wildcarding in host identifiers means that once pmcd  actually  accepts  a  connection
       from  a client, the connection may contribute to the current connection count of more than
       one access control statement (the client's host may match more  than  one  access  control
       statement).  This may be significant for subsequent connection requests.

       Note  that  because  most  specific  match semantics are used when checking the connection
       limit, priority is given to clients with more  specific  host  identifiers.   It  is  also
       possible to exceed connection limits in some situations.  Consider the following:

              allow clank : all, maximum 5 connections;
              allow * : all except store, maximum 2 connections;

       This  says that only 2 client connections at a time are permitted for all hosts other than
       "clank", which is permitted 5.  If a client from host "boing" is the first to  connect  to
       pmcd,  its  connection  is checked against the second statement (that is the most specific
       match with a connection limit).  As there are no other clients, the connection is accepted
       and contributes towards the limit for only the second statement above.  If the next client
       connects from "clank",  its  connection  is  checked  against  the  limit  for  the  first
       statement.   There  are  no other connections from "clank", so the connection is accepted.
       Once this connection is accepted,  it  counts  towards  both  statements'  limits  because
       "clank"  matches  the  host  identifier in both statements.  Remember that the decision to
       accept a new connection is made using only  the  most  specific  matching  access  control
       statement with a connection limit.  Now, the connection limit for the second statement has
       been reached.  Any connections from hosts other than "clank" will be refused.

       If instead, pmcd with no clients saw three successive connections  arrived  from  "boing",
       the  first  two  would be accepted and the third refused.  After that, if a connection was
       requested from "clank" it would be accepted.  It matches the  first  statement,  which  is
       more  specific  than the second, so the connection limit in the first is used to determine
       that the client has the right to connect.  Now there are 3 connections contributing to the
       second  statement's  connection  limit.   Even  though the connection limit for the second
       statement has been exceeded, the earlier connections from  "boing"  are  maintained.   The
       connection  limit  is  only checked at the time a client attempts a connection rather than
       being re-evaluated every time a new client connects to pmcd.

       This gentle scheme is designed to allow reasonable limits to be imposed on  a  first  come
       first served basis, with specific exceptions.

       As  illustrated  by  the  example above, a client's connection is honored once it has been
       accepted.  However, pmcd reconfiguration (see  the  next  section)  re-evaluates  all  the
       connection  counts and will cause client connections to be dropped where connection limits
       have been exceeded.

RECONFIGURING PMCD

       If the configuration file has been changed or if an agent is not responding because it has
       terminated  or the PMNS has been changed, pmcd may be reconfigured by sending it a SIGHUP,
       as in

            # pmsignal -a -s HUP pmcd

       When pmcd receives a SIGHUP, it checks the configuration file for changes.   If  the  file
       has been modified, it is reparsed and the contents become the new configuration.  If there
       are errors in the configuration file, the  existing  configuration  is  retained  and  the
       contents of the file are ignored.  Errors are reported in the pmcd log file.

       It  also  checks the PMNS file for changes. If the PMNS file has been modified, then it is
       reloaded.  Use of tail(1) on the log file is recommended while reconfiguring pmcd.

       If the configuration for an agent has changed (any parameter except the agent's  label  is
       different),  the  agent  is  restarted.  Agents whose configurations do not change are not
       restarted.  Any existing agents not present in the new configuration are terminated.   Any
       deceased agents are that are still listed are restarted.

       Sometimes  it  is necessary to restart an agent that is still running, but malfunctioning.
       Simply stop the agent (e.g. using SIGTERM from pmsignal(1)),  then  send  pmcd  a  SIGHUP,
       which will cause the agent to be restarted.

STARTING AND STOPPING PMCD

       Normally,  pmcd is started automatically at boot time and stopped when the system is being
       brought down (see rc2(1M) and rc0(1M)).  Under certain circumstances it  is  necessary  to
       start or stop pmcd manually.  To do this one must become superuser and type

            # $PCP_RC_DIR/pcp start

       to start pmcd, or

            # $PCP_RC_DIR/pcp stop

       to  stop  pmcd.   Starting  pmcd when it is already running is the same as stopping it and
       then starting it again.

       Sometimes it may be necessary to restart pmcd during another phase of  the  boot  process.
       Time-consuming  parts  of  the boot process are often put into the background to allow the
       system to become available sooner (e.g. mounting huge databases).  If an agent run by pmcd
       requires such a task to complete before it can run properly, it is necessary to restart or
       reconfigure pmcd after the task completes.  Consider, for example, the case of mounting  a
       database  in  the  background while booting.  If the PMDA which provides the metrics about
       the database cannot function until the database is  mounted  and  available  but  pmcd  is
       started  before the database is ready, the PMDA will fail (however pmcd will still service
       requests for metrics from other domains).  If the database is  initialized  by  running  a
       shell  script, adding a line to the end of the script to reconfigure pmcd (by sending it a
       SIGHUP) will restart the PMDA (if it exited because it couldn't connect to the  database).
       If  the PMDA didn't exit in such a situation it would be necessary to restart pmcd because
       if the PMDA was still running pmcd would not restart it.

       Normally pmcd listens for client connections on one or more well-known TCP/IP port numbers
       (historically  4321 and more recently the officially registered port 44321; in the current
       release, pmcd listens on only port 44321 by default).   Either  the  environment  variable
       PMCD_PORT  or the -p command line option may be used to specify alternative port number(s)
       when pmcd is started; in each case, the specficiation is a comma-separated list of one  or
       more numerical port numbers.  Should both methods be used or multiple -p options appear on
       the command line, pmcd will listen on the union of the set of ports specified via  all  -p
       options  and  the PMCD_PORT environment variable.  If non-default ports are used with pmcd
       care should be taken to ensure that PMCD_PORT is also set in the environment of any client
       application that will connect to pmcd.

FILES

       $PCP_PMCDCONF_PATH
                 default configuration file
       $PCP_PMCDOPTIONS_PATH
                 command  line options to pmcd when launched from $PCP_RC_DIR/pcp All the command
                 line option lines should start with a hyphen as the first character.  This  file
                 can also contain environment variable settings of the form "VARIABLE=value".
       ./pmcd.log
                 (or $PCP_LOG_DIR/pmcd/pmcd.log when started automatically)
       $PCP_RUN_DIR/pmcd.pid
                 contains  an  ascii decimal representation of the process ID of pmcd , when it's
                 running.
                 All messages and diagnostics are directed here

ENVIRONMENT

       In addition to the PCP environment variables described  in  the  PCP  ENVIRONMENT  section
       below,  the  PMCD_PORT  variable  is  also  recognised  as  the  TCP/IP  port for incoming
       connections (default 44321).

PCP ENVIRONMENT

       Environment variables with the prefix PCP_ are used to parameterize the file and directory
       names used by PCP.  On each installation, the file /etc/pcp.conf contains the local values
       for these variables.  The $PCP_CONF  variable  may  be  used  to  specify  an  alternative
       configuration file, as described in pcp.conf(4).

SEE ALSO

       PCPIntro(1),  pmdbg(1), pmerr(1), pmgenmap(1), pminfo(1), pmstat(1), pmstore(1), pmval(1),
       pcp.conf(4), and pcp.env(4).

DIAGNOSTICS

       If pmcd is already running the message "Error: OpenRequestSocket bind: Address may already
       be  in  use"  will  appear.  This may also appear if pmcd was shutdown with an outstanding
       request from a client.  In this case, a request socket has  been  left  in  the  TIME_WAIT
       state  and  until  the  system  closes  it down (after some timeout period) it will not be
       possible to run pmcd.

       In addition to the standard  PCP  debugging  flags,  see  pmdbg(1),  pmcd  currently  uses
       DBG_TRACE_APPL0  for  tracing  I/O  and termination of agents, DBG_TRACE_APPL1 for tracing
       host access control (see below) and DBG_TRACE_APPL2 for  tracing  the  configuration  file
       scanner and parser.

CAVEATS

       pmcd  does not explicitly terminate its children (agents), it only closes their pipes.  If
       an agent never checks for a closed pipe it may not terminate.

       The configuration file parser will only read lines of less than 1200 characters.  This  is
       intended to prevent accidents with binary files.

       The  timeouts  controlled  by  the  -t  option  apply to IPC between pmcd and the PMDAs it
       spawns.  This is independent of settings of the environment variables PMCD_CONNECT_TIMEOUT
       and  PMCD_REQUEST_TIMEOUT  (see  PCPIntro(1))  which  may  be used respectively to control
       timeouts for client  applications  trying  to  connect  to  pmcd  and  trying  to  receive
       information from pmcd.