Provided by: libpcp3-dev_5.3.6-1build1_amd64 bug

NAME

       pmRecordSetup, pmRecordAddHost, pmRecordControl - record mode support for PMAPI clients

C SYNOPSIS

       #include <pcp/pmafm.h>

       FILE *pmRecordSetup(const char *folio, const char *creator, int replay);
       int pmRecordAddHost(const char *host, int isdefault, pmRecordHost **rhp);
       int pmRecordControl(pmRecordHost *rhp, int request, const char *options);

       cc ... -lpcp_gui

DESCRIPTION

       These  routines  may  be  used  to  create a Performance Co-Pilot (PCP) archive ``on the fly'' to support
       ``record mode'' services for PMAPI client applications.

       Each record mode ``session'' involves one or more  PCP  archive  logs  each  created  using  a  dedicated
       pmlogger(1)  process, with an overall Archive Folio format as understood by pmafm(1), to name and collect
       all of the archive logs associated with a single recording session.

       The pmRecordHost structure is used to maintain state information between the  creator  of  the  recording
       session and the associated pmlogger process(es).  The structure is defined as:
         typedef struct {
             FILE   *f_config;    /* caller writes pmlogger configuration here */
             int    fd_ipc;       /* IPC channel to pmlogger */
             char   *logfile;     /* full pathname for pmlogger error logfile */
             pid_t  pid;          /* process id for pmlogger */
             int    status;       /* exit status, -1 if unknown */
         } pmRecordHost;

       The routines are used in combination to create a recording session as follows.

       1.  Call  pmRecordSetup  to establish a new recording session.  A new Archive Folio will be created using
           the name folio; if the file or directory folio already exists, or the file folio cannot  be  created,
           this  is an error.  The application that is creating the session is identified by creator (most often
           this would be the same as the global PMAPI application name, as returned  by  pmGetProgname(3)).   If
           the  application  knows how to create its own configuration file to replay the recorded session, then
           replay should be non-zero.

           pmRecordSetup returns a stdio stream onto which the application should write the text of the required
           replay configuration file, if any.

       2.  For  each  host  that  is  to  be  included  in  the  recording session, call pmRecordAddHost.  A new
           pmRecordHost structure is returned via rhp.  It is assumed that pmcd(1) is running on host as this is
           how pmlogger(1) will retrieve the required performance metrics.

           If this host is the default host for this recording session, then isdefault should be non-zero.  This
           will ensure that the corresponding archive appears first in the PCP  archive  folio,  and  hence  the
           tools  used to replay the archive folio will make the correct determination of the archive associated
           with the default host.  At most one host per recording session may be nominated as the default host.

           The calling application should write  the  desired  pmlogger  configuration  onto  the  stdio  stream
           returned via the f_config field in the pmRecordHost structure.

       3.  Optionally  add  arguments  to  the  command  line that will be used to launch pmlogger(1) by calling
           pmRecordControl with a request of PM_REC_SETARG.  The argument is passed via options and one call  to
           pmRecordControl is required for each distinct argument.

           An argument may be added for a particular pmlogger instance identified by rhp, or if the rhp argument
           is NULL the argument is added for all pmlogger  instances  that  will  be  launched  in  the  current
           recording session.

           Independent  of  any calls to pmRecordControl with a request of PM_REC_SETARG, each pmlogger instance
           will automatically be launched with the following arguments: -c, -h, -l, -x and the basename for  the
           PCP archive log.

       4.  To  commence the recording session, call pmRecordControl with a request of PM_REC_ON, and rhp must be
           NULL.  This will launch one  pmlogger(1)  process  for  each  host  in  the  recording  session,  and
           initialize the fd_ipc, logfile, pid and status fields in the associated pmRecordHost structure(s).

       5.  To  terminate  a  pmlogger  instance  identified  by  rhp,  call  pmRecordControl  with  a request of
           PM_REC_OFF.  If the rhp argument to pmRecordControl is NULL, the termination request is broadcast  to
           all pmlogger processes in the current recording session.

           An  informative  dialog is generated directly by each pmlogger process and hence note the comments on
           the disposition of output from pmlogger below.

           Alternatively, pmlogger can be started with options to limit the duration of logging, e.g. the -T  or
           -s arguments, in which case there is no need to call pmRecordControl with a request of PM_REC_OFF and
           no dialog is generated.

       6.  To display the current status of the pmlogger instance identified by rhp, call pmRecordControl with a
           request  of  PM_REC_STATUS.   If  the  rhp argument to pmRecordControl is NULL, the status request is
           broadcast to all pmlogger processes in the current recording session.

           The display is generated directly by each pmlogger  process  and  hence  note  the  comments  on  the
           disposition of output from pmlogger below.

       7.  To  detach  a  pmlogger  instance  identified  by  rhp  and  allow  it to continue independent of the
           application  that  launched  the  recording  session,  call  pmRecordControl  with   a   request   of
           PM_REC_DETACH.   If  the  rhp argument to pmRecordControl is NULL, the detach request is broadcast to
           all pmlogger processes in the current recording session.

           An informative dialog is generated directly by each pmlogger process and hence note the  comments  on
           the disposition of output from pmlogger below.

       The  calling  application  should  not  close  any  of  the  returned stdio streams; this will be done by
       pmRecordControl when recording is commenced.

       Once pmlogger has been started for a recording session, then pmlogger will assume responsibility for  any
       dialog  with  the user in the event that the application that launched the recording session should exit,
       particularly without terminating the recording session.

       By default, information and dialogs from pmlogger will be displayed using pmquery(1)  on  the  assumption
       that  most  applications  wishing to launch a recording session are GUI-based.  In the event that pmquery
       fails to display the information (for example, because the DISPLAY  environment  variable  is  not  set),
       pmlogger will write on its own stderr stream (not the stderr stream of the launching process); the output
       will be assigned to the XXXXXX.host.log file described in the FILES section below.  For convenience,  the
       full pathname to this file is provided via the logfile field in the pmRecordHost structure.

       If  the  options  argument  to  pmRecordControl  is  not NULL, this string may be used to pass additional
       arguments to pmquery(1) in those cases where a dialog is to be displayed.  One  use  of  this  capability
       would be to provide a -geometry string to control the placement of the dialog.

       Premature  termination of a launched pmlogger process may be determined using the pmRecordHost structure,
       by calling select(2) on the fd_ipc field or polling the status field that will  contain  the  termination
       status from waitpid(2) if known, else -1.

