# pmda

## NAME



           **PMDA** - introduction to the Performance Metrics Domain Agent
           support library
    


## C SYNOPSIS



           **#include <pcp/pmapi.h>**
           **#include <pcp/pmda.h>**
    
            ... assorted routines ...
    
           **cc ... -lpcp_pmda -lpcp**
    


## DESCRIPTION



           To  assist  in the development of Performance Metric Domain Agents
           (**PMDA** s) for the Performance Co-Pilot (PCP), a procedural interface
           is provided that extends the Performance Metrics Application  Pro‐
           gramming  Interface  (PMAPI(3)) library.  These procedures are de‐
           signed to enable a programmer to quickly build a  PMDA  which  can
           then be tested and refined.  However, this also implies that a PM‐
           DA  has  a  particular structure which may not be suitable for all
           PMDA implementations.
    
           Once you are familiar with the PCP and PMDA  frameworks,  you  can
           quickly  implement  a new PMDA with only a few data structures and
           functions.  This is covered in far greater detail in  the  _Perfor‐_
           _mance Co-Pilot Programmer's Guide_.
    
           A  PMDA  is  responsible  for a set of performance metrics, in the
           sense that it must respond to requests from pmcd(1)  for  informa‐
           tion about performance metrics, instance domains, and instantiated
           values.
    
           This man page contains sections of the **simple PMDA** which is locat‐
           ed at _$PCP_PMDAS_DIR_ /simple.
    


## COMMUNICATING WITH PMCD



           Two  approaches  may  be  used  for connecting a PMDA to a pmcd(1)
           process.  A Dynamic Shared Object (DSO) can be attached by pmcd(1)
           using dlopen(3) when the pmcd(1) process is started.  A procedural
           interface referenced through a shared data structure  is  used  to
           handle requests from pmcd(1) to the PMDA .
    
           The  preferred approach is for a separate process (daemon) to com‐
           municate with pmcd(1) using the Performance Data Units  (PDU)  In‐
           ter-Process Communication (IPC) protocol.
    
           All  PMDAs  are  launched and controlled by the pmcd(1) process on
           the local host.  The requests from the  clients  are  received  by
           pmcd(1)  and  forwarded to the appropriate PMDAs.  Responses, when
           required, are returned through pmcd(1) to the  clients.   The  re‐
           quests  (PDUs)  that  may  be  sent  to  a  PMDA  from pmcd(1) are
           **PDU_FETCH** ,    **PDU_PROFILE** ,     **PDU_INSTANCE_REQ** ,     **PDU_DESC_REQ** ,
           **PDU_TEXT_REQ** and  **PDU_RESULT**.  If the PMDA implements any dynamic
           metrics  it  may  also   receive   **PDU_PMNS_CHILD** ,   **PDU_PMNS_IDS** ,
           **PDU_PMNS_NAMES** and **PDU_PMNS_TRAVERSE** PDUs.
    


## DEFAULT CALLBACKS FOR HANDLING PDUs



           To allow a consistent framework, pmdaMain(3) can be used by a dae‐
           mon PMDA to handle the communication protocol using the same call‐
           backs  as a DSO PMDA.  The structure **pmdaInterface** is used to con‐
           vey the common procedural interface and state information that  is
           used  by  pmcd(1) and a PMDA.  This state information includes ta‐
           bles describing the supported metrics and instance domains.
    
           As most of the procedural interface is identical  for  all  PMDAs,
           they are provided as part of this support library (pmdaProfile(3),
           pmdaFetch(3),   pmdaInstance(3),   pmdaDesc(3),   pmdaText(3)  and
           pmdaStore(3)).  However, these routines require access to the  **pm‐**
           **daInterface** state information so it must be correctly initialized
           using pmdaConnect(3), pmdaDaemon(3),  pmdaOpenLog(3),  pmdaDSO(3),
           pmdaGetOpt(3) and pmdaInit(3).
    


