The name pies (pronounced p-yes) stands for Program Invocation and Execution Supervisor.  This utility starts and controls execution of external programs, called components.  Each component is a stand-alone program, which is executed in the foreground.  Upon startup, pies reads the list of components from its configuration file, starts them, and remains in the background, controlling their execution.  When any of the components terminates, pies restarts it.  Its configuration allows to specify actions other than simple restart, depending on the exit code of the component.

A component A may depend on another components, say B and C, i.e. require them to be running at the moment of its startup.  Components B and C are called prerequisites for A, while A is called a dependency or dependent component of B, C.

Before restarting any component, pies verifies if it is a prerequisite for any other components.  If so, it first terminates its dependencies, then restarts the component, and then starts its dependencies again, in the order of their appearance in the configuration file.

The standard output and standard error streams of a component can be redirected to a file or to an arbitrary syslog channel.

These way of operation applies to so-called init-style components, called so because of the similarity with the init process manager.  Pies is also able to handle components that receive input on their stdin and send reply to stdout.  Such components are called inetd-style components.

Inetd-style components are not executed right after pies startup.  Instead, pies opens a socket for each of them and listens for connections on these sockets.  When a connection arrives, it decides what component the socket corresponds to, and invokes this component to handle that connection.  In this case, the connection is bound to component's stdin and stdout streams.  The stderr stream can be redirected to a file or to syslog, as described above.  This mode of operation is similar to that of inetd utility.

The third type of components, supported by pies are meta1-style components.  As the name suggests this type is designed expressly as a support for MeTA1 components, namely smtps.  This type can be regarded as a mixture of the above two.  For each meta1-style component pies opens a socket after start-up, and then executes the component.  Once the component is running, pies passes it the file descriptor of the socket, using a preconfigured UNIX-style socket.  Further handling of the socket is the responsibility of the component itself.

The last flavor of pies components are accept-style components, which are handled basically as inetd-style ones, except that after binding to the socket pies immediately starts the component, without waiting for an actual connection.

Any number of components of all three styles can be handled simultaneously.

Components are started in the order of their appearance in the configuration file and terminated in the reverse order.  When starting or stopping component dependencies, the same ordering is preserved.

This order is reversed for files included by include-meta1 statement (see include-meta1).

Pies Configuration File
=======================

Pies reads its configuration from the main Mailutils configuration file.  See Mailutils Configuration File (GNU Mailutils Manual), for a description of GNU Mailutils configuration system.  It is recommended to use include DIRECTORY statement (see Include Statement (GNU Mailutils Manual)), and to place pies configuration in file DIRECTORY/pies. See MeTA1, for an example.

The following standard Mailutils configuration statements are understood:

Statement   Reference
debug   see Mailutils Debug Statement (GNU Mailutils Manual).
logging   see Mailutils Logging (GNU Mailutils Manual).
include   see Include Statements (GNU Mailutils Manual).
mailer    see Mailer Statement (GNU Mailutils Manual).
acl       see ACL Statement (GNU Mailutils Manual).

Component Statement
===================

The component statement defines a new component:

     component TAG {
       ...
     }

The component is identified by its tag, which is given as argument to the component keyword.

The following statements are allowed within the component block:

 -- Pies Conf: mode MODE
     Declare the type (style) of the component.  Accepted values for MODE are:

     exec
     wait
          Create an init-style component (see init-style).  This is the default.

     inetd
     nostartaccept
          Create an inetd-style component (see inetd-style).

     pass
     pass-fd
          Create a meta1-style component (see meta1-style).

     accept
          Create a accept-style component (see accept-style).

 -- Pies Conf: program NAME
     Full file name of the component binary.  This binary will be executed (via /bin/sh -c) each time pies decides it needs to start the component.

     To supply command line arguments, use command statement.

 -- Pies Conf: command STRING
     Command line for the program.  The argument should be just as arguments normally are, starting with the name of the program.  The latter may be different from the one specified to program statement.  Its value will be available to the program as argv[0].

 -- Pies Conf: disable BOOL
     If BOOL is true, this component is disabled, i.e. pies will ignore it.

 -- Pies Conf: precious BOOL
     If BOOL is true, this component is marked as precious. Precious components are never disabled by pies, even if they respawn too fast.

Component Prerequisites
-----------------------

Prerequisites (see component prerequisite) for a component are declared using the following statement:

 -- Pies Conf: prerequisites TAG-LIST
     The argument is either a list of component tags, defined before this component, or one of the following words:

     all
          Declare all components defined so far as prerequisites for this one.

     none
          No prerequisites.  This is the default.