DIAGNOSTICS

       pmRecordSetup  may  return  NULL in the event of an error.  Check errno for the real cause, but the value
       EINVAL typically means that the order of calls to these routines is not correct (there is  obvious  state
       associated  with  the  current recording session that is maintained across calls to these routines).  For
       example the following calls would produce this  EINVAL  error;  calling  pmRecordControl  before  calling
       pmRecordAddHost at least once, or calling pmRecordAddHost before calling pmRecordSetup.

       pmRecordControl  and  pmRecordAddHost  both  return  0  on success, else a value less than 0 suitable for
       decoding with pmErrStr(3) on failure.  The value -EINVAL has the same interpretation as errno  being  set
       to EINVAL as described above.

       pmRecordControl will return PM_ERR_IPC if the associated pmlogger process has already exited.

FILES

       These  routines  create  a  number  of files in the same directory as the folio file named in the call to
       pmRecordSetup.  In all cases, the ``XXXXXX'' component is the result of calling mktemp(3).

       XXXXXX    If replay is non-zero, this is the creator's replay configuration file, else an  empty  control
                 file, used to guarantee uniqueness.
       folio     The PCP Archive Folio, suitable for use with pmafm(1).
       XXXXXX.host.config
                 The  pmlogger(1)  configuration  for each host - if the same host is used in different calls to
                 pmRecordAddHost within the same recording session then one of the letters ``a''  through  ``z''
                 will be appended to the ``XXXXXX'' part of all associated file names to ensure uniqueness.
       XXXXXX.host.log
                 stdout and stderr for the pmlogger(1) instance for each host.
       XXXXXX.host.{0,meta,index}
                 The files comprising a single PCP archive for each host.

SEE ALSO

       pmafm(1), pmlogger(1), pmquery(1) and PMAPI(3).