## INSTANCES AND INSTANCE DOMAINS



           Three  structures  are  declared  in _/usr/include/pcp/pmda.h_ which
           provide a framework for declaring the metrics and  instances  sup‐
           ported by the PMDA.
    
           Every  instance  requires a unique integer identifier and a unique
           name, as defined by the structure **pmdaInstid** :
    
                /*
                 * Instance description: index and name
                 */
    
                typedef struct {
                    int         i_inst;        /* internal instance identifier */
                    char        *i_name;       /* external instance identifier */
                } pmdaInstid;
    
           An instance domain requires its own unique  identification  (**pmIn‐**
           **Dom**), the number of instances the domain represents, and a pointer
           to  an  array  of  instance  descriptions.  This is defined in the
           structure **pmdaIndom** :
    
                /*
                 * Instance domain description: unique instance id,
                 * number of instances in this domain, and the list of
                 * instances (not null terminated).
                 */
    
                typedef struct {
                    pmInDom     it_indom;       /* indom, filled in */
                    int         it_numinst;     /* number of instances */
                    pmdaInstid  *it_set;        /* instance identifiers */
                } pmdaIndom;
    
           The **simple PMDA** has one  instance  domain  for  _simple_._color_  with
           three  instances  (_red_ , _green_ and _blue_), and a second instance do‐
           main for _simple_._now_ with instances which can be specified at  run-
           time.  These instance domains are defined as:
    
                static pmdaInstid _color[] = {
                    { 0, "red" }, { 1, "green" }, { 2, "blue" }
                };
                static pmdaInstid *_timenow = NULL;
    
                static pmdaIndom indomtab[] = {
                #define COLOR_INDOM 0
                    { COLOR_INDOM, 3, _color },
                #define NOW_INDOM 1
                    { NOW_INDOM, 0, NULL },
                };
    
           The  preprocessor macros **COLOR_INDOM** and **NOW_INDOM** are used in the
           metric description table to identify the instance domains of indi‐
           vidual metrics.  These correspond to the _serial_ value in  the  in‐
           stance  domain  **pmInDom** structure  (the  _domain_  field  is set by
           pmdaInit(3) at run-time).  The serial value  must  be  unique  for
           each instance domain within the PMDA.
    
           The indom table shown above which is usually passed to pmdaInit(3)
           does  not need to be created if one wants to write one's own Fetch
           and Instance functions.  See pmdaInit(3) for more details.
    


## NAMESPACE



           Every PMDA has its own unique **namespace** using the  format  defined
           in  PMNS(5).   In  summary, the namespace matches the names of the
           metrics to the unique identifier.  The **simple  PMDA** defines  five
           metrics:  _simple_._numfetch_ ,  _simple_._color_ ,  _simple_._time_._user,_  _sim‐_
           _ple_._time_._sys_ and _simple_._now_.  The namespace for these  metrics  is
           defined in _$PCP_PMDAS_DIR_ /simple/pmns and is installed as:
    
                simple {
                    numfetch    253:0:0
                    color       253:0:1
                    time
                    now         253:2:4
                }
    
                simple.time {
                    user        253:1:2
                    sys         253:1:3
                }
    
           The  domain number of _253_ is obtained from _$PCP_VAR_DIR_ /pmns/stdp‐
           mid.  New PMDAs should specify a  unique  domain  number  in  this
           file,  and obtain the number during installation.  This allows the
           domain   number   to   change   by   modifying   only   the   file
           _$PCP_VAR_DIR_ /pmns/stdpmid.
    
           The  _simple.time_  and  _simple.now_  metrics are defined in separate
           clusters to the other metrics which allows a PMDA to support  more
           than  1024  metrics, as well as grouping similar metrics together.
           Therefore, the item numbers for a new cluster may be identical  to
           the  item numbers in other clusters.  The **simple PMDA** continues to
           increment  the  item  numbers  to  permit  direct   mapping   (see
           pmdaInit(3)).
    
           The  namespace file should be installed and removed with the agent
           using pmnsadd(1) and pmnsdel(1).  See the later  sections  on  IN‐
           STALLATION and REMOVAL.
    
           A  simple  ASCII  namespace  can be constructed by creating a file
           similar to _$PCP_PMDAS_DIR_ /simple/root:
    
                /*
                 * fake "root" for validating the local PMNS subtree
                 */
    
                #include "$PCP_VAR_DIR/pmns/stdpmid"
    
                root { simple }
    
                #include "pmns"
    
           and can be referred to with the **-n** option in most PCP tools.
    