If you wish, you can define dependents, instead of prerequisites:

 -- Pies Conf: dependents TAG-LIST
     Declare dependents for this component.  VAR-LIST is a list of component tags.

Component Privileges
--------------------

Following statements control the privileges the component is executed with.

 -- Pies Conf: user USER-NAME
     Start component with the UID and GID of this user.

 -- Pies Conf: group GROUP-LIST
     Retain supplementary groups, specified in GROUP-LIST.

 -- Pies Conf: allgroups BOOL
     Retain all supplementary groups of which the user (as given with user statement) is a member.  This is the default for components specified in meta1.conf file (see include-meta1).

Resources
---------

 -- Pies Conf: limits STRING
     Impose limits on system resources, as defined by STRING.  The argument consists of commands, optionally separated by any amount of whitespace.  A command is a single command letter followed by a number, that specifies the limit.  The command letters are case-insensitive and coincide with those used by the shell ulimit utility:

     Command    The limit it sets
     A          max address space (KB)
     C          max core file size (KB)
     D          max data size (KB)
     F          maximum file size (KB)
     M          max locked-in-memory address space (KB)
     N          max number of open files
     R          max resident set size (KB)
     S          max stack size (KB)
     T          max CPU time (MIN)
     U          max number of processes
     P          process priority -20..20 (negative = high priority)

     For example:

          limits T10 R20 U16 P20

     Additionally, the command letter L is recognized.  It is reserved for future use (number of logins limit) and is ignored in version VERSION.

 -- Pies Conf: umask NUMBER
     Set the umask.  The NUMBER must be an octal value not greater than 777.  The default umask is inherited at startup.

 -- Pies Conf: env ARGS
     Set program environment.

     Arguments are a whitespace-delimited list of specifiers.  The following specifiers are understood:

     - (a dash)
          Clear the environment.  This is understood only when used as a first word in ARGS.

     -NAME
          Unset the environment variable NAME.

     -NAME=VAL
          Unset the environment variable NAME only if its value is VAL.

     NAME
          Retain the environment variable NAME.

     NAME=VALUE
          Define environment variable NAME to have given VALUE.

     NAME+=VALUE
          Retain variable NAME and append VALUE to its existing value.  If no such variable is present in the environment, it is created and VALUE is assigned to it.  However, if VALUE begins with a punctuation character, this character is removed from it before the assignment.  This is convenient for using this construct with environment variables like PATH, e.g.:

               PATH+=:/sbin

          In this example, if PATH exists, :/sbin will be appended to it.  Otherwise, it will be created and /sbin will be assigned to it.

     NAME=+VALUE
          Retain variable NAME and prepend VALUE to its existing value.  If no such variable is present in the environment, it is created and VALUE is assigned to it.  However, if VALUE ends with a punctuation character, this character is removed from it before assignment.

Actions Before Startup
----------------------

Several statements are available that specify actions to perform immediately before starting the component:

 -- Pies Conf: chdir DIR
     Change to the directory DIR.

 -- Pies Conf: remove-file FILE-NAME
     Remove FILE-NAME.  This is useful, for example, to remove stale UNIX sockets or pid-files, which may otherwise prevent the component from starting normally.

     As of version VERSION only one remove-file may be given.

 -- Pies Conf: settle-timeout NUMBER
     Wait NUMBER seconds.  This is kind of kludge.  Currently it is used for components imported from meta1.conf file (see include-meta1), where settle-timeout 1 is implied. This may change in future versions.

Exit Actions
------------

The default behavior of pies if an init-style component terminates is to restart it.  Unless the component terminates with 0 exit code, a corresponding error message is issued to the log file.  This behavior can be modified using return-code statement:

     return-code CODES {
       ...
     }

The CODES argument is a list of exit codes or signal names. Exit codes can be specified either as decimal numbers or as symbolic code names from the table below:

Name         Numeric value
EX_OK            0
EX_USAGE         64
EX_DATAERR       65
EX_NOINPUT       66
EX_NOUSER        67
EX_NOHOST        68
EX_UNAVAILABLE   69
EX_SOFTWARE      70
EX_OSERR         71
EX_OSFILE        72
EX_CANTCREAT     73
EX_IOERR         74
EX_TEMPFAIL      75
EX_PROTOCOL      76
EX_NOPERM        77
EX_CONFIG        78

Signal codes can be given either as SIG+N, where N is the signal number, or as signal names from the following list: SIGHUP, SIGINT, SIGQUIT, SIGILL, SIGTRAP, SIGABRT, SIGIOT, SIGBUS, SIGFPE, SIGKILL, SIGUSR1, SIGSEGV, SIGUSR2, SIGPIPE, SIGALRM, SIGTERM, SIGSTKFLT, SIGCHLD, SIGCONT, SIGSTOP, SIGTSTP, SIGTTIN, SIGTTOU, SIGURG, SIGXCPU, SIGXFSZ, SIGVTALRM, SIGPROF, SIGWINCH, SIGPOLL, SIGIO, SIGPWR, SIGSYS.

If the component exits with an exit code listed in CODES or is terminated on a signal listed in CODES, pies executes actions specified by its substatements. They are executed in the order of their appearance below:

 -- Pies Conf: exec COMMAND
     Execute external command.  Prior to execution of COMMAND all file descriptors are closed.  It inherits the environment from the main pies process with the following additional variables:

     PIES_VERSION
          The pies version number (VERSION).

     PIES_COMPONENT
          Tag of the terminated component (see tag).

     PIES_PID
          PID of the terminated component.

     PIES_SIGNAL
          If the component terminated on signal, the number of that signal.

     PIES_STATUS
          Program exit code.

 -- Pies Conf: action disable | restart
     If restart is given, restart the component.  This is the default.  Otherwise, mark the component as disabled.  Component dependents are stopped and marked as disabled as well.  Once disabled, the components are never restarted, unless their restart is requested by the administrator.

 -- Pies Conf: notify EMAIL-STRING
     Send an email notification to addresses in EMAIL-STRING.  The latter is a comma-separated list of email addresses, e.g.:

          notify "root@localhost,postmaster@localhost";

     The mailer statement (see Mailer Statement (GNU Mailutils Manual)) configures the mailer used to send the message.  The message itself is configured by the message statement.

 -- Pies Conf: message STRING
     Supply notification message text to use by notify statement. STRING must be a valid RFC 822 message text, i.e. it must begin with message headers, followed by an empty line and actual message body.

     The following macro-variables are expanded within STRING:

     Variable   Expansion
     canonical-program-name   pies
     program-name   Program name of the pies binary.
     package      Package name (Mailfromd).
     version      Package version (VERSION).
     mu-version   Version of GNU Mailutils.
     component    Name of the terminated component.
     retcode      Component exit code, in decimal.

     If message statement is not given, the following default message is used instead:

          From: <>
          X-Agent: ${canonical-program-name} (${package} ${version})
          Subject: Component ${component} terminated with code ${retcode}.

Any number of return-code statements are allowed, provided that their CODES do not intersect.

Such statements can also be used outside of component block. In this case, they supply global actions, i.e. actions applicable to all components.  Any return-code statements appearing within a component block override the global ones.

Output Redirectors
------------------

Output redirectors allow to redirect the standard error and/or standard output of a component to a file or syslog facility.

 -- Pies Conf: stderr TYPE CHANNEL
 -- Pies Conf: stdout TYPE CHANNEL
     Redirect standard error (if stderr) or standard output (if stdout) to the given channel.

     The type of redirection is specified by TYPE argument:

     file
          Redirect to the file.  In this case CHANNEL gives the full name of the file.  For example:

               stderr file /var/log/component/name.err;

     syslog
          Redirect to the syslog channel.  The syslog priority is given by the CHANNEL argument.  Its allowed values are: emerg, alert, crit, err, warning, notice, info, debug.  The facility is inherited from the logging statement (see Mailutils Logging (GNU Mailutils Manual)), or from facility statement (see below), if given.

          Example:

               stderr syslog err;

 -- Pies Conf: facility SYSLOG-FACILITY
     Specify the syslog facility to use in syslog redirectors.  Allowed values for SYSLOG-FACILITY are: user, daemon, auth, authpriv, mail, cron, local0 through local7 (all names case-insensitive), or a facility number.

Inetd-Style Components
----------------------