## METRIC DESCRIPTIONS



           Each metric requires a description (**pmDesc**),  which  contains  its
           Performance Metric Identifier (PMID), data type specification, in‐
           stance  domain, semantics and units (see pmLookupDesc(3)).  A han‐
           dle is also provided for application specific information  in  the
           **pmdaMetric** structure:
    
                /*
                 * Metric description: handle for extending description,
                 * and the description.
                 */
    
                typedef struct {
                    void*       m_user;         /* for users external use */
                    pmDesc      m_desc;         /* metric description */
                } pmdaMetric;
    
           The **simple PMDA** defines the metrics as:
    
                static pmdaMetric metrictab[] = {
                /* numfetch */
                    { (void *)0,
                      { PMDA_PMID(0,0), PM_TYPE_U32, PM_INDOM_NULL, PM_SEM_INSTANT,
                        { 0,0,0,0,0,0} }, },
                /* color */
                    { (void *)0,
                      { PMDA_PMID(0,1), PM_TYPE_32, COLOR_INDOM, PM_SEM_INSTANT,
                        { 0,0,0,0,0,0} }, },
                /* time.user */
                    { (void*)0,
                      { PMDA_PMID(1,2), PM_TYPE_DOUBLE, PM_INDOM_NULL, PM_SEM_COUNTER,
                           { 0, 1, 0, 0, PM_TIME_SEC, 0 } }, },
                /* time.sys */
                    { (void*)0,
                      { PMDA_PMID(1,3), PM_TYPE_DOUBLE, PM_INDOM_NULL, PM_SEM_COUNTER,
                           { 0, 1, 0, 0, PM_TIME_SEC, 0 } }, },
                /* now */
                    { NULL,
                      { PMDA_PMID(2,4), PM_TYPE_U32, NOW_INDOM, PM_SEM_INSTANT,
                        { 0,0,0,0,0,0 } }, },
                };
    
           The  macro  **PMDA_PMID**(defined in _/usr/include/pcp/pmda.h_) is used
           to specify each metric's _cluster_ and _item_ fields of the associated
           **pmID**.  As with instance  domains,  the  _domain_  field  is  set  by
           pmdaInit(3) at run-time, however, the default domain is assumed to
           be defined by the PMDA in the macro **MYDOMAIN**.
    
           The   metric   table  shown  above  which  is  usually  passed  to
           pmdaInit(3) does not need to be created  if  one  wants  to  write
           one's  own  Fetch  and  Descriptor functions.  See pmdaInit(3) for
           more details.
    


## DSO PMDA



           A PMDA that is run as a DSO is opened by pmcd(1)  with  dlopen(3).
           pmcd(1) will call the PMDA's initialization function that is spec‐
           ified in _$PCP_PMCDCONF_PATH_.  This function is passed a pointer to
           a  **pmdaInterface** structure which must be completed.  Any callbacks
           which are _not_ the default PMDA support library callbacks  must  be
           specified in the **pmdaInterface** structure.
    
           The  **simple  PMDA** uses  its  own  store and fetch callback.  **sim‐**
           **ple_fetch**() calls pmdaFetch(3) which requires a callback to be set
           with pmdaSetFetchCallBack(3) as can be seen in _$PCP_PMDAS_DIR_ /sim‐
           ple/simple.c.
    
           The flag **_isDSO** is used to determine if the PMDA is a daemon or  a
           DSO  so  that the correct initialization routine, pmdaDaemon(3) or
           pmdaDSO(3), is called.
    


## DAEMON PMDA



           A PMDA that is run as a daemon is forked and executed by  pmcd(1).
           Therefore, unlike a DSO PMDA, the starting point for a daemon PMDA
           is  **main**().   The  agent  should parse the command line arguments,
           create a log file and initialize some data structures that pmcd(1)
           would initialize for a DSO agent.
    
           The **pmdaInterface** structure must be completely defined by the dae‐
           mon PMDA.  The function pmdaDaemon(3) can be called at  the  start
           of  **main**()  to set most of these fields.  Command line parsing can
           be  simplified  by  using  pmdaGetOpt(3),  which  is  similar   to
           **getopt**(2),  but  extracts a common set of options into the **pmdaIn‐**
           **terface** structure.  _stderr_ can be  mapped  to  a  log  file  using
           pmdaOpenLog(3) to simplify debugging and error messages.  The con‐
           nection  to  pmcd(1)  can be made with pmdaConnect(3) and the loop
           which handles the incoming PDUs, pmdaMain(3), should be  the  last
           function  called.   This can be seen in _$PCP_PMDAS_DIR_ /simple/sim‐
           ple.c.
    
           The **simple_init**() routine is common to an agent that can be run as
           both a Daemon and DSO PMDA.
    


## HELP TEXT



           Each PMDA must be able to provide pmcd(1) with the help  text  for
           each  metric.  Most PMDAs use specially created files with indexes
           to support efficient retrieval of the help text.  Tools  are  pro‐
           vided  with  PCP to create the help text files of appropriate for‐
           mat. See newhelp(1).
    


## INSTALLATION AND REMOVAL



           A series of shell procedures are defined in _$PCP_SHARE_DIR_ /lib/pm‐
           daproc.sh which greatly simplify the installation and removal of a
           PMDA.
    
           The _Install_ scripts for most PMDAs should only need to specify the
           name of the PMDA in **iam** , call **pmdaSetup** which sets up some default
           variables, checks permissions (you have to be ``root'' to  install
           or  remove  a  PMDA),  checks  that  you're in the right directory
           (somewhere that ends with /pmdas/_$iam_),  optionally  generate  the
           Performance Metrics Name Space (PMNS) and PMDA domain number files
           for  Perl or Python PMDAs, checks the PMDA domain number is valid,
           etc., specify the communication protocols, and  finally  call  **pm‐**
           **daInstall** to  do  all the work of updating the PMNS, updating the
           pmcd(1) control file, notifying or restarting pmcd(1),
    
           Beyond **pmdaSetup** and **pmdaInstall** , another optional helper routines
           is **pmdaChooseConfigFile** that may be used to  interactively  select
           or create a PMDA-specific configuration file, e.g. pmdalogger(1).
    
           The  _Remove_  scripts are even simpler as setting up the communica‐
           tion protocols are not required, so set the name of  the  PMDA  in
           _iam_ , then call **pmdaSetup** followed by a call to **pmdaRemove**.
    
           Further  information  is  contained  in the _$PCP_SHARE_DIR_ /lib/pm‐
           daproc.sh file and the following section.
    
           Optionally, a PMDA may provide an _Upgrade_ script alongside _Install_
           and _Remove_.  If present this script  will  be  used  by  the  **pmcd**
           startup process to ensure corrections to an installation have been
           made  before  starting the PMDA.  Examples of such corrections in‐
           clude: updates to _pmcd.conf_ when a PMDA script or binary has  been
           renamed,  when the PMDA supports a new format of its configuration
           file, or if there is some latent problem from an  earlier  install
           (e.g. some PMDAs may need to introduce use of the **notready** keyword
           in _pmcd.conf_ , as described below).
    