Inetd-style components are declared using mode inetd statement.  You must also declare a socket to listen for requests for such components:

 -- Pies Conf: socket URL
     Define a socket to listen on.  Allowed values for URL are:

     file name
          Specifies a UNIX socket file name.  You may use a relative file name, provided that chdir statement is used for this component (see chdir).

     local://FILE[;ARGS]
     file://FILE[;ARGS]
     unix://FILE[;ARGS]
          Listen on the UNIX socket file FILE, which may be either absolute or relative file name, as described above.  Optional arguments ARGS control ownership and file mode of FILE.  They are a list of assignments, separated by semicolons.  The following values are allowed:

          user
               User name of the socket owner.

          group
               Owner group of the socket, if it differs from the user group.

          mode
               Socket file mode (octal number between 0 and 777).

          umask
               Umask to use when creating the socket (octal number between 0 and 777).

          For example:

               socket unix:/var/run/socket;user=nobody;group=mail;mode=770

     inet://IP:PORT
          Listen on IPv4 address IP (may be given as a symbolic host name), on port PORT.

     Notice, that pies version VERSION handles only TCP sockets and only IPv4 addresses.  Support for IPv6 will be added in future versions.  Support for UDP sockets will be added if there is a demand.

Meta1-Style Components
----------------------

Meta1-style components are declared using mode pass statement.  For such components, you must declare both a socket to listen on (see inetd-socket and a UNIX socket name to pass the file descriptor to the component.  The latter is defined using pass-fd-socket statement:

 -- Pies Conf: pass-fd-socket FILE-NAME
     The argument is an absolute or relative file name of the socket file. In the latter case, the chdir DIR statement must be used for this component (see chdir), and the socket will be looked under DIR.

     This socket file is supposed to be created by the component binary upon its startup.

Component Syntax Summary
------------------------

This subsection summarizes the component summary.  For each statement, a reference to its detailed description is supplied.

     component TAG {
       # Component execution mode.
       # See mode.
       mode exec | wait | accept | inetd | nostartaccept | pass-fd | pass;

       # Full name of the program.
       # See program.
       program NAME;
       # Command line.
       # See command.
       command STRING;

       # Disable this entry.
       # See disable.
       disable BOOL;
       # Mark this entry as precious.
       # See precious.
       precious BOOL;

       # List of prerequisites.
       # See Prerequisites.
       prerequisites (COMPNAMES);
       # List of components for which this one is a prerequisite.
       # See dependents.
       dependents (COMPNAMES);

       # Listen on the given url.
       # See Inetd-Style Components.
       socket URL;

       # Pass fd through this socket.
       # See Meta1-Style Components.
       pass-fd-socket SOKET-NAME;

       # ACL for this component.
       # See ACL Statement (GNU Mailutils Manual).
       acl { ... }

       # Override default syslog facility for this component.
       facility FACILITY;
       # Redirect program's standard output to the given
       # file or syslog priority.
       # See Output Redirectors.
       stdout file | syslog CHANNEL;
       # Redirect program's standard error to the given
       # file or syslog priority.
       # See Output Redirectors.
       stderr file | syslog CHANNEL;

       # Run with this user privileges.
       # See Component Privileges.
       user USER-NAME;
       # Retain supplementary group.
       # See group.
       group GROUP-NAME;
       # Retain all supplementary groups of which user is a member.
       # See allgroups.
       allgroups BOOL;

       # Set system limits.
       # See Resources.
       limits STRING;

       # Force this umask.
       # See umask.
       umask NUMBER;

       # Set program environment.
       # See env.
       env ASSIGNMENTS;

       # Change to this directory before executing the component.
       # See chdir.
       chdir DIR;
       # Remove FILE-NAME before starting the component.
       # See remove-file.
       remove-file FILE-NAME;
       # Time to wait before starting this component.
       # See settle-timeout.
       settle-timeout NUMBER;

       # Actions:
       # See Exit Actions.
       return-code EXIT-CODE-LIST {
         # Action to take when a component finishes with this return code.
         action disable | restart;
         # Notify these addresses when then component terminates.
         notify EMAIL-STRING;
         # Notification message text (with headers).
         message STRING;
       }
     }

Using MeTA1 Configuration File
==============================

Pies is able to take a list of components from MeTA1 configuration file:

 -- Pies Conf: include-meta1 FILE
     Parse FILE as MeTA1 configuration file and incorporate components defined there into the current component list.

     For example:

     include-meta1 /etc/meta1/meta1.conf;

Thus, you can use pies instead of the default MeTA1 program manager mcp.

To ensure compatibility with MeTA1, the components read from MeTA1 configuration are started in the reverse order (i.e. from last to first), and stopped in the order of their appearance in FILE.  Of course, this does not affect normal pies components.

The following pies statements are silently applied to all MeTA1 components:

     allgroups yes;
     stderr file COMPNAME.log
     chdir QUEUE-DIR

Here, COMPNAME stands for the name of the component, and QUEUE-DIR stands for the name of MeTA1 queue directory.  The latter is /var/spool/meta1 by default.  It can be changed using the following statement

 -- Pies Conf: meta1-queue-dir DIR
     Set name of MeTA1 queue directory.

To override any default settings for a MeTA1 component, add a command section with the desired settings after including meta1.conf.  For example, here is how to redirect program diagnostics to local1.debug syslog channel:

     include-meta1 /etc/meta1/meta1.conf

     component smtps {
       facility local1;
       stderr syslog debug;
     }

Global Configuration
====================

The statements described in this section affect pies behavior as a whole.

 -- Pies Conf: umask NUMBER
     Set the default umask.  The NUMBER must be an octal value not greater than 777.  The default umask is inherited at startup.

 -- Pies Conf: limits ARG
     Set global system limits for all pies components.  See limits, for a detailed description of ARG.

 -- Pies Conf: return-code { ... }
     Configure global exit actions.  See Exit Actions, for a detailed description of this statement.

 -- Pies Conf: shutdown-timeout NUMBER;
     Wait NUMBER of seconds for all components to shut down. Default is 5 seconds.

Less Useful Statements
----------------------

Some configuration file statements are provided for completeness and are rarely, if at all used.  If used improperly, they may severely impair the functionality of pies or even render it useless.  Do not use them, unless you have a good knowledge of pies internals and understand their impact.

The following three statements define file names of various files needed by pies.  Use them only if the defaults does not suit your needs:

 -- Pies Conf: pidfile FILE
     Write PID of the master pies process to FILE.  By default, master PID is stored in STATEDIR/pies.pid (see statedir).

 -- Pies Conf: control-file FILE
     Set file name of the pies control file.  Default is STATEDIR/pies.ctl

 -- Pies Conf: stat-file FILE
     Set file name of the statistics output file.  Default is STATEDIR/pies.stat.

Normally, pies must be run with root privileges.  If, however, you found such an implementation for it, that requires another privileges, you may change them using the following three statements:

pies process.
 -- Pies Conf: user USER-NAME
     Start pies with the UID and GID of this user.

 -- Pies Conf: group GROUP-LIST
     Retain supplementary groups, specified in GROUP-LIST.

 -- Pies Conf: allgroups BOOL
     Retain all supplementary groups of which user, given with user statement, is a member.

Pies Debugging
==============

The amount of debugging information produced by pies is configured by the following two configuration statements.  First of all, the standard debug block statement controls debugging of the underlying GNU Mailutils libraries (see Mailutils Configuration File (GNU Mailutils Manual)).  Secondly, the debug statement controls debugging output of the pies utility itself.

 -- Pies Conf: debug SPEC
     Set debugging level for the pies code.  See Mailutils Configuration File (GNU Mailutils Manual), for a description of SPEC syntax.  The following debugging levels are used:

     trace1
          Log all basic actions: starting and stopping of components, received incoming TCP connections, sending mails.  Notify about setting limits.  Log pre-startup actions (see Actions Before Startup).

     trace2
          Log setting particular limits.  Log the recomputed alarms.

     trace4
          Dump execution environments

     trace6
          Debug the parser of MeTA1 configuration grammar.

     trace7
          Debug the lexical analyzer of MeTA1 configuration file.

Configuration Example
=====================

In this section we provide several examples of working pies configuration files.

Simplest Case: Using Pies to Run Pmult
--------------------------------------

The example below runs pmult (see pmult) utility with the privileges of meta1 user.  Both standard error and standard output are redirected to the syslog facility mail, priorities err and info, correspondingly.

     component pmult {
       command "/usr/local/sbin/pmult";
       user meta1s;
       facility mail;
       stderr syslog err;
       stdout syslog info;
     }

Using Pies to Run Pmult and MeTA1
---------------------------------

The example below is a working configuration file for running pmult and all components of MeTA1, configured in /etc/meta1/meta1.conf.  The global return-code statement is used to configure pies behavior for some exit codes.

     # Sample pies configuration for running pmult and MeTA1

     # Special handling for exit codes that mean the program was
     # incorrectly used or misconfigured.
     return-code (EX_USAGE, EX_CONFIG) {
       action disable;
       notify "root";
       message <<- EOT
         From: Pies <>
         X-Agent: ${canonical-program-name} (${package} ${version})
         Subject: Component ${component} disabled.

         Component "${component}" has terminated with code ${retcode},
         which means it encountered some configuration problem.
         I will not restart it automatically. Please fix its configuration
         and restart it manually at your earliest convenience.

         To restart, run ``${program-name} -R ${component}''
         ---
         Wuff-wuff,
         Pies
       EOT;
     }

     component pmult {
       command "/usr/local/sbin/pmult";
       user meta1s;
       stderr syslog err;
       stdout syslog info;
     }

     include-meta1 "/etc/meta1/meta1.conf";

Running Pies Instead of Inetd
-----------------------------

This configuration file allows to run pies instead of initd.  It starts two services: ftp and pop3d, and restricts access to them to two local subnets:

     acl {
        log from any "Connect from ${address}";
        allow from 10.10.10.0/24;
        allow from 192.168.10.0/27;
        deny from any;
     }

     debug "<trace4";

     component ftp {
        mode inetd;
        socket "inet://0.0.0.0:21";
        umask 027;
        program /usr/sbin/ftpd
        command ftpd -l -C;
     }

     component pop3d {
        mode inetd;
        socket "inet://0.0.0.0:110";
        program "/usr/sbin/pop3d";
        command "pop3d --inetd";
     }

Command Line Usage
==================

When run without arguments, pies parses and loads the configuration file, detaches itself from the controlling terminal (becomes a daemon), and starts all components.  Before actually starting up, it ensures that no another instance of it is already running, by looking for a PID file and verifying that the PID listed there is alive and responding.  If another instance is running, pies refuses to start up.

After startup, you can verify the status of the running process using --status command line option:

     $ pies --status
     redirector smtps/stderr 4697
     redirector pmult/stderr 4677
     redirector pmult/stdout 4676
     component pmult 4678 /usr/local/sbin/pmult
     component smar 4680 smar -f /etc/meta1/meta1.conf -d 100
     component qmgr 4691 qmgr -f /etc/meta1/meta1.conf
     component smtpc 4696 smtpc -f /etc/meta1/meta1.conf
     component smtps 4698 smtps -d100 -f /etc/meta1/meta1.conf

In its output, lines beginning with component refer to running components.  For running components, the following information is displayed:

 1. Component tag (see Component Statement).

 2. PID of the running instance of the component.

 3. Command line of the component, as set by the command statement (see command).

If the component is not running, the reason is indicated in the PID column, between the square brackets, e.g.:

     component pmult [disabled; scheduled for Mon 01 Dec 2008 20:27:02]
       /usr/local/sbin/pmult

(the example above is split in two lines for readability).

You can restart any component by using the --restart-component (-R) option, e.g.:

     $ pies -R pmult smtps

To stop all running components and shut down pies, use the --stop (-S) command line option:

     $ pies --stop

Two options are provided for verifying inter-component dependencies.  The --dump-depmap option prints on the standard output the dependency map.  This map is a square matrix with rows representing dependents and columns representing prerequisites. An X sign is placed on each crossing which corresponds to the actual dependency.  For example:

     $ pies --dump-depmap
     Dependency map:
         0  1  2  3  4
      0
      1
      2     X
      3        X
      4     X  X

     Legend:
      0: pmult
      1: smar
      2: qmgr
      3: smtpc
      4: smtps

This example corresponds to the configuration file shown in Hairy Pies.  To illustrate how to read it, consider the 4th row of the table.  According to the legend, number 4 means smtps component.  There are two X marks: in columns 1 and 2.  This means that smtps depends on smar and qmgr.

You can also list prerequisites explicitly:

     $ pies --dump-prereq
     qmgr: smar
     smtpc: qmgr
     smtps: smar qmgr

Pies Invocation
===============

This section summarizes pies command line options.

--force
     Force startup even if another instance may be running.

--foreground
     Remain in foreground.

--stderr
     Log to standard error.

--syslog
     Log to syslog.  This is the default.

-x LEVEL
--debug=LEVEL
     Set debug verbosity level.  See Pies Debugging, for a description of LEVEL.

-r
--reload
--hup
     Reload the running instance of pies.

-R
--restart-component
     Restart components named in the command line.  See pies-restart.

-s
--status
     Display info about the running instance.  See pies-status.

-S
--stop
     Stop the running instance.

--dump-depmap
     Dump dependency map.  See dump-depmap.

--dump-prereq
     Dump prerequisite charts.  See dump-prereq.

Apart from these, the common GNU Mailutils options are understood, which are useful for checking pies configuration file for syntax errors.  See Common Options (GNU Mailutils Manual), for a detailed description of these.