## INSTALLATION REFINEMENTS



           As  outlined below there are a number of variables that can be set
           in a PMDA's _Install_ script to influence the behaviour of  the  in‐
           stallation  procedures.   These would typically need to be set be‐
           fore the call to **pmdaInstall** , but in some instances (like _$iam_ and
           the cases specifically noted below), before the call to **pmdaSetup**.
    
           The following variables control the communication options  between
           the  PMDA  and  pmcd(1).   At  least one of _$daemon_opt_ , _$dso_opt_ ,
           _$perl_opt_ or _$python_opt_ must  be  set  to  define  the  supported
           mode(s)  of  communication.   If more than one of these is set the
           user will be prompted to make a selection when the _Install_  script
           is run.
    
           _daemon_opt_
                  We are willing to install the PMDA as a daemon.
                  Default: true
    
           _dso_opt_
                  We are willing to install the PMDA as a DSO, so pmcd(1)
                  will use the dynamic linking loader to attach the PMDA's
                  DSO at run-time and communication from pmcd(1) to the PMDA
                  and back uses procedure calls, not an IPC channel.
                  Default: false
    
           _dso_entry_
                  For a DSO PMDA, this is the name of the PMDA's initializa‐
                  tion routine.
                  Default: _${iam}_ _init
    
           _dso_name_
                  For a DSO PMDA, this is the full pathanme of the PMDA's DSO
                  file.
                  Default: _$PCP_PMDAS_DIR_ /_$iam_ /pmda__$iam_._$dso_suffix_
    
           _pipe_opt_
                  For a daemon PMDA, is the default IPC channel via a
                  pipe(2)?
                  Default: Platform-specific, so **true** for most, but **false** for
                  Windows
    
           _perl_opt_
                  We are willing to install the PMDA as a Perl script and
                  pmcd(1) will use the **perl**(1) interpreter to run the PMDA.
                  Default: false
    
           _pmda_dir_
                  Full pathname to the directory where the PMDA's installa‐
                  tion files (executable, script, PMNS source, help text
                  source, etc) are to be found.
                  Default: output from pwd(1)
    
                           If set, must be done before the call to **pmdaSetup**.
    
           _pmda_name_
                  For a daemon PMDA, this is the name of the PMDA's exe‐
                  cutable binary relative to the _$pmda_dir_ directory.
                  Default: pmda _$iam_
    
           _python_opt_
                  We are willing to install the PMDA as a Python script and
                  pmcd(1) will use the **python**(1) interpreter to run the PMDA.
                  Default: false
    
           _ipc_prot_
                  For a daemon PMDA, this can be set to either **binary** or
                  **text**.  The default is **binary** and **text** is rarely used.  In
                  addition, an optional IPC parameter **notready** can be used to
                  signify that the PMDA will start up in the **notready** state,
                  e.g. **ipc_prot="binary notready"**.  Note that the quotes are
                  required.  The IPC parameters for a PMDA appear in **pm‐**
                  **cd.conf** in the **IPC Params** column.  For further details, see
                  pmcd(1) but basically **pmcd** will not issue any requests to a
                  PMDA that has started in the **notready** state until the PMDA
                  sends a **PM_ERR_PMDAREADY** PDU.  This allows PMDAs with long
                  startup times to initialize correctly without timing out.
                  For details, see pmdaSendError(3) and pmcd(1).  When a PMDA
                  is in the **notready** state, any client requests sent to **pmcd**
                  for the PMDA domain will return with the **PM_ERR_PMDAN‐**
                  **OTREADY** error.
    
           _socket_inet_def_
                  For a daemon PMDA using a socket(2) as the IPC channel the
                  default Internet port number or service name (if known).
                  Default: ""
    
           _socket_opt_
                  For a daemon PMDA, is the default IPC channel via a
                  socket(2)?
                  Default: Platform-specific, so **false** for most, but **true** for
                  Windows
    
           The following variables control the PMNS options.
    
           _pmns_dupok_
                  Most PMDAs do not have duplicate names for the same PMID in
                  their PMNS.  But if this is not the case, _pmns_dupok_ should
                  be set to **true**.
                  Default: false
    
           _pmns_name_
                  Each PMDA will add one or more non-leaf nodes to the top of
                  the PMNS.  The most common case is that all of the metrics
                  for a PMDA will be placed below the node named _$iam_.  If
                  this is not the case, and especially when the PMDA adds
                  more than one non-leaf node at the top of the PMNS,
                  _pmns_name_ needs to be set to the list of node names (sepa‐
                  rated by white space), e.g. for pmdaproc(1) _pmns_name_ is
                  set to "proc cgroup hotproc".
                  Default: _$iam_
    
                           It is most important that if _pmns_name_ is set to a
                           non-default value in the _Install_ script then it
                           must also be set to the same value in the _Remove_
                           script.
    
           _pmns_source_
                  The name of the PMDA's PMNS source file.  By default, the
                  name is interpreted as a relative pathname from the _$pm‐_
                  _da_dir_ directory.
                  Default: pmns
    
           The following variables provide assorted additional options asso‐
           ciated with the installation of a PMDA.
    
           _args_   Additional command line args for the PMDA.  These will be
                  appended to the PMDA's control line in _$PCP_PMCDCONF_PATH_.
                  Default: ""
    
           _check_delay_
                  Delay (in seconds) after finishing the PMDA installation
                  (or removal) before checking the availability of metrics
                  from the PMDA.  May need to be increased if the PMDA has a
                  lengthy startup procedure.
                  Default: 0.3
    
           _signal_delay_
                  Delay (in seconds) after notifying pmcd(1) with a signal.
                  Required to allow pmcd(1) to complete processing before
                  proceeding to the next step of the installation (or re‐
                  moval).
                  Default: 1
    
           _configdir_
                  Determines the directory in which a PMDA's configuration
                  file will be stored.  Used by **pmdaChooseConfigFile** so
                  should be set before calling that procedure.
                  Default: _$PCP_VAR_DIR_ /config/_$iam_
    
           _configfile_
                  Preferred configuration file for the PMDA.  Used by **pmda‐**
                  **ChooseConfigFile** so should be set before calling that pro‐
                  cedure.
                  Default: ""
    
           _default_configfile_
                  Default configuration file for the PMDA.  Used by **pmda‐**
                  **ChooseConfigFile** so should be set before calling that pro‐
                  cedure.
                  Default: ""
    
           _dso_suffix_
                  Standard suffix for a DSO.  Should not need to be changed
                  under normal circumstances.
                  Default: Platform-specific, so 'so' for Linux, 'dylib' for
                  Mac OS X, 'dll' for Windows, etc.
    
                           If set, must be done before the call to **pmdaSetup**.
    
           _help_source_
                  The name of the help text source file that should be used
                  as input to **pmnewhelp**(1).  By default, the name is inter‐
                  preted as a relative pathname from the _$pmda_dir_ directory.
                  Default: help
    
           _python_name_
                  Full pathname of the Python script for a Python PMDA.
                  Default: _$pmda_dir_ /pmda _$iam_.python or _$pmda_dir_ /pmda _$iam_.py
    
           The shell procedures in _$PCP_SHARE_DIR_ /lib/pmdaproc.sh manipulate
           a number of temporary files using the variable _$tmp_ as the prefix
           for the name of the temporary files.  _$tmp_ is a directory that is
           created, used and removed internally within the procedures of
           _$PCP_SHARE_DIR_ /lib/pmdaproc.sh but can also be used as the prefix
           for temporary files needed by a PMDA's _Install_ or _Remove_ scripts.
           When used in this way, _$tmp_ should be followed by a ``/'' and then
           a suffix, e.g. _$tmp_ /myfoo.  The _Install_ and _Remove_ scripts should
           not use other temporary file name prefixes nor use **sh**(1) **trap**
           statements to clean up temporary files as this is all done within
           _$PCP_SHARE_DIR_ /lib/pmdaproc.sh.
    


## CAVEAT



           Failing to complete any of the data structures or calling any of
           the library routines out of order may cause unexpected behavior in
           the PMDA.
    
           Due to changes to the PMAPI(3) and PMDA(3) API in the PCP 2.0 re‐
           lease, as described in the product release notes, PMDAs built us‐
           ing PCP 2.0 must specify **PMDA_INTERFACE_2** or later and link with
           _libpcp_pmda.so.2_ and _libpcp.so.2_.  Pre-existing Daemon PMDAs spec‐
           ifying **PMDA_INTERFACE_1** will continue to function using the back‐
           wards compatible _libpcp_pmda.so.1_ and _libpcp.so.1_ libraries and
           may be recompiled using the headers installed in _/usr/in‐_
           _clude/pcp1.x/_ without any modification.  These backwards compati‐
           ble headers and libraries are contained in the _pcp.sw.compat_ sub‐
           system.
    


## DIAGNOSTICS



           Any PMDA which uses this library can set PMAPI(3) debugging con‐
           trol option **libpmda**(with **-Dlibpmda** on the command line or via
           **3** pmSetDebug**(3))** to to enable the display of debugging information
           which may be useful during development (see pmdbg(1)).
    
           The _status_ field of the **pmdaInterface** structure should be zero af‐
           ter **pmdaDaemon** , **pmdaDSO** , **pmdaGetOpt** , **pmdaConnect** and **pmdaInit** are
           called.  A value less than zero indicates that initialization has
           failed.
    
           Some error messages that are common to most functions in this li‐
           brary are:
    
           **PMDA interface version** _interface_ **not supported**
                  Most of the functions require that the _comm.version_ field
                  of the **pmdaInterface** structure be set to **PMDA_INTERFACE_2**
                  or later.  **PMDA_INTERFACE_2** or **PMDA_INTERFACE_3** implies
                  that the _version.two_ fields are correctly initialized,
                  while **PMDA_INTERFACE_4** implies that the _version.four_ fields
                  are correctly initialized (see pmdaDaemon(3) and
                  pmdaDSO(3)).
    


## FILES



           _/usr/include/pcp/pmda.h_
                  Header file for the PMDA support library.
    
           _/usr/lib/libpcp_pmda.so_
                  Dynamic library containing PMDA support library routines.
    
           _$PCP_PMDAS_DIR_ /trivial
                  The source of the **trivial PMDA**.
    
           _$PCP_PMDAS_DIR_ /simple
                  The source of the **simple PMDA**.
    
           _$PCP_PMDAS_DIR_ /txmon
                  The source of the **txmon PMDA**.
    
           _$PCP_PMCDCONF_PATH_
                  Configuration file for pmcd(1).
    
           _$PCP_VAR_DIR_ /pmns
                  Location of namespace descriptions for every PMDA.
    
           _$PCP_VAR_DIR_ /pmns/stdpmid
                  The unique domain identifiers for each PMDA.
    
           _$PCP_SHARE_DIR_ /lib/pmdaproc.sh
                  Shell procedures for installing and removing a PMDA.
    


## PCP ENVIRONMENT



           Environment variables with the prefix **PCP_** are used to parameter‐
           ize the file and directory names used by PCP.  On each installa‐
           tion, the file _/etc/pcp.conf_ contains the local values for these
           variables.  The _$PCP_CONF_ variable may be used to specify an al‐
           ternative configuration file, as described in pcp.conf(5).  Values
           for these variables may be obtained programmatically using the
           pmGetConfig(3) function.
    


* * *