\input texinfo @c -*-texinfo-*-
@c %**start of header
@setfilename pies.info
@settitle GNU Pies Manual
@c %**end of header
@setchapternewpage odd

@defcodeindex pr
@defcodeindex op
@c mt is the same as op, but used for mtasim options.
@defcodeindex mt
@defcodeindex kw
@defcodeindex fl

@syncodeindex fn cp
@syncodeindex vr cp
@syncodeindex ky cp
@syncodeindex mt cp
@syncodeindex pg cp
@syncodeindex tp cp
@syncodeindex op cp
@syncodeindex pr cp
@syncodeindex kw cp
@syncodeindex fl cp

@include version.texi
@include rendition.texi
@include macros.texi

@ifinfo
@dircategory System Administration
@direntry
* GNU Pies: (pies).             Program Invocation and Execution Supervisor.
* pies: (pies) Invocation.      GNU Pies Command Line Options.
* pies.conf: (pies) Configuration.    GNU Pies Configuration File.
* piesctl: (pies) piesctl.            GNU Pies Control Tool.
* piesctl.conf: (pies) piesctl.conf.  Configuration File for the @command{piesctl} tool.
@end direntry
@end ifinfo

@copying
Published by the Free Software Foundation,
31 Milk Street,
Boston, MA 02196 USA

Copyright @copyright{} 2005--2026 Sergey Poznyakoff

Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.3 or
any later version published by the Free Software Foundation; with no
Invariant Sections, and no specific Front-Cover and Back-Cover texts.
@end copying

@titlepage
@title The @sc{GNU PIES} Manual
@subtitle version @value{VERSION}, @value{UPDATED}
@author Sergey Poznyakoff.
@page
@vskip 0pt plus 1filll
@insertcopying
@end titlepage

@ifnothtml
@page
@summarycontents
@end ifnothtml

@page
@contents

@ifnottex
@node Top
@top GNU Pies Manual

This edition of the @cite{GNU Pies Manual}, last updated @value{UPDATED},
documents @command{pies} Version @value{VERSION}.
@end ifnottex

@menu
* Intro::                    Introduction to Process Management with @command{Pies}.
* Dependencies::             Inter-process dependencies.
* Configuration::            Configuration Files of Various Syntax.
* Pies Debugging::           Debugging @command{Pies}.
* piesctl::                  Communication with Running @command{pies} Instances.
* Init Process::             Using @command{Pies} as Parent of All Processes.
* Docker Entrypoint::        Using @command{Pies} as Entrypoint in Docker Container.
* Configuration Examples::   Examples of Configuration Files.
* Command Line Usage::
* Invocation::
* Reporting Bugs::

Appendices

* inetd configuration::  @file{Inetd.conf} Format.
* User-Group ACLs::
* Control API::
* Copying This Manual::  The GNU Free Documentation License.
* Concept Index::        Index of Concepts.
@ifset WEBDOC
@ifhtml
* This Manual in Other Formats::
@end ifhtml
@end ifset

@detailmenu
 --- The Detailed Node Listing ---

Pies Configuration File

* Syntax::               Configuration File Syntax
* Preprocessor::         Using Preprocessor
* Component Statement::
* Notification::         Mail Notification.
* ACL::                  Access Control Lists.
* control::              The @samp{control} statement.
* inetd::                Using @command{inetd} Configuration Files.
* include-meta1::        Using @command{meta1} Configuration Files.
* Global Configuration::
* Pies Privileges::
* State Files::

Configuration File Syntax

* Comments::
* Statements::

Component Statement

* Prerequisites::
* Component Privileges::
* Resources::
* Environment::
* Early Environment Expansion::
* Actions Before Startup::
* Exit Actions::
* Output Redirectors::
* Inetd-Style Components::
* Meta1-Style Components::
* Visibility::
* Component Syntax Summary::

Inetd-Style Components

* builtin::    Built-in Inetd Services
* TCPMUX::     TCPMUX Services
* sockenv::    Socket Environment Variables
* inetd exit:: Exit Actions in Inetd Components

Communicating with Running @command{pies} Instances

* id::          Get Info About the Running Instance.
* stop and reboot:: Instance Management.
* config::      Configuration Management.
* components::  Component Management.
@c * telinit::
* piesctl.conf:: Configuration file for @command{piesctl}.

Init -- parent of all processes

* Runlevels::
* Init Process Configuration::
* Init Command Line::
* Init Environment::
* piesctl telinit::
* telinit command::

Configuration Examples

* Simple Pies::
* Hairy Pies::
* Inetd Pies::

@end detailmenu
@end menu

@node Intro
@chapter Introduction
@cindex component
  The name @command{pies} (pronounced @samp{p-yes}) stands for
@samp{Program Invocation and Execution Supervisor}.  This utility
starts and controls execution of external programs.   In this document
these programs will be referred to as @dfn{components}.  Each
component is a stand-alone program, which is executed in the
foreground.

  Upon startup, @command{pies} reads the list of components
from its configuration file, starts them, and remains in the
background, controlling their execution.  Each component is
defined by the name of the external program to be run and its
arguments (command line).  The program is normally run directly
(via @code{exec}), but you can instruct @command{pies} to run
it via @code{sh -c} as well.

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

  The way of handling each component, and in particular the action to
be taken upon its termination is determined by the component's @dfn{mode}.

@anchor{respawn}
@cindex respawn components
  A @dfn{respawn} component is restarted each time it terminates.  If
it terminates too often, @command{pies} puts it to sleep for certain
time and logs that fact.  This prevents badly configured components
from taking too much resources and allows administrator to take
measures in order to fix the situation.  More specific action can
be configured, depending on the exit code of the component.

@anchor{inetd-style}
@cindex inetd-style components
  An @dfn{inetd}-style components is not started.  Instead, @command{pies}
opens a socket associated with it and listens for connections on that
socket.  When a connection arrives, @command{pies} runs this component
to handle it. The connection is bound to the component's @samp{stdin}
and @samp{stdout} streams.  The @samp{stderr} stream can be redirected
to a file or to syslog, as described above.  This mode of operation is
similar to that of the @command{inetd} utility.

@anchor{meta1-style}
@cindex meta1-style components
@cindex pass-style components
@cindex smtps
  Yet another type of components supported by @command{pies} are
@dfn{pass-style} or @dfn{meta1-style} components.  As the name
suggests, this type is designed expressly as a support for
MeTA1@footnote{See @uref{http://www.meta1.org}} components, namely
@command{smtps}.  This type can be regarded as a mixture of the above
two.  For each meta1-style component @command{pies} opens a socket
and starts the component executable program.  Once the program
is running, @command{pies} passes it the file descriptor of that
socket, through another preconfigured @acronym{UNIX}-style socket.  Further
handling of the socket is the responsibility of the program itself.

@anchor{accept-style}
@cindex accept-style components
  An @dfn{accept} component is basically handled as @samp{inetd},
except that after binding to the socket @command{pies} immediately
starts the program, without waiting for actual connections.

@cindex startup components
@cindex shutdown components
  Finally, two special component modes are available. @dfn{Startup}
components are run right after @command{pies} startup, prior to
running any other components. Their counterpart, @dfn{shutdown}
components are run before program termination, after all other
components have finished.

  Any number of components of all types can be handled simultaneously.

  Components are started in the order of their appearance in the
configuration file and terminated in reverse order.  This order can
be modified by declaring component @dfn{prerequisites} or
@dfn{dependents}. This is described in the following chapter.

  As an exception, this order is reversed for the components read from
MeTA1 configuration files, either included by @code{include-meta1}
statement (@pxref{include-meta1}) or expressly supplied in the command
line (@pxref{config syntax}).

@node Dependencies
@chapter Inter-Component Dependencies
@cindex prerequisite
@cindex dependency
@cindex dependents
@anchor{component prerequisite}
  A component @samp{A} may depend on another components, say
@samp{B} and @samp{C}, i.e. require them to be running at the moment of its
startup.  Components @samp{B} and @samp{C} are called
@dfn{prerequisites} for @samp{A}, while @samp{A} is called a
@dfn{dependency} or @dfn{dependent} component of @samp{B}, @samp{C}.

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

@node Configuration
@chapter Pies Configuration File
@cindex configuration file
@flindex pies.conf
@xopindex{config-file, introduced}
  @command{Pies} reads its settings and component definitions from one
or more @dfn{configuration files}.  The default configuration file
is named @file{pies.conf} and is located in the @dfn{system
configuration directory} (in most cases @file{/etc} or
@file{/usr/local/etc}, depending on how the package was compiled).
This file uses the @dfn{native Pies configuration syntax}.  Apart from
this format, the program also understands configuration files in
@dfn{inetd} and @dfn{meta1} formats.

  Alternative configuration files may be specified using @option{--config-file}
(@option{-c} command line option), e.g.:

@example
pies --config-file @var{filename}
@end example

@anchor{config syntax}
Any number of such options may be given.  The files named in
@option{--config-file} options are processed in order of their
appearance in the command line.  By default, @command{pies} expects
configuration files in its native format.  This, however, can be
changed by using the @option{--syntax=@var{format}} command line
option.  This option instructs @command{pies} that any configuration
files given after it have are written in the specified @var{format}.
Valid formats are:

@table @samp
@item pies
@command{Pies} native configuration file format.

@item inetd
@command{Inetd}-style configuration format.

@item meta1
MeTA1-style format.

@item inittab
Format of the @file{/etc/inittab} file (@pxref{Init Process}).
@end table

The configuration file format set by the @option{--syntax} option remains
in effect for all @option{--config-file} options that follow it, up to
the end of the command line or the next occurrence of the
@option{--syntax} option.  This means that you can instruct
@command{pies} to read several configuration files of various formats
in a single command line, e.g.:

@example
@group
pies --config-file /etc/pies.conf \
     --syntax=inetd --config-file /etc/inetd.conf \
     --syntax=meta1 --config-file /etc/meta1/meta1.conf
@end group
@end example

@xopindex{config-help, introduced}
  The rest of this chapter concerns the @command{pies} native
configuration file format.  You can receive a concise summary of all
configuration directives any time by running @command{pies
--config-help}.  The use of inetd configuration files is
covered in @ref{inetd} and the use of meta1 configuration files
is described in @ref{include-meta1}

  If any errors are encountered in the configuration file, the program
reports them on the standard error and exits with status 78.

@anchor{lint}
@xopindex{lint, introduced}
  To test the configuration file without actually starting the server, the
@option{--lint} (@option{-t}) command line option is provided.  It causes
@command{pies} to check its configuration file and exit with status 0
if no errors were detected, and with status 78 otherwise.

@cindex @option{-E}, introduced
  Before parsing, configuration file is preprocessed using
@command{m4} (@pxref{Preprocessor}).  To see the preprocessed
configuration without actually parsing it, use @option{-E} command
line option.

@menu
* Syntax::               Configuration File Syntax
* Preprocessor::         Using preprocessor.
* Component Statement::
* Notification::         Mail Notification.
* ACL::                  Access Control Lists.
* control::              The @samp{control} statement.
* Identities::           User Identities for Accessing Control Interface.
* inetd::                Using @command{inetd} Configuration Files.
* include-meta1::        Using @command{meta1} Configuration Files.
* Global Configuration::
* Pies Privileges::
* State Files::
@end menu

@node Syntax
@section Configuration File Syntax
  The configuration file consists of statements and comments.

  There are three classes of lexical tokens: keywords, values, and
separators.  Blanks, tabs, newlines and comments, collectively called
@dfn{white space} are ignored except as they serve to separate
tokens.  Some white space is required to separate otherwise adjacent
keywords and values.

@menu
* Comments::
* Statements::
@end menu

@node Comments
@subsection Comments
@cindex Comments in a configuration file
@cindex single-line comments
  @dfn{Comments} may appear anywhere where white space may appear in the
configuration file.  There are two kinds of comments:
single-line and multi-line comments.  @dfn{Single-line} comments start
with @samp{#} or @samp{//} and continue to the end of the line:

@example
# This is a comment
// This too is a comment
@end example

The following constructs, appearing at the start of a line are
treated specially: @samp{#include}, @samp{#include_once},
@samp{#line}, @samp{# @var{num}} (where @var{num} is a decimal number).
These are described in detail in @ref{Preprocessor}.

@cindex multi-line comments
  @dfn{Multi-line} or @dfn{C-style} comments start with the two
characters @samp{/*} (slash, star) and continue until the first
occurrence of @samp{*/} (star, slash).

  Multi-line comments cannot be nested.

@node Statements
@subsection Statements
@cindex statements, configuration file
@cindex configuration file statements
@cindex statement, simple
@cindex simple statements
  A @dfn{simple statement} consists of a keyword and value
separated by any amount of whitespace.  The statement is terminated
with a semicolon (@samp{;}).

  Examples of simple statements are:

@example
pidfile /var/run/pies.pid;
source-info yes;
debug 10;
@end example

  A @dfn{keyword} begins with a letter and may contain letters,
decimal digits, underscores (@samp{_}) and dashes (@samp{-}).
Examples of keywords are: @samp{group}, @samp{control-file}.

  A @dfn{value} can be one of the following:

@table @asis
@item number
  A number is a sequence of decimal digits.

@item boolean
@cindex boolean value
  A boolean value is one of the following: @samp{yes}, @samp{true},
@samp{t} or @samp{1}, meaning @dfn{true}, and @samp{no},
@samp{false}, @samp{nil}, @samp{0} meaning @dfn{false}.

@item unquoted string
@cindex string, unquoted
  An unquoted string may contain letters, digits, and any of the
following characters: @samp{_}, @samp{-}, @samp{.}, @samp{/},
@samp{:}.

@item quoted string
@cindex quoted string
@cindex string, quoted
@cindex escape sequence
  A quoted string is any sequence of characters enclosed in
double-quotes (@samp{"}).  A backslash appearing within a quoted
string introduces an @dfn{escape sequence}, which is replaced
with a single character according to the following rules:

@float Table, backslash-interpretation
@caption{Backslash escapes}
@multitable @columnfractions 0.30 .5
@headitem Sequence @tab Replaced with
@item \a @tab Audible bell character (@acronym{ASCII} 7)
@item \b @tab Backspace character (@acronym{ASCII} 8)
@item \f @tab Form-feed character (@acronym{ASCII} 12)
@item \n @tab Newline character (@acronym{ASCII} 10)
@item \r @tab Carriage return character (@acronym{ASCII} 13)
@item \t @tab Horizontal tabulation character (@acronym{ASCII} 9)
@item \v @tab Vertical tabulation character (@acronym{ASCII} 11)
@item \\ @tab A single backslash (@samp{\})
@item \" @tab A double-quote.
@end multitable
@end float

  In addition, any occurrence of @samp{\} immediately followed by
a newline character (@acronym{ASCII} 10) is removed from
the string.  This allows to split long strings over several
physical lines, e.g.:

@example
@group
"a long string may be\
 split over several lines"
@end group
@end example

  If the character following a backslash is not one of those specified
above, the backslash is ignored and a warning is issued.

@anchor{here-document}
@item Here-document
@cindex here-document
  @dfn{Here-document} is a special construct that allows to introduce
strings of text containing embedded newlines.

  The @code{<<@var{word}} construct instructs the parser to read all
the following lines up to the line containing only @var{word}, with
possible trailing blanks.  Any lines thus read are concatenated
together into a single string.  For example:

@example
@group
<<EOT
A multiline
string
EOT
@end group
@end example

  Body of a here-document is interpreted the same way as
double-quoted string, unless @var{word} is preceded by a backslash
(e.g.@: @samp{<<\EOT}) or enclosed in double-quotes, in which case
the text is read as is, without interpretation of escape sequences.

  If @var{word} is prefixed with @code{-} (a dash), then all leading
tab characters are stripped from input lines and the line containing
@var{word}.  Furthermore, if @code{-} is followed by a single space,
all leading whitespace is stripped from them.  This allows to indent
here-documents in a natural fashion.  For example:

@example
@group
<<- TEXT
    All leading whitespace will be
    ignored when reading these lines.
TEXT
@end group
@end example

  It is important that the terminating delimiter be the only token on
its line.  The only exception to this rule is allowed if a
here-document appears as the last element of a statement.  In this
case a semicolon can be placed on the same line with its terminating
delimiter, as in:

@example
help-text <<-EOT
        A sample help text.
EOT;
@end example

@item list
@cindex list
  A @dfn{list} is a comma-separated list of values.  Lists are
delimited by parentheses.  The following example shows a statement
whose value is a list of strings:

@example
dependents (pmult, auth);
@end example

  In any case where a list is appropriate, a single value is allowed
without being a member of a list: it is equivalent to a list with a
single member.  This means that, e.g.@: @samp{dependents auth;} is
equivalent to @samp{dependents (auth);}.

@end table

@cindex statement, block
@cindex block statement
  A @dfn{block statement} introduces a logical group of another
statements.  It consists of a keyword, followed by an optional value,
and a sequence of statements enclosed in curly braces, as shown in
the example below:

@example
@group
component multiplexor @{
        command "pmult";
@}
@end group
@end example

  The closing curly brace may be followed by a semicolon, although
this is not required.

@node Preprocessor
@section Preprocessor
@cindex preprocessor
Before parsing, configuration file is preprocessed.  This goes in
three stages.  First, include directives are expanded.  An
@dfn{include directive} begins with a @samp{#} sign at the beginning
of a line, followed by the word @samp{include} or @samp{include_once}.
Any amount of whitespace is allowed between the @samp{#} and the
word.  The entire text up to the end of the line is removed and
replaced using the following rules:

@table @code
@kwindex #include
@item #include @var{file}
The contents of the file @var{file} is included.

If @var{file} contains wildcard characters (@samp{*}, @samp{[},
@samp{]} or @samp{?}), it is interpreted as shell globbing pattern and
all files matching that pattern are included, in lexicographical
order.  If no matching files are found, the directive is replaced with
an empty line.

Otherwise, the named file is included.  Unless @var{file} is an
absolute file name, it will be searched relative to the current
working directory.  An error message will be issued if it does not
exist.

@kwindex #include_once
@item #include_once @var{file}
  Same as @code{#include}, except that, if the @var{file} has already
been included, it will not be included again.
@end table

@cindex m4
@cindex preprocessor, external
@cindex external preprocessor
  The obtained material is then passed to @dfn{external
preprocessor}.  By default, @command{pies} uses GNU @command{m4}.
This powerful macro processor is described
in @ref{Top, GNU M4 manual,, m4, GNU M4 macro processor}.
For the rest of this subsection we assume the reader is sufficiently
acquainted with the @command{m4} macro processor.

  The external preprocessor is invoked with the following two flags:
@option{-s} flag, instructing it to include line synchronization
information in its output, and @option{-P}, which changes all
@command{m4} built-in macro names by prefixing them with @samp{m4_}.

@anchor{additional preprocessor options}
  The following command line options are passed to @command{m4}
verbatim:

@table @option
@xopindex{define, described}
@cindex @option{-D}
@item --define=@var{sym}[=@var{value}]
@itemx -D @var{symbol}[=@var{value}]
Define symbol @var{sym} as having @var{value}, or empty, if
the @var{value} is not given.

@xopindex{undefine, described}
@cindex @option{-U}
@item --undefine=@var{sym}
@itemx -U @var{sym}
Undefine symbol @var{sym}.
@end table

@xopindex{include-directory, described}
The @option{--include-directory=@var{dir}} or @option{-I @var{dir}}
option causes the option @option{-I @var{dir}} to be appended to
the preprocessor command line.  This option modifies the @command{m4}
include search path (@pxref{Search Path, GNU M4 manual,, Search Path, GNU M4 macro processor}).

Finally, the following two options are appended:

@table @option
@item -I @var{$prefix}/share/pies/include
@item -I @var{$prefix}/share/pies/@value{VERSION}/include
@end table

@noindent
(where @var{$prefix} stands for installation prefix chosen when the
package was built.  Normally it is @file{/usr}.)  This step can be
disabled using the @option{--no-include} option.

These provide the default search path.

The name of the source file is appended to the command line, and the
constructed command is executed via @command{$SHELL -c} and its output
is then passed to the configuration parser.  When parsing, the
following constructs appearing at the beginning of a line are handled
specially:

@table @code
@kwindex #line
@item #line @var{num}
@itemx #line @var{num} "@var{file}"
  This line causes the parser to believe, for purposes of error
diagnostics, that the line number of the next source line is given by
@var{num} and the current input file is named by @var{file}.
If the latter is absent, the remembered file name does not change.

@item # @var{num} "@var{file}"
  This is a special form of @code{#line} statement, understood for
compatibility with the @sc{c} preprocessor.

@kwindex #warning
@item #warning "@var{text}"
  Emits @var{text} as a warning.

@kwindex #error
@item #error "@var{text}"
  Emits @var{text} as an error message.  Further parsing continues,
but will end with failure.

@kwindex #abend
@item #abend "@var{text}"
  Emits @var{text} as an error message and stops further processing
immediately.
@end table

If @code{#error} or @code{#abend} is encountered, the effect is the same
as if syntax error has been detected.  If it occurs at @command{pies}
startup, the program will terminate abnormally.  If it occurs as
part of the reload sequence in a running instance of @command{pies},
the configuration file will be rejected and old configuration will
remain in effect.

@menu
* m4::                   Using M4.
* custom preprocessor::  Using Custom Preprocessor.
@end menu

@node m4
@subsection Using M4
@WRITEME
  This subsection gives some tips on using the default preprocessor.

@node custom preprocessor
@subsection Using Custom Preprocessor
  The default preprocessor can be changed (or even disabled) at
compile time as well as on the runtime.  When invoked with the
@option{--help} option @command{pies} reports, among others, the
preprocessor it is configured to use and the default include search
path.

  To disable preprocessing, use the @option{--no-preprocessor} command
line option.

  To change the default preprocessor at runtime, use the
@option{--preprocessor} option.  Its argument is the initial
preprocessor command line.  Depending on the @command{pies} command line,
it can be further modified by appending new options as described in
@ref{additional preprocessor options}.

  When selecting another preprocessor, please bear in mind that
@command{pies} assumes that the preprocessor program understands the
following three options:

@table @option
@item -D @var{name}[=@var{value}]
Define the preprocessor symbol @var{name}.

@item -I @var{dir}
Add the directory @var{dir} to the preprocessor search path for
include files.

@item -U @var{name}
Undefine the preprocessor symbol @var{name}.
@end table

@command{pies} never passes @option{-D} and @option{-U} options,
except as if these were passed to it in the command line.

However, it normally adds one or more @option{-I} options to configure
the default search path.

If the preprocessor of your choice doesn't support some or any of these
options, there are several possible solutions.

@itemize @bullet
@item
If the preprocessor doesn't support @option{-D} and
@option{-U} options, don't pass them in the @command{pies} command
line.

@item
If it does not support the @option{-I} option, run @command{pies} with
the @option{--no-include} option or create a wrapper script which will
consume all @option{-I} options without affecting the preprocessor
command line.
@end itemize

  For an example of using alternative preprocessor, @xref{xenv}.

@node Component Statement
@section The @code{component} Statement
@kwindex component

@deffn {Config} component
  The @code{component} statement defines a new component:
@end deffn

@example
component @var{tag} @{
  @dots{}
@}
@end example

@cindex component tag
@cindex tag (component)
@anchor{tag}
The component is identified by its @dfn{tag}, which is given as
argument to the @code{component} keyword.  Component declarations with
the same tags are merged into a single declaration.

The following are the basic statements which are allowed within the
@code{component} block:

@anchor{component mode}
@deffn {Config: component} mode @var{mode}
  Declare the type (style) of the component.  Following are the basic
values for @var{mode}:

@table @code
@kindex exec
@kindex respawn
@item exec
@itemx respawn
  Define a @samp{respawn} component (@pxref{respawn}).  This is
the default.

@kindex inetd
@kindex nostartaccept
@item inetd
@itemx nostartaccept
  Define an @samp{inetd-style} component (@pxref{inetd-style}).

@kindex pass
@kindex pass-fd
@item pass
@itemx pass-fd
  Define a @samp{meta1-style} component (@pxref{meta1-style}).

@kindex accept
@item accept
  Define a @samp{accept-style} component (@pxref{accept-style}).

@kindex startup
@item startup
  The component is run right after startup. Prior to starting any
other components, @command{pies} will wait for all @code{startup}
components to terminate.

@kindex shutdown
@item shutdown
  These components are started as a part of program shutdown sequence,
after all regular components have terminated.  @xref{shutdown
sequence}, for a detailed discussion.
@end table

  When run as init process (@pxref{Init Process}), the following
@var{mode}s are also allowed:

@table @code
@item boot
  The process will be executed during system boot.  The
@samp{runlevel} settings are ignored.

@item bootwait
  The process will be executed during system boot.  No other
components will be started until it has terminated.  The
@samp{runlevel} settings are ignored.

@item ctrlaltdel
  The process will be executed when @command{pies} receives the SIGINT
signal.  Normally this means that the CTRL-ALT-DEL combination has
been pressed on the keyboard.

@item kbrequest
  The process will be executed when a signal from the keyboard handler
is received that indicates that a special key combination was pressed
on the console keyboard.

@item once
  The process will be executed once when the specified runlevel is
entered.

@item ondemand
  The process will be executed when the specified @dfn{ondemand}
runlevel is called (@samp{a}, @samp{b} and @samp{c}).  No real
runlevel change will occur (@pxref{Ondemand runlevels}).
The process will remain running across any eventual runlevel changes
and will be restarted whenever it terminates, similarly to
@code{respawn} components.

@item powerfail
  The process will be executed when the power goes down.  @command{Pies}
will not wait for the process to finish.

@item powerfailnow
  The process will be executed when the power is failing and the
battery of the external UPS is almost empty.

@item powerokwait
  The process will be executed as soon as @command{pies} is informed that
the power has been restored.

@item powerwait
  The process will be executed when the power goes down.  @command{Pies}
will wait for the process to finish before continuing.

@item sysinit
  The process will be executed during system boot, before any @code{boot}
or @code{bootwait} entries.  The @samp{runlevel} settings are ignored.

@item wait
  The process will be started once when the specified runlevel is
entered.  @command{Pies} will wait for its termination before starting
any other processes.
@end table
@end deffn

@deffn {Config: component} command @var{string}
Command line to run.  @var{string} is the full command line.  Its
first word (in the shell sense) is the name of the program to invoke.
@end deffn

@deffn {Config: component} program @var{name}
Full file name of the program to run.  When supplied, @command{pies}
will execute the program @var{name} instead of the first word in the
@code{command} statement.  The latter, however, will be passed to
the running program as @code{argv[0]}.
@end deffn

@anchor{flags}
@deffn {Config: component} flags (@var{flag-list})
Define flags for this component.  The @var{flag-list} is a
comma-separated list of flags.  Valid flags are:

@table @code
@kwindex deansify
Remove ANSI escape sequences from program output before logging it
as per @code{strerr} or @code{stdout} statements.  @xref{Output Redirectors}.

@kwindex disable
@item disable
This component is disabled, i.e.@: @command{pies} will parse and
remember its settings, but will not start it.

@kwindex expandenv
@item expandenv
Expand environment variables in the @samp{command} statement prior to
running it. When used together with the @samp{shell} flag, this flag
produces a warning and has no effect.  @xref{Early Environment
Expansion}, for a detailed discussion.

@kwindex internal
@item internal
This is an internal inetd component.  @xref{builtin}.

@kwindex nullinput
@cindex stdin
@cindex standard input
@item nullinput
Do not close standard input.  Redirect it from @file{/dev/null}
instead.   Use this option with commands that require
their standard input to be open (e.g.@: @command{pppd nodetach}).

@kwindex precious
@item precious
Mark this component as @dfn{precious}.  Precious components are never
disabled by @command{pies}, even if they respawn too fast.

@kwindex resolve
@item resolve
When used with @samp{sockenv}, the @env{LOCALHOST} and
@env{REMOTEHOST} environment variables will contain resolved host
names, instead of IP addresses.

@kwindex shell
@item shell
Run command as @code{/bin/sh -c "$command"}.  Use this flag if command
contains shell-specific features, such as I/O redirections, pipes,
variables or the like.  You can change the shell program using the
@code{program} statement.  For example, to use Korn shell:

@example
component X @{
  flags shell;
  program "/bin/ksh";
  command "myprog $HOME";
@}
@end example

@kwindex siggroup
@item siggroup
When stopping a component, send the signal to the process group,
instead of to the process itself.  Similarly, if a stopped
process fails to terminate within a predefined timeout
(@pxref{shutdown-timeout}, send @samp{SIGKILL} to the process group of this
process.

@kwindex sockenv
@item sockenv
This inetd component wants socket description variables in its
environment.  @xref{sockenv}.

@kwindex tcpmux
@item tcpmux
This is a @acronym{TCPMUX} component.  @xref{TCPMUX}.

@kwindex tcpmuxplus
@item tcpmuxplus
This is a @acronym{TCPMUX+} component.  @xref{TCPMUX}.

@kwindex wait
@item wait
This flag is valid only for @samp{inetd} components.  It has the same
meaning as @samp{wait} in @file{inetd.conf} file, i.e. it tells
@command{pies} to wait for the server program to
return.  @xref{inetd configuration, wait}.

@end table
@end deffn

@anchor{sigterm}
@deffn {Config: component} sigterm @var{sig}
Defines signal which should be sent to terminate this component.  The
default is @code{SIGTERM}.  The argument @var{sig} is either the name
of a signal defined in @file{/usr/include/signal.h}, or
@samp{SIG+@var{n}}, where @var{n} is signal number.
@end deffn

The following subsections describe the rest of @samp{component}
substatements.

@menu
* Prerequisites::
* Component Privileges::
* Resources::
* Environment::
* Early Environment Expansion::
* Actions Before Startup::
* Exit Actions::
* Output Redirectors::
* Inetd-Style Components::
* Meta1-Style Components::
* Visibility::
* Component Syntax Summary::
@end menu

@node Prerequisites
@subsection Component Prerequisites
@cindex declaring prerequisites
@cindex prerequisites, declaring
Prerequisites (@pxref{component prerequisite}) for a component are
declared using the following statement:

@deffn {Config: component} prerequisites @var{tag-list}
The argument is either a list of component tags or one of the
following words:

@table @code
@item all
Declare all components defined so far as prerequisites for this one.

@item none
No prerequisites.  This is the default.
@end table
@end deffn

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

@deffn {Config: component} dependents @var{tag-list}
Declare dependents for this component.  @var{var-list} is a list of
component tags.
@end deffn

@node Component Privileges
@subsection Component Privileges
@cindex privileges
  The following statements control privileges the component
is executed with.

@deffn {Config: component} user @var{user-name}
Start component with the UID and GID of this user.
@end deffn

@deffn {Config: component} group @var{group-list}
Retain supplementary groups, specified in @var{group-list}.
@end deffn

@deffn {Config: component} allgroups @var{bool}
Retain all supplementary groups of which the user (as given with
@command{user} statement) is a member.  This is the default for
components specified in @file{meta1.conf} file (@pxref{include-meta1}).
@end deffn

@node Resources
@subsection Resources

@deffn {Config: component} limits @var{string}
Impose limits on system resources, as defined by the @var{string}
argument.  It consists of @dfn{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 @code{ulimit}
utility:

@float Table, Limits
@caption{Limit Command Letters}
@multitable @columnfractions 0.3 0.6
@headitem Command @tab  The limit it sets
@item     A       @tab  max address space (KB)
@item     C       @tab  max core file size (KB)
@item     D       @tab  max data size (KB)
@item     F       @tab  maximum file size (KB)
@item     M       @tab  max locked-in-memory address space (KB)
@item     N       @tab  max number of open files
@item     R       @tab  max resident set size (KB)
@item     S       @tab  max stack size (KB)
@item     T       @tab  max CPU time (MIN)
@item     U       @tab  max number of processes
@item     P       @tab  process priority -20..20 (negative = high priority)
@end multitable
@end float

For example:

@example
limits T10 R20 U16 P20
@end example

Additionally, the command letter @samp{L} is recognized.  It is
reserved for future use (@samp{number of logins} limit) and is ignored
in version @value{VERSION}.
@end deffn

@deffn {Config: component} umask @var{number}
Set the umask.  The @var{number} must be an octal value not greater
than @samp{777}.  The default umask is inherited at startup.
@end deffn

@deffn {Config: component} max-instances @var{n}
Sets the maximum number of simultaneously running instances of this
component.
@end deffn

@node Environment
@subsection Environment
Normally all components inherit the environment of the master
@command{pies} process.  You can modify this environment using
the @code{env} statement.  It has two variants: @dfn{compound} and @dfn{legacy}.
The legacy one-line statement was used in @command{pies} versions
up to 1.3 and is still retained for backward compatibility.  It is
described in @ref{env legacy syntax}.  This subsection describes the
modern compound syntax.

The @code{env} statement can also be used in global context, in which
case it modifies environment for the master @command{pies} program,
i.e. the environment that will be inherited by all components
(@pxref{Global Configuration}).  The global @code{env} is available
only in compound syntax described here.

@deffn {Config: component} env @{ ... @}
The compound @code{env} statement has the following syntax:

@example
@group
env @{
   clear;
   keep @var{pattern};
   set "@var{name}=@var{value}";
   eval "@var{value}";
   unset @var{pattern};
@}
@end group
@end example
@end deffn

Statements inside the @code{env} block define operations that
modify the environment.  The @code{clear} and @code{keep} statements
are executed first.  Then, the @code{set} and @code{unset} statements
are applied in the order of their appearance in the configuration.

@deffn {env} clear
Clears the environment by removing (unsetting) all variables, except
those listed in @code{keep} statements, if such are given (see below).
The @code{clear} statement is always executed first.
@end deffn

@deffn {env} keep @var{pattern}
Declares variables matching @var{pattern} (a globbing pattern) as
exempt from clearing.  This statement implies @code{clear}.

For example, the following configuration fragment removes from the
environment all variables except @samp{HOME}, @samp{USER},
@samp{PATH}, and variables beginning with @samp{LC_}:

@example
@group
env @{
  clear;
  keep HOME;
  keep USER;
  keep PATH;
  keep "LC_*";
@}
@end group
@end example
@end deffn

@deffn {env} keep "@var{name}=@var{value}"
Retains the variable @var{name}, if it has the given value. Note, that
the argument must be quoted.
@end deffn

@deffn {env} set "@var{name}=@var{value}"
Assigns @var{value} to environment variable @var{name}.  The value is
subject to @dfn{variable expansion} using the same syntax as in shell.
The @code{set} and @code{unset} (see below) statements are executed in
order of their appearance.  For example

@example
@group
env @{
  set "MYLIB=$HOME/lib";
  set "LD_LIBRARY_PATH=$LD_LIBRARY_PATH$@{LD_LIBRARY_PATH:+:@}$MYLIB";
@}
@end group
@end example
@end deffn

@deffn {env} eval "@var{value}"
Perform variable expansion on @var{value} and discard the result. This
is useful for side-effects. For example, to provide default value for
the @env{LD_LIBRARY_PATH} variable, one may write:

@example
@group
env @{
  eval "$@{LD_LIBRARY_PATH:=/usr/local/lib@}";
@}
@end group
@end example
@end deffn

@deffn {env} unset @var{pattern}
Unset environment variables matching @var{pattern}.  The following
will unset the @env{LOGIN} variable:

@example
unset LOGIN;
@end example

@noindent
The following will unset all variables starting with @samp{LD_}:

@example
unset "LD_*";
@end example

@noindent
Notice, that patterns containing wildcard characters must be quoted.
@end deffn

@menu
* env legacy syntax::
@end menu

@node env legacy syntax
@subsubsection @code{env}: legacy syntax.
Up to version 1.3 @command{pies} implemented the one-line variant of
the @code{env} statement.  The use of this legacy syntax is
discouraged.  It is supported for backward compatibility only and will
be removed in future versions.  This subsection describes the legacy
syntax.

@deffn {legacy syntax} env @var{args}
Set program environment.

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

@table @asis
@item - (a dash)
Clear the environment.  This is understood only when used as a first
word in @var{args}.

The modern syntax equivalent is:

@example
@group
env @{
  clear;
@}
@end group
@end example

@item -@var{name}
Unset the environment variable @var{name}.  The modern syntax
equivalent is

@example
@group
env @{
  unset @var{name};
@}
@end group
@end example

@item -@var{name}=@var{val}
Unset the environment variable @var{name} only if its value is @var{val}.
The modern syntax equivalent is:

@example
@group
env @{
  unset "@var{name}=@var{val}";
@}
@end group
@end example

@item @var{name}
Retain the environment variable @var{name}.  The modern syntax
equivalent is

@example
@group
env @{
  keep @var{name};
@}
@end group
@end example

@item @var{name}=@var{value}
Define environment variable @var{name} to have given @var{value}.  The
modern syntax equivalent is:

@example
@group
env @{
  keep "@var{name}=@var{value}";
@}
@end group
@end example

@item @var{name}+=@var{value}
Retain variable @var{name} and append @var{value} to its existing
value.  If no such variable is present in the environment, it is
created and @var{value} is assigned to it.  However, if @var{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 @env{PATH}, e.g.:

@example
PATH+=:/sbin
@end example

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

In modern syntax, use shell variable references, e.g.:

@example
@group
env @{
  set "PATH=$@{PATH@}$@{PATH:+:@}/sbin";
@}
@end group
@end example

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

In modern syntax, use shell variable references, e.g. instead of
doing

@example
env PATH=+/sbin:
@end example

@noindent
use

@example
@group
env @{
  set "PATH=/sbin$@{PATH:+:@}$PATH";
@}
@end group
@end example

@end table
@end deffn

@node Early Environment Expansion
@subsection Early Environment Expansion

  By default any references to environment variables encountered in
the @code{command} statement are not expanded.  If you need to expand
them, there are two @dfn{flags} (@pxref{flags}) at your disposal:
@samp{shell} and @samp{expandenv}.

@kwindex shell
The @samp{shell} flag instructs @command{pies} to pass the command
line specified by the the @code{command} statement as the argument to
the @samp{/bin/sh -c} command (or another shell, if specified by the
@samp{program} statement).  This naturally causes all references to the
environment variables to be expanded, as in shell.  The overhead is
that two processes are run instead of the one: first the shell and
second the command itself, being run as its child.  This overhead
can be eliminated by using the @code{exec} statement before the
command, to instruct the shell to replace itself with the command
without creating a new process.

  Use this flag if the command you use in the component definition
is a shell built-in, a pipe or another complex shell statement.

@kwindex expandenv
  Another way to expand environment variables in the command line is by
specifying the @samp{expandenv} flag.  This flag instructs
@command{pies} to expand any variable references the same way that the
Bourne shell would expand them, but without actually invoking the
shell.

  A variable reference has the form @samp{$@var{variable}} or
@samp{$@{@var{variable}@}}, where @var{variable} is the variable
name.  The two forms are entirely equivalent.  The form with curly
braces is normally used if the variable name is immediately followed
by an alphanumeric symbol, which will otherwise be considered part of it.
This form also allows for specifying the action to take if the
variable is undefined or expands to an empty value:

@table @asis
@item $@{@var{variable}:-@var{word}@}
@dfn{Use Default Values}.  If @var{variable} is unset or null, the expansion
of @var{word} is  substituted.   Otherwise, the value of @var{variable} is
substituted.

@item $@{@var{variable}:=@var{word}@}
@dfn{Assign Default Values}.  If @var{variable} is unset or null, the
expansion  of @var{word} is assigned to variable.  The value of
@var{variable} is then substituted.

@item $@{@var{variable}:?@var{word}@}
@dfn{Display Error if Null or Unset}.  If @var{variable} is null or unset,
the expansion of @var{word} (or a message to that effect if @var{word} is
not present) is output to the current logging channel.  Otherwise, the
value of @var{variable} is substituted.

@item $@{@var{variable}:+@var{word}@}
@dfn{Use Alternate Value}.  If @var{variable} is null or unset, nothing is
substituted, otherwise the expansion of @var{word} is substituted.
@end table

  When the two flags are used together, the preference is given to
@samp{shell}, and a warning message to that effect is issued.

  Also, please note, that whichever option you chose the environment
variables available for expansion are those inherited by the parent
shell and modified by the @code{env} statement (@pxref{Environment}).

@node Actions Before Startup
@subsection Actions Before Startup

  The statements described in this subsection specify actions to perform
immediately before starting the component:

@deffn {Config: component} chdir @var{dir}
Change to the directory @var{dir}.
@end deffn

@deffn {Config: component} remove-file @var{file-name}
Remove @var{file-name}.  This is useful, for example, to remove stale
@acronym{UNIX} sockets or pid-files, which may otherwise prevent the
component from starting normally.

As of version @value{VERSION} only one @command{remove-file} may be given.
@end deffn

@deffn {Config: component} pass-fd-timeout @var{number}
Wait @var{number} of seconds for the @samp{pass-fd} socket
to become available (@pxref{Meta1-Style Components}).  Default is
5 seconds.
@end deffn

@node Exit Actions
@subsection Exit Actions
@kwindex return-code
  The default behavior of @command{pies} when a @samp{respawn}
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
@code{return-code} statement:

@deffn {Config: component} return-code
@example
return-code @var{codes} @{
  @dots{}
@}
@end example
@end deffn

  The @var{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:

@float Table, exit-codes
@caption{Standard Exit Codes}
@multitable @columnfractions 0.5 0.3
@headitem Name       @tab Numeric value
@item EX_OK          @tab 0
@item EX_USAGE       @tab 64
@item EX_DATAERR     @tab 65
@item EX_NOINPUT     @tab 66
@item EX_NOUSER      @tab 67
@item EX_NOHOST      @tab 68
@item EX_UNAVAILABLE @tab 69
@item EX_SOFTWARE    @tab 70
@item EX_OSERR       @tab 71
@item EX_OSFILE      @tab 72
@item EX_CANTCREAT   @tab 73
@item EX_IOERR       @tab 74
@item EX_TEMPFAIL    @tab 75
@item EX_PROTOCOL    @tab 76
@item EX_NOPERM      @tab 77
@item EX_CONFIG      @tab 78
@end multitable
@end float

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

  Each element in the list can be prefixed with @samp{!} to revert
the sense of matching.  Thus, e.g. @samp{!0} would match any status
code except 0 and @samp{!SIGHUP} would match any signal other than
@code{SIGHUP}.  If such a negated element yields true, the result is
saved and matching continues from the next element.  If any subsequent
element evaluates to false, false is returned.  Otherwise, the saved
return value (true) will be returned as the final result when the list
is exhausted.  For example, the following list:

@example
(!0, !SIGHUP, !SIGQUIT)
@end example

@noindent
will match if the program exits with any status, except 0 or if it is
terminated with any signal, except @code{SIGHUP} and @code{SIGQUIT}.

  Empty list or @samp{*} in its place matches any exit status and
any signal number.

  If the component exits with an exit code or is terminated on a
signal that matches @var{codes}, @command{pies} executes actions
specified in that @samp{return-code} block.  The actions are executed
in the order of their appearance below:

@deffn {Config: return-code} exec @var{command}
Execute the supplied external command.  Prior to execution, all
file descriptors are closed.  The @var{command} inherits the
environment from the main @command{pies} process with the following
additional variables:

@table @env
@item PIES_VERSION
The @command{pies} version number (@value{VERSION}).

@item PIES_MASTER_PID
PID of the master @command{pies} process.

@item PIES_COMPONENT
Tag of the terminated component (@pxref{Component Statement, tag}).

@item PIES_PID
PID of the terminated component.

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

@item PIES_STATUS
Program exit code.
@end table
@end deffn

@deffn {Config: return-code} action @samp{disable | restart}
If @samp{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.
@end deffn

@deffn {Config: return-code} notify @var{email-string}
Send an email notification to addresses in @var{email-string}.
@xref{Notification}, for a detailed discussion of this feature.
@end deffn

@deffn {Config: return-code} message @var{string}
Supply notification message text to use by @code{notify} statement.
@xref{Notification}, for a detailed discussion of this feature.
@end deffn

  Any number of @code{return-code} statements are allowed, provided
that their @var{codes} do not intersect.

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

@node Output Redirectors
@subsection Output Redirectors
@cindex repeater
  Following configuration statements instruct @command{pies} to
redirect standard error and/or standard output of a component to a
file or @command{syslog} facility.

@deffn {Config: component} stderr @var{type} @var{channel}
@deffnx {Config: component} stdout @var{type} @var{channel}
Redirect standard error (if @code{stderr}) or standard output (if
@code{stdout}) to the given channel.

The type of redirection is specified by @var{type} argument:

@table @code
@item file
Redirect to a file.  In this case @var{channel} gives the full name of
the file.  For example:

@example
stderr file /var/log/component/name.err;
@end example

@item syslog
Redirect to syslog.  The @var{channel} parameter is either the syslog
facility and priority separated by dot or the priority alone, in which
case the facility will be taken from the @code{syslog} statement
(@pxref{syslog}).

Example:

@example
stdout syslog local1.info;
stderr syslog err;
@end example

Valid facilities are: @samp{user}, @samp{daemon},
@samp{auth}, @samp{authpriv}, @samp{mail}, @samp{cron}, @samp{local0}
through @samp{local7} (all names case-insensitive).

Valid priorities are: @samp{emerg}, @samp{alert}, @samp{crit},
@samp{err}, @samp{warning}, @samp{notice}, @samp{info}, @samp{debug}.
@end table
@end deffn

@cindex ANSI escapes
By default, anything that appears on the standard stream being
redirected is sent to the configured output channel verbatim.  This
can cause problems if the program run by a component outputs text
with ANSI escape sequences.  When sent to syslog, the control
characters are translated to ASCII, and the result only worsens
readability of the content.

@kwindex deansify
To avoid this, use the @code{deansify} flag (@pxref{flags}).  It
instructs @command{pies} to remove ANSI escape sequences from the text
before redirecting it.

@node Inetd-Style Components
@subsection Inetd-Style Components
@cindex inetd-style components
  Inetd-style components are declared using @code{mode inetd}
statement.  The @samp{component} declaration must contain a
@samp{socket} statement:

@anchor{inetd-socket}
@deffn {Config: component} socket @var{url}
Define a socket to listen on.  Allowed values for @var{url} are:

@table @asis
@flindex /etc/protocols
@item inet[+@var{proto}]://@var{ip}:@var{port}
Listen on IPv4@footnote{Support for IPv6 will be added in future
versions.} address @var{ip} (may be given as a symbolic host name),
on port @var{port}.  Optional @var{proto} defines the protocol
to use.  It must be a valid protocol name as given in
@file{/etc/protocols}.  Default is @samp{tcp}.

@item local[+@var{proto}]://@var{file}[;@var{args}]
@itemx file[+@var{proto}]://@var{file}[;@var{args}]
@itemx unix[+@var{proto}]://@var{file}[;@var{args}]
Listen on the @acronym{UNIX} socket file @var{file}, which is either
an absolute or relative file name, as described above.  The
@var{proto} part is as described above.  Optional arguments, @var{args},
control ownership and file mode of @var{file}.  They are a list of
assignments, separated by semicolons.  The following values are
allowed:

@table @code
@item user
User name of the socket owner.

@item group
Owner group of the socket, if it differs from the @code{user} group.

@item mode
Socket file mode (octal number between @samp{0} and @samp{777}).

@item umask
Umask to use when creating the socket (octal number between @samp{0}
and @samp{777}).
@end table

For example:

@example
socket
 "unix:///var/run/socket;user=nobody;group=mail;mode=770";
@end example

The @var{file} part may be a relative file name,
provided that the @code{chdir} statement is used for this component
(@pxref{Actions Before Startup, chdir}).

@ignore
@item file name
Specifies a @acronym{UNIX} socket file name.  It is a shortcut for
@samp{unix:@var{file-name}}.  You may use a relative file name,
provided that @code{chdir} statement is used for this component
(@pxref{Actions Before Startup, chdir}).
@end ignore

@end table
@end deffn

@anchor{socket-type}
@deffn {Config: component} socket-type @var{type}
Sets the socket type.  Allowed values for @var{type} are:
@samp{stream}, @samp{dgram}, @samp{raw}, @samp{rdm},
@samp{seqpacket}.  Default is @samp{stream}.  Notice that
some socket types may not be implemented by all protocol
families, e.g.@: @samp{seqpacket} is not implemented for
@samp{inet}.
@end deffn

@anchor{max-rate}
@deffn {Config: component} max-rate @var{n}
Specifies the maximum number of times the component can be invoked in
one minute; the default is unlimited.  A rate of @samp{0} stands for
@samp{unlimited}.
@end deffn

@deffn {Config: component} max-instances @var{n}
Sets the maximum number of simultaneously running instances of this
component.  It is equivalent to the maximum number of simultaneously
opened connections.
@end deffn

@deffn {Config: component} max-instances-message @var{text}
Text to send back if @code{max-instances} is reached.  This is valid
only for TCP sockets.
@end deffn

@deffn {Config: component} max-ip-connections @var{number}
Maximum number of connections that can be opened simultaneously from a
single IP address.
@end deffn

@deffn {Config: component} max-ip-connections-message @var{text}
Textual message to send in reply to an incoming TCP connection from the IP
address that has already reached @code{max-ip-connections} limit.
@end deffn

@deffn {Config: component} acl @{ @dots{} @}
Set access control list for this component.  This is valid only for
@samp{inetd} and @samp{accept} components.  @xref{ACL}, for a
detailed description of access control lists.
@end deffn

@deffn {Config: component} access-denied-message @var{text}
Textual message to send in reply to an incoming TCP connection that
has been denied by ACL settings.
@end deffn

@menu
* builtin::    Built-in Inetd Services
* TCPMUX::     TCPMUX Services
* sockenv::    Socket Environment Variables
* inetd exit:: Exit Actions in Inetd Components
@end menu

@node builtin
@subsubsection Built-in Inetd Services
@cindex builtin services
@cindex internal services
@dfn{Built-in} or @dfn{internal} services are such inetd-style
components that are supported internally by @command{pies} and do not
require external programs.  In @command{pies} version @value{VERSION}
those are:

@table @code
@cindex echo
@item echo
Send back any received data.  Defined in @RFC{862}.
@cindex discard
@item discard
Read the data and discard them.  Defined in @RFC{863}.
@cindex time
@item time
Return a machine readable date and time as seconds since the Epoch.
Defined in @RFC{868}.
@cindex daytime
@item daytime
Return current date and time in human-readable format.  Defined in
@RFC{867}.
@cindex chargen
@item chargen
Send a continuous stream of ASCII printable characters without regard
to the input.  Defined in @RFC{864}
@cindex qotd
@item qotd
Send a @samp{quotation of the day} text without regard
to the input.  Defined in @RFC{865}.
@cindex tcpmux
@item tcpmux
TCP Port Service Multiplexer.  Defined in @RFC{1078}.
@end table

@cindex @code{internal} flag
A definition of a built-in service component must
have the @code{internal} flag (@pxref{flags}) set.  It may not contain
@code{command} or @code{program} statements, as built-in services do
not need external programs.  Instead, a @dfn{service} declaration must
be present:

@deffn {Config: component} service @var{name}
Set the built-in service name.  Its argument is one of the keywords
listed in the above table.
@end deffn

  For example, the following component declaration defines a standard
TCP-based echo service:

@example
@group
component echo @{
        socket "inet://0.0.0.0:echo";
        service echo;
        flags internal;
@}
@end group
@end example

  It corresponds to the following @file{inetd.conf} line:

@example
echo stream  tcp     nowait  root    internal
@end example

  Another built-in services are defined in the same manner, replacing
@samp{echo} in the @code{service} field with the corresponding service
name.

@anchor{qotd}
  The @samp{qotd} service reads the contents of the @dfn{qotd file}
and sends it back to the client.  By default the @samp{qotd} file
is located in the local state directory and named
@file{@var{instance}.qotd} (where @var{instance} is the name of the
@command{pies} instance; @pxref{instances}).  This default location
can be changed using the following statement:

@deffn {Config} qotd-file @var{file-name}
Set the name of the @samp{quotation-of-the-day} file.
@end deffn

  The text read from the @samp{qotd} file is preprocessed, by
replacing each @acronym{LF} character (@acronym{ASCII} 10) with two
characters: @acronym{CR} (@acronym{ASCII} 13) followed by
@acronym{LF}.  The resulting text is truncated to 512 characters.

  The use of @samp{tcpmux} services is covered below.

@node TCPMUX
@subsubsection TCPMUX Services
@cindex TCPMUX

  TCPMUX allows to use multiple services on a single well-known TCP
port using a service name instead of a well-known number.  It is
defined in @RFC{1078}.  The protocol operation is as follows.
The @dfn{master} TCPMUX component listens on a certain TCP port
(usually on port 1) for incoming requests.  After connecting to the
master, the client sends the name of the service it wants, followed
by a carriage-return line-feed (@acronym{CRLF}).  @command{Pies}
looks up this name in the list of services handled by the master
(@dfn{subordinate services}) and reports with @samp{+} or @samp{-}
followed by optional text and terminated with the @acronym{CRLF},
depending on whether such service name is found or not.  If the reply
was @samp{+}, @command{pies} then starts the requested component.
Otherwise, it closes the connection.

  TCPMUX service names are case-insensitive.  The special service
@samp{help} is always defined; it outputs a list of all the
subordinate services, one name per line, and closes the connection.

  The master TCPMUX service is declared as a usual built-in service,
e.g.:

@example
component tcpmux-master @{
        socket "inet://0.0.0.0:1";
        service tcpmux;
        flags internal;
@}
@end example

  Any number of subordinate services may be defined for each master.
A subordinate server component definition must contain at least the
following statements:

@deffn {Config: component} service @var{name}
Sets the name of the subordinate service.  The @var{name} will be compared
with the first input line from the client.
@end deffn

@deffn {Config: component} tcpmux-master @var{name}
Sets the name of the master TCPMUX service.
@end deffn

@deffn {Config: component} flags @var{list}
The @code{flags} statement (@pxref{flags}) must contain at least one
of the following flags:

@table @code
@item tcpmux
A ``dedicated'' TCPMUX subordinate service.  When invoked, it must
output the @samp{+ CRLF} response itself.

@item tcpmuxplus
Simple service.  Before starting it, @command{pies} will send the
@samp{+ CRLF} reply.
@end table
@end deffn

@deffn {Config: component} command @var{command-line}
The command line for handling this service.
@end deffn

  For example:

@example
component scp-to @{
        service scp-to;
        flags (tcpmuxplus, sockenv);
        tcpmux-master tcpmux;
        command "/usr/sbin/in.wydawca";
@}
@end example

@cindex ACL in TCPMUX services
  For TCPMUX services, access control lists are handled in the
following order.  First, the global @acronym{ACL} is checked.
If it rejects the connection, no further checks are done.  Then,
if the master TCPMUX service has an @acronym{ACL}, that @acronym{ACL}
is consulted.  If it allows the connection, the subordinate is looked
up.  If found, its @acronym{ACL} (if any) is consulted.  Only if all
three @acronym{ACL}s allow the connection, is the service started.

  A similar procedure applies for other resources, such as
@code{limits}, @code{umask}, @code{env}, @code{user}, @code{group}, etc.

@node sockenv
@subsubsection Socket Environment Variables
@cindex socket environment variables
@kindex sockenv
  If the @samp{sockenv} flag is set (@pxref{flags, sockenv}), the
following environment variables are set prior to executing the
command:

@table @env
@item PROTO
Protocol name.

@item SOCKTYPE
Socket type.  @xref{socket-type}, for a list of possible
values.

@item LOCALIP
IP address of the server which is handling the connection.

@item LOCALPORT
Local port number.

@item LOCALHOST
Host name of the server.  This variable is defined only if
the @samp{resolve} flag is set (@pxref{flags,resolve}).

@item REMOTEIP
IP address of the remote party (client).

@item REMOTEPORT
Port number on the remote side.

@item REMOTEHOST
Host name of the client.  This variable is defined only if
the @samp{resolve} flag is set (@pxref{flags,resolve}).
@end table

  The variables whose names begin with @env{REMOTE} are defined only
for @acronym{TCP} connections.

@node inetd exit
@subsubsection Exit Actions in Inetd Components

  Exit actions (@pxref{Exit Actions}) work for @samp{inet-style} components.
The only difference from @samp{respawn} components is that the
@samp{restart} action is essentially ignored, as it makes no sense to
start an @samp{inet-style} component without a communication socket.

  A common use of @code{return-code} statement is to invoke an
external program upon the termination of a component.  For example,
the following configuration snippet configures an @acronym{FTP} server
and ensures that a special program is invoked after closing each
@acronym{FTP} connection:

@example
component ftp @{
    return-code EX_OK @{
        exec "/sbin/sweeper --log";
    @}
    mode inetd;
    socket "inet://0.0.0.0:21";
    umask 027;
    program /usr/sbin/in.ftpd
    command "ftpd -ll -C -t180";
@}
@end example

  This approach may be used to process @command{FTP} uploads in real time.

@node Meta1-Style Components
@subsection Meta1-Style Components
@cindex meta1-style components
  Meta1-style components are declared using @code{mode pass}
statement.  For such components, you must declare both a socket to
listen on (@pxref{inetd-socket} and a @acronym{UNIX} socket name to
pass the file descriptor to the component.  The latter is defined
using @code{pass-fd-socket} statement:

@deffn {Config: component} pass-fd-socket @var{file-name}
The argument is an absolute or relative file name of the socket file.
In the latter case, the @code{chdir @var{dir}} statement must be used
for this component (@pxref{Actions Before Startup, chdir}), and the
socket will be looked under @var{dir}.

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

@node Visibility
@subsection Component Visibility ACLs

  Pies control interface allows certain users to list and modify
components of a running @command{pies} instance.  Two access control
lists define who can list and modify the particular component.

@deffn {Config: component} list-acl @var{name}
@deffnx {Config: component} list-acl @{ @dots{} @}
This list controls who can get listing of this component
(@pxref{piesctl list}).

In the first form, @var{name} refers to the name of an already defined
global ACL (@pxref{defacl}).

The second form defines new unnamed ACL.  The syntax is described in
detail in @ref{ACL}.
@end deffn

@deffn {Config: component} admin-acl @var{name}
@deffnx {Config: component} admin-acl @{ @dots{} @}
This list controls who can stop, restart or otherwise modify this
component (@pxref{components}).

As above, two forms are available: the first one for using an already
defined named ACL, and the second one, for defining a new ACL in place.
@end deffn

@node Component Syntax Summary
@subsection Component Syntax Summary
  This subsection summarizes the @code{component} statements.  For each
statement, a reference to its detailed description is provided.

@example
component @var{tag} @{
  # @r{Component execution mode.}
  # @xref{Component Statement, mode}.
  mode @var{modename};

  # @r{Full name of the program.}
  # @xref{Component Statement, program}.
  program @var{name};
  # @r{Command line.}
  # @xref{Component Statement, command}.
  command @var{string};

  # @r{List of prerequisites.}
  # @xref{Prerequisites}.
  prerequisites (@var{compnames});
  # @r{List of components for which this one is a prerequisite.}
  # @xref{Prerequisites, dependents}.
  dependents (@var{compnames});

  # @r{List of flags.}
  # @xref{flags}.
  flags (@var{flags});

  # @r{For @i{init} components: runlevels in which to start this}
  # @r{component.}
  # @xref{Runlevels}.
  runlevels @var{string};

  # @r{Listen on the given url.}
  # @xref{Inetd-Style Components}.
  socket @var{url};

  # @r{Set socket type.}
  # @xref{Inetd-Style Components}.
  socket-type @samp{stream | dgram | raw | rdm | seqpacket};

  # @r{Service name for built-in inetd component.}
  # @xref{builtin}.
  service @var{string};

  # @r{Tag of master TCPMUX component, for subordinate components}.
  # @xref{TCPMUX}.
  tcpmux-master @var{string};

  # @r{Pass fd through this socket.}
  # @xref{Meta1-Style Components}.
  pass-fd-socket @var{soket-name};
  # @r{Wait @var{number} of seconds for pass-fd socket to become available.}
  # @xref{Actions Before Startup, pass-fd-timeout}.
  pass-fd-timeout @var{number};

  # @r{Maximum number of running instances.}
  # @xref{Resources, max-instances}.
  # @xref{Inetd-Style Components, max-instances}.
  max-instances @var{number};

  # @r{For @samp{inetd} components:}
  # @r{Text to send back if @code{max-instances} is reached.}
  # @xref{Inetd-Style Components, max-instances-message}.
  max-instances-message @var{text};

  # @r{Maximum number of times an inetd component can be invoked in}
  # @r{one minute.}
  # @xref{Inetd-Style Components, max-rate}.
  max-rate @var{number};

  # @r{For @samp{inetd} components:}
  # @r{Max. number of simultaneous connections from a single IP address.}
  # @xref{Inetd-Style Components, max-ip-connections}.
  max-ip-connections @var{number};

  # @r{For @samp{inetd} components:}
  # @r{Text to send back if @code{max-ip-connections} is reached.}
  # @xref{Inetd-Style Components, max-ip-connections-message}.
  max-ip-connections-message @var{text};

  # @r{For @samp{inetd} components:}
  # @r{Text to send back if access is denied by ACL.}
  # @xref{Inetd-Style Components, access-denied-message}.
  access-denied-message @var{text};

  # @r{ACL for administrative (read-write) access to this component.}
  # @xref{Visibility}.
  admin-acl @var{name};
  # @r{or:}
  admin-acl @{ @dots{} @}

  # @r{ACL for read-only access to this component.}
  # @xref{Visibility}.
  list-acl @var{name};
  # @r{or:}
  list-acl @{ @dots{} @}

  # @r{ACL for this component.}
  # @xref{ACL}.
  acl @var{name};
  # @r{or:}
  acl @{ @dots{} @}

  # @r{Redirect program's standard output to the given}
  # @r{file or syslog priority.}
  # @xref{Output Redirectors}.
  stdout @samp{file | syslog} @var{channel};
  # @r{Redirect program's standard error to the given}
  # @r{file or syslog priority.}
  # @xref{Output Redirectors}.
  stderr @samp{file | syslog} @var{channel};

  # @r{Run with this user privileges.}
  # @xref{Component Privileges}.
  user @var{user-name};
  # @r{Retain supplementary group.}
  # @xref{Component Privileges, group}.
  group @var{group-name};
  # @r{Retain all supplementary groups of which user is a member.}
  # @xref{Component Privileges, allgroups}.
  allgroups @var{bool};

  # @r{Set system limits.}
  # @xref{Resources}.
  limits @var{string};

  # @r{Force this umask.}
  # @xref{Resources, umask}.
  umask @var{number};

  # @r{Set program environment.}
  # @xref{Environment}.
  env @{ @dots{} @}

  # @r{Change to this directory before executing the component.}
  # @xref{Actions Before Startup, chdir}.
  chdir @var{dir};
  # @r{Remove @var{file-name} before starting the component.}
  # @xref{Actions Before Startup, remove-file}.
  remove-file @var{file-name};

  # @r{Actions:}
  # @xref{Exit Actions}.
  return-code @var{exit-code-list} @{
    # @r{Action to take when a component finishes with this return code.}
    action @samp{disable | restart};
    # @r{Notify these addresses when then component terminates.}
    notify @var{email-string};
    # @r{Notification message text (with headers).}
    message @var{string};
    # @r{Execute this command.}
    exec @var{command}
  @}
@}
@end example

@node Notification
@section Notification
@cindex Notification

  Pies provides a @dfn{notification} mechanism, which can be used to
send email messages when components terminate.  The exact contents
of such notifications and the list of their recipients may depend on
the exit code which the component returned.  Notification is
configured by @samp{notify} and @samp{message} statements
in a @samp{return-code} block.

@deffn {Config: return-code} notify @var{email-string}
Send email notification to each address from @var{email-string}.  The
latter is a comma-separated list of email addresses, e.g.:

@example
notify "root@@localhost,postmaster@@localhost";
@end example
@end deffn

@deffn {Config: return-code} message @var{string}
Supply the email message text to be sent.  @var{String} must be a
valid RFC 822 message, i.e. it must begin with message headers,
followed by an empty line and the actual message body.

The message may contain variable data in the form of
variable references.  A @dfn{variable} is an entity that holds
some data describing the event that occurred.  Meta-variables
are referenced using the following construct:

@example
$@{@var{name}@}
@end example

@noindent
where @var{name} is the name of the variable.  Before actually sending
the message, each occurrence of this construct is removed from the
text and replaced by the actual value of the referenced variable.
For example, the variables @samp{component} and @samp{retcode} expand
to the name of the exited component and its exit code, correspondingly.
Supposing that @samp{component} is @samp{ftpd} and @samp{retcode} is
76, the following fragment:

@example
Subject: $@{component@} exited with code $@{retcode@}
@end example

@noindent
will become:

@example
Subject: ftpd exited with code 76
@end example

The table below lists all available variables and their expansions:

@float Table, notification-variables
@caption{Notification Variables}
@multitable @columnfractions 0.5 0.5
@headitem Variable @tab Expansion
@item @code{canonical_program_name} @tab @samp{pies}
@item @code{program_name} @tab Program name of the @command{pies} binary.
@item @code{package}      @tab Package name (@samp{GNU Pies}).
@item @code{instance}     @tab Instance name (@pxref{instances}).
@item @code{version}      @tab Package version (@value{VERSION}).
@item @code{component}    @tab Name of the terminated component.
@item @code{termination}  @tab Termination cause (see below).
@item @code{retcode}      @tab Component exit code (or signal number, if exited
on signal), in decimal.
@end multitable
@end float

The @samp{termination} variable is set so as to facilitate its use
with the @samp{retcode} variable.  Namely, its value is @samp{exited
with}, if the component exited and @samp{terminated on signal}, if it
terminated on a signal.  Thus, using

@example
$@{termination@} $@{retcode@}
@end example

@noindent
results in a correct English sentence.  This message, however, cannot
be properly internationalized.  This will be fixed in the future
versions.

If @code{message} statement is not given, the following default
message is used instead:

@example
From: <>
X-Agent: $@{canonical_program_name@} ($@{package@} $@{version@})
Subject: Component $@{component@} $@{termination@} $@{retcode@}.

@end example
@end deffn

@cindex mailer
@cindex @command{sendmail}
  Notification messages are sent using an external program, called
@dfn{mailer}.  By default it is @command{/usr/sbin/sendmail}.  You can
change it using the following configuration statement:

@deffn {Config} mailer-program @var{prog}
Use @var{prog} as a mailer program.  The mailer must meet the
following requirements:

@enumerate 1
@item It must read the message from its standard input.
@item It must treat the non-optional arguments in its command line as
recipient addresses.
@end enumerate

For example, the following statement instructs @command{pies} to use
@command{exim} as a mailer:

@example
mailer-program /usr/sbin/exim;
@end example

@end deffn

By default, the mailer program is invoked as follows:

@example
/usr/sbin/sendmail -oi -t @var{rcpts}
@end example

@noindent
where @var{rcpts} is a whitespace-separated list of addresses supplied
in the @samp{notify} statement.

The mailer command may be altered using @samp{mailer-command-line} statement:

@deffn {Config} mailer-command-line @var{string}
Set mailer command line.  Notice, that @var{string} must include the
command name as well.  The @samp{mailer-program} statement supplies
the full name of the binary which will be executed, while the first word
from the @samp{mailer-command-line} argument gives the string it
receives as @samp{argv[0]}.

  The example below shows how to use this statement to alter the
envelope sender address:

@example
mailer-command-line "sendmail -f root@@domain.com -oi -t";
@end example
@end deffn

@node ACL
@section Access Control Lists
@cindex @acronym{ACL}
@cindex access control lists
@dfn{Access control lists}, or @acronym{ACL}s for short, are lists of
permissions that control access to @samp{inetd}, @samp{accept} and
@samp{meta1}-style components.

An @acronym{ACL} is defined using @code{acl} block statement:

@deffn {Config} acl
@example
acl @{
  @var{definitions}
@}
@end example
@end deffn

  This statement is allowed both in global context and within a
@samp{component} block.  If both are present, the global-level
@acronym{ACL} is consulted first, and if it allows access, the
component @acronym{ACL} is consulted.  As a result, access is
granted only if both lists allow it.

@anchor{defacl}
  A @dfn{named @acronym{ACL}} is an access control list which is
assigned its own name.  Named @acronym{ACL}s are defined using
the @samp{defacl} statement:

@deffn {Config} defacl @var{name}
@example
defacl @var{name} @{
  @var{definitions}
@}
@end example

  The @var{name} parameter specifies a unique name for that
@acronym{ACL}.  Named @acronym{ACL}s are applied only if
referenced from another @acronym{ACL} (either global or a
per-component one, or any named @acronym{ACL}, referenced
from these).  @xref{acl-ref, ACL references}, below.
@end deffn

  In both forms, the part between the curly braces (denoted by
@var{definitions}), is a list of @dfn{access control statements}.
There are two types of such statements:

@deffn {Config: acl} allow [@var{user-group}] @var{sub-acl} @var{host-list}
@deffnx {Config: acl} allow any
Allow access to the component.
@end deffn
@ignore
@deffn {Config: defacl} allow [@var{user-group}] @var{sub-acl} @var{host-list}
@end deffn
@end ignore

@deffn {Config: acl} deny [@var{user-group}] @var{sub-acl} @var{host-list}
@deffnx {Config: acl} deny any
Deny access to the component.
@end deffn
@ignore
@deffn {Config: defacl} deny [@var{user-group}] @var{sub-acl} @var{host-list}
@end deffn
@end ignore

All parts of an access statement are optional, but at least one
of them must be present.  The @var{user-group} part is reserved for
future use and is described in more detail in @ref{User-Group ACLs}.

@anchor{acl-ref}
The @var{sub-acl} part, if present, allows to branch to another
@acronym{ACL}.  The syntax of this part is:

@example
acl @var{name}
@end example

@noindent
where @var{name} is the name of an @acronym{ACL} defined previously in
@samp{defacl} statement.

The @var{host-list} group allows to match client addresses.
It consists of the @code{from} keyword followed by a list of
@dfn{address specifiers}.  Allowed address specifiers are:

@table @asis
@item @var{addr}
Matches if the client @acronym{IP} equals @var{addr}.
The latter may be given either as an @acronym{IP}
address or as a host name, in which case it will be resolved and the
first of its @acronym{IP} addresses will be used.

@item @var{addr}/@var{netlen}
Matches if first @var{netlen} bits from the client @acronym{IP}
address equal to @var{addr}.  The network mask length, @var{netlen},
must be an integer number in the range from 0 to 32.  The address part,
@var{addr}, is as described above.

@item @var{addr}/@var{netmask}
The specifier matches if the result of logical @acronym{AND} between
the client @acronym{IP} address and @var{netmask} equals to
@var{addr}.  The network mask must be specified in ``dotted quad''
form, e.g.@: @samp{255.255.255.224}.

@item @var{filename}
Matches if connection was received from a @acronym{UNIX} socket
@var{filename}, which must be given as an absolute file name.
@end table

@anchor{acl-any}
The special form @samp{allow any} means to allow access
unconditionally.  Similarly, @samp{deny any}, denies access
unconditionally.  Normally, one of these forms appears as the last
statement in an @acronym{ACL} definition.

To summarize, the syntax of an access statement is:

@example
allow|deny [acl @var{name}] [from @var{addr-list}]
@end example

@noindent
where square brackets denote optional parts.

When an @acronym{ACL} is checked, its entries are tried in turn until
one of them matches, or the end of the list is reached.  If a matched
entry is found, its command verb, @code{allow} or @code{deny}, defines
the result of the @acronym{ACL} check.  If the end of the list is reached,
the result is @samp{allow}, unless explicitly specified otherwise
(using the @ref{acl-any, ``any'' form}.)

For example, the following @acronym{ACL} allows access for anybody
coming from networks @samp{192.168.10.0/24} and @samp{192.168.100.0/24},
or any connection that matches the named @acronym{ACL} @samp{my-nets}
(which is defined elsewhere in the configuration file).  Access is
denied for anybody else:

@example
@group
acl @{
    allow from (192.168.10.0/24, 192.168.100.0/24);
    allow acl "my-nets";
    deny all;
@}
@end group
@end example

@node control
@section The Control Statement

  The @dfn{control interface} provides a method for communication with
the running @command{pies} instance.  It is used by the
@command{piesctl} utility to query information about the instance and
components it is currently running and to send it commands for
controlling its operation (@pxref{piesctl}).  By default the UNIX
socket @file{/tmp/pies.ctl} is used for this purpose.  If
@command{pies} was started with the @option{--instance=@var{name}}
option, the socket is named @file{/tmp/@var{name}.ctl}.  Whatever its
name, the socket will be owned by the user @command{pies} runs as
(@pxref{Pies Privileges}) and will have access rights of 0500,
allowing only that user to read and write to it.  When @command{pies}
is used as init process, the default socket name is @file{/dev/init.ctl}.

@deffn {Config} control
  The @samp{control} statement configures the control interface and
limits access to it:

@example
@group
control @{
    socket @var{url};
    acl @{ @dots{} @}
    admin-acl @{ @dots{} @}
    user-acl @{ @dots{} @}
    realm @var{name};
@}
@end group
@end example
@end deffn

@deffn {Config: control} socket @var{url}
URL of the control socket.  The @var{url} argument is a string of the
following syntax:

@table @asis
@item inet://@var{ip}:@var{port}
Listen on IPv4 address @var{ip} (may be given as a symbolic host name),
on port @var{port}.

@item local://@var{file}[;@var{args}]
@itemx file://@var{file}[;@var{args}]
@itemx unix://@var{file}[;@var{args}]
Listen on the @acronym{UNIX} socket file @var{file}, which is either
an absolute or relative file name.  Optional arguments @var{args}
control ownership and file mode of @var{file}.  They are a
semicolon-separated list of assignments to the following variables:

@table @code
@item user
User name of the socket owner.

@item group
Owner group of the socket, if it differs from the @code{user} group.

@item mode
Socket file mode (octal number between @samp{0} and @samp{777}).

@item umask
Umask to use when creating the socket (octal number between @samp{0}
and @samp{777}).
@end table
@end table
@end deffn

@deffn {Config: control} idle-timeout @var{n}
  Disconnect any control session that remains inactive for @var{n}
seconds.  This statement is reserved for use in the future.  Currently
(as of version @value{VERSION}) it is a no-op.
@end deffn

  The control interface is protected by three access control lists
(@xref{ACL}, for a discussion of their syntax).

@deffn {Config: control} acl @var{name}
@deffnx {Config: control} acl @{ @dots{} @}
  Controls who can connect to the interface.  The first form refers to
a named ACL that must have been defined earlier by @code{defacl}
statement (@pxref{defacl}).  Use the second form to define a new ACL
in place.
@end deffn

@deffn {Config: control} user-acl @var{name}
@deffnx {Config: control} user-acl @{ @dots{} @}
  Control interface provides two kinds of operations: @dfn{read-only}
(such as getting information about running components) and @dfn{write}
operations (such as stopping or restarting components).

  The @code{user-acl} controls read access.  Access to particular
components can also be controlled individually, using the
per-component @code{list-acl} statement (@pxref{Visibility, list-acl}).
@end deffn

@deffn {Config: control} admin-acl @var{name}
@deffnx {Config: control} admin-acl @{ @dots{} @}
  Controls write access to the @command{pies} instance itself and to
the components for which no specific @code{admin-acl} statements are
supplied (@pxref{Visibility, admin-acl}).

  In particular, whoever passes @code{admin-acl} can issue commands
for stopping the instance and reloading its configuration.
@end deffn

  When checking whether the user has a particular kind of access to a
component, first the corresponding ACL from the @code{control} section
is checked.  If it allows access, then the per-component ACL is tried.
If it allows access too, then the operation is permitted.

@deffn {Config: control} realm @var{name}
  Defines the realm for basic authentication.  Default value is @samp{pies}.
@end deffn

@node Identities
@section User Identities for Accessing Control Interface

  Privileges for using and performing various commands over the
control interface can be distributed among several users.  For
example, it is possible to grant some users the rights to only view
the component listing, or even to further limit their rights to only
see the components they are authorized to know about.  Another user
may be able to stop or restart components and so on.  This privilege
separation requires @command{pies} to have a notion of user and be
able to authenticate it.

  @dfn{Identity provider} is an abstract mechanism that @command{pies}
uses to obtain information about the user trying to authenticate
himself for accessing a particular control function.  As of version
@value{VERSION}, this mechanism is considered experimental.  That
means, that although being fully functional, it can change
considerably in future releases.

  Identity provider supports two operations: authenticating a user,
and checking if he is a member of particular @dfn{group}.  It is
defined in the configuration file using the @code{identity provider}
statement.

@deffn {Config} identity-provider @var{name}
Defines an identity provider.  It is a block statement:

@example
identity-provider @var{name} @{
  type @var{type};
  @dots{}
@}

The provider @var{name} is used in diagnostic messages.
@end example

The only required substatement is @code{type}, which defines the type
of the provider.  Rest of statements (represented by @dots{} above)
depends on the type.
@end deffn

Pies version @value{VERSION} supports identity providers of two types:
@samp{system} and @samp{pam}.

The @samp{system} identity provider uses system user database for
authentication and system group database for checking group membership.
It is declared using the following statement:

@example
@group
identity-provider @var{name} @{
    type system;
@}
@end group
@end example

Obviously, to use the system identity provider for authentication,
@command{pies} must be run as root.

The @samp{pam} identity provider uses the Pluggable Authentication
Modules (@acronym{PAM}) for authentication, and system group database
for checking group membership.

@example
@group
identity-provider @var{name} @{
    type pam;
    service @var{srv};
@}
@end group
@end example

The @samp{service} statement defines the name of PAM service to use
for authentication.  If absent, the name @samp{pies} is used.

Any number of different identity providers can be declared in the
configuration file.  When authenticating the user, they will be tried
in turn until the one is found where authentication succeeds.
Subsequent group membership checks will then use this identity provider.

@node inetd
@section Using @command{inetd} Configuration Files
@cindex inetd.conf
@flindex /etc/inetd.conf
  In addition to its native configuration file format, GNU
@command{pies} is able to read configuration files of several other
widely-used utilities.  One of these is @command{inetd}.  The simplest
way to use such configuration files is by including them to your main
@file{pies.conf} using the @dfn{include-inetd} statement:

@deffn {Config} include-inetd @var{file}
Read components from @command{inetd}-style configuration file
@var{file}.  The argument may also be a directory, in which case
all regular files from that directory are read and parsed
as @command{inetd}-style configuration files.

The components read from @var{file} are appended to the @command{pies}
list of components in order of their appearance.

For example, the following statement reads components from the
standard @command{inetd} configuration file:

@example
include-inetd /etc/inetd.conf;
@end example

Any number of @code{include-inetd} may be specified.  For example, the
following reads the contents of the @file{/etc/inetd.conf}
configuration file and all files from the @file{/etc/inetd.d}
directory:

@example
include-inetd /etc/inetd.conf;
include-inetd /etc/inetd.d;
@end example
@end deffn

  Another way to read @command{inetd} configuration files is to supply
them in the command line, like this:

@example
pies --syntax=inetd --config-file /etc/inetd.conf
@end example

Notice the @option{--syntax} option (@pxref{config syntax}).  It
informs @command{pies} that the following files are in @command{inetd}
format.  Of course, several configuration file may be given:

@example
@group
pies --syntax=inetd \
     --config-file /etc/inetd.conf --config-file /etc/inetd.d
@end group
@end example

A special option is provided that instructs @command{pies} to behave
as @command{inetd}:

@table @option
@xopindex{inetd, described}
@item --inetd
Read configuration from @file{@var{sysconfdir}/inetd.conf} and make
sure @command{pies} state files (@pxref{State Files}) do not
conflict with those from other @command{pies} instances.
@end table

The GNU Pies package also provides a wrapper that allows to use
@command{pies} instead of @command{inetd}.  It is built if the package
is configured with the @option{--enable-inetd} option.  The wrapper
is then installed in @var{sbindir} as @file{inetd}, possibly replacing
the system binary of that name.

The command line usage of the @command{inetd} wrapper is entirely
compatible with that of the usual @command{inetd} utility, i.e.:

@example
inetd [@var{option}] [@var{config} [@var{config}...]] [-- @var{pies-options}]
@end example

Options are:

@table @option
@item -d
Increase debug level.
@item -R @var{rate}
Set maximum rate (@pxref{max-rate}).
@end table

For convenience, the following additional options are understood:

@table @option
@item -t
@itemx --lint
Parse configuration file or files and exit.  @xref{lint}.

@item -s
@itemx --status
Display info about the running instance.  @xref{pies-status}.

@item -S
@itemx --stop
Stop the running instance.
@end table

  Finally, any additional options @command{pies} understands may be
given to @command{inetd} after the @samp{--} separator.

@node include-meta1
@section Using MeTA1 Configuration File
@flindex /etc/meta1/meta1.conf
  MeTA1 is a mail transfer agent of new generation, designed
to replace Sendmail in the future (@uref{http://www.meta1.org}).
It has a modular structure, each module being a component
responsible for a particular task.  The components are configured in
the MeTA1 configuration file @file{/etc/meta1/meta1.conf}.

  @command{Pies} can take a list of components directly
from MeTA1 configuration file:

@deffn {Config} include-meta1 @var{file}
Parse @var{file} as MeTA1 configuration file and incorporate
components defined there into the current component list.

For example:

include-meta1 /etc/meta1/meta1.conf;
@end deffn

Thus, you can use @command{pies} instead of the default MeTA1 program
manager @command{mcp}.  This is particularly useful if you use
@samp{Mailfromd} (@uref{http://mailfromd.software.gnu.org.ua}) to
control the mail flow.

To ensure compatibility with MeTA1, the components read from its
configuration file are started in the reverse order (i.e. from last to
first), and stopped in the order of their appearance in @var{file}.

The following @command{pies} statements are silently applied to
all MeTA1 components:

@example
allgroups yes;
stderr file @var{compname}.log
chdir @var{queue-dir}
@end example

Here, @var{compname} stands for the name of the component, and
@var{queue-dir} stands for the name of MeTA1 queue directory.  The
latter is @file{/var/spool/meta1} by default.  It can be changed using
the following statement:

@deffn {Config} meta1-queue-dir @var{dir}
Set name of MeTA1 queue directory.
@end deffn

To override any default settings for a MeTA1 component, add a
@code{command} section with the desired settings after including
@file{meta1.conf}.  For example, here is how to redirect the
standard error of the @samp{smtps} component to @samp{local1.debug}
syslog channel:

@example
include-meta1 /etc/meta1/meta1.conf

component smtps @{
  stderr syslog local1.debug;
@}
@end example

@node Global Configuration
@section Global Configuration
@cindex Global Configuration
The statements described in this section affect @command{pies}
behavior as a whole.

@deffn {Config} env @{ @dots{} @}
Modifies the environment for the running @command{pies} instance.  The
modified environment will be inherited by all processes started by
@command{pies} in the course of its normal operation.

@xref{Environment}, for a detailed discussion of the @code{env}
statement syntax.
@end deffn

@anchor{syslog}
@deffn {Config} syslog @{ @dots{} @}
This block statement configures logging via syslog.  It has the following
substatements:

@deffn {Config: syslog} dev @var{address}
Address of the socket the syslog daemon is listening on.  By default,
@file{/dev/log} is used.

The @var{address} argument is either the file name of the UNIX socket
file or IPv4 address of the syslog collector optionally followed by
the colon and port number (or symbolic service name).  If the port
number is not supplied, the @samp{syslog} port (UDP) from
@file{/etc/services} is used.
@end deffn

@deffn {Config: syslog} facility @var{string}
Set syslog facility to use.  Allowed values are: @samp{user},
@samp{daemon}, @samp{auth}, @samp{authpriv}, @samp{mail}, @samp{cron},
@samp{local0} through @samp{local7} (case-insensitive).
@end deffn

@deffn {Config: syslog} tag @var{string}
Prefix syslog messages with this string.  By default, the program name
is used.
@end deffn

@deffn {Config: syslog} message-queue-size @var{number}
Defines how many log messages can be stored in the request queue.
Messages enter the request queue when the logger cannot communicate
with the syslog server. This can happen when the latter is down or
is heavily loaded. When the server is back again, messages from
the queue are sent to it. If, during the server unavailability,
the queue gets full, its first (oldest) message is discarded to make
place for the incoming message, and the fact is recorded. The number
of such discarded messages will be logged when the syslog server is
available. Also, if the number of discarded messages reaches
the message queue size, the queue gets flushed to the fallback log
file.

The default is 64.
@end deffn

@deffn {Config: syslog} fallback-ignore-failures @var{bool}
When set to @code{true}, instructs @code{pies} to ignore any errors
occurring while writing to the fallback file. Any such errors cause
the fallback file to be closed and disabled. It will remain in this
state until @command{pies} is reloaded via the @code{SIGHUP} signal
or using the @command{pies -r}.

If this setting is @code{false}, I/O errors occurring during writes to
fallback log file cause abnormal program termination. This is the
default behavior.
@end deffn
@end deffn

@deffn {Config} umask @var{number}
Set the default umask.  The @var{number} must be an octal value not greater
than @samp{777}.  The default umask is inherited at startup.
@end deffn

@deffn {Config} limits @var{arg}
Set global system limits for all pies components.  @xref{Resources,
limits}, for a detailed description of @var{arg}.
@end deffn

@deffn {Config} return-code @{ @dots{} @}
Configure global exit actions.  @xref{Exit Actions}, for a detailed
description of this statement.
@end deffn

@anchor{shutdown-timeout}
@deffn {Config} shutdown-timeout @var{number};
Wait @var{number} of seconds for all components to shut down.
Default is 5 seconds.

@anchor{shutdown sequence}
@cindex shutdown sequence
The normal shutdown sequence looks as follows:

@enumerate 1
@item
Compute shutdown sequence that takes into account dependencies
between components, so as to ensure that dependent components
stop before their prerequisites.  This sequence can be viewed
using the @option{--list-shutdown-sequence} option.

@item
For each stage in the shutdown sequence, send the @dfn{termination signal}
to each component marked for that stage.  By default, @code{SIGTERM}
is used, but it can be changed for each component using the @code{sigterm}
configuration statement (@pxref{sigterm}).  Wait for the signalled
components to terminate.  If any of them remain running after
@code{shutdown-timeout} seconds, send them the @code{SIGKILL} signal.

@item
If any @code{shutdown} components are defined, start them and wait
for their termination.  If any components are left running after
@code{shutdown-timeout} seconds, terminate them by sending the
@code{SIGKILL} signal.
@end enumerate
@end deffn

@node Pies Privileges
@section Pies Privileges
@cindex privileges
  Normally, @command{pies} is 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:

@deffn {Config} user @var{user-name}
Start @command{pies} with the UID and GID of this user.
@end deffn

@deffn {Config} group @var{group-list}
Retain the supplementary groups, specified in @var{group-list}.
@end deffn

@deffn {Config} allgroups @var{bool}
Retain all supplementary groups the user (as given with
@command{user} statement) is a member of.
@end deffn

  An example of such implementation is using @command{pies} to
start @command{jabberd} components:
@uref{http://www.gnu.org.ua/@/software/@/pies/@/example.php?what=jabberd2}.

@node State Files
@section State Files
@cindex state files
  Pies uses several files to keep its state information.  The
directory which hosts these files is called @dfn{state directory}, it
is usually @file{/var/pies} or @file{/usr/local/var/pies}).  The state
directory can be configured at run time:

@deffn {Config} state-directory @var{dir}
Set the program state directory.
@end deffn

The table below describes the files kept in the state directory.  The
@var{instance} in this table stands for the @command{pies} instance
name (@pxref{instances}).  Usually, it is @samp{pies}.

@table @asis
@item @file{@var{instance}.pid}
The @dfn{PID file}.  It keeps the PID number of the running
@command{pies} instance.

@item @file{@var{instance}.qotd}
The @dfn{Quotation-of-the-day file}.  It is used by the @samp{qotd}
built-in service (@pxref{qotd}).
@end table

  The following statements allow to redefine state file names.
Use them only if the defaults do not suit your needs, and neither
the @code{state-directory} statement nor the @option{--instance}
option can help:

@deffn {Config} pidfile @var{file}
Sets the PID file name.
@end deffn

@deffn {Config} qotd-file @var{file-name}
Sets the name of the @samp{quotation-of-the-day} file.
@end deffn

The following statements are retained for compatibility with earlier
@command{pies} versions.  They are silently ignored:

@deffn {Config} control-file @var{arg}
@end deffn

@deffn {Config} stat-file @var{arg}
@end deffn

@node Pies Debugging
@chapter Pies Debugging
@xopindex{debug, described}
  The amount of debugging information produced by @command{pies} is configured
by the following statements:

@deffn {Config} debug @var{level}
Set debugging level.  The @var{level} must be a non-negative decimal
integer.  In version @value{VERSION} the following debugging levels
are used:

@table @asis
@item 1
Log all basic actions: starting and stopping of components, received incoming
@acronym{TCP} connections, sending mails.  Notify about setting
limits.  Log pre-startup actions (@pxref{Actions Before Startup}).

@item 2
Log setting particular limits.  Log the recomputed alarms.

@item 4
Dump execution environments

@item 6
Debug the parser of MeTA1 configuration grammar.

@item 7
Debug the lexical analyzer of MeTA1 configuration file.
@end table
@end deffn

@anchor{source-info}
@deffn {Config} source-info @var{bool}
This statement decides whether debugging messages should contain
source information.  To enable source information, use:

@example
source-info yes;
@end example

This feature is designed for @command{pies} developers.
@end deffn

@node piesctl
@chapter Communicating with Running @command{pies} Instances
  The @command{piesctl} tool allows you to communicate with the
running @command{pies} program.  The invocation syntax is:

@example
piesctl [@var{options}] @var{command} [@var{args}...]
@end example

The @var{command} determines the operation to perform.  The following
sections describe available commands in detail.

@menu
* id::          Get Info About the Running Instance.
* stop and reboot:: Instance Management.
* config::      Configuration Management.
* components::  Component Management.
* telinit::     Init Process Management.
* options::      @command{piesctl} options.
* piesctl.conf:: Configuration file for @command{piesctl}.
@end menu

@node id
@section piesctl id -- Return Info About the Running Instance
@cindex id, piesctl
@cindex piesctl id
  The @option{id} subcommand returns information about the
@command{pies} instance organized as key-value pairs.  When invoked
without arguments, the following data are returned:

@table @code
@item package
Canonical package name.
@item version
Version of @command{pies}.
@item instance
Instance name (@pxref{instances}).
@item binary
Full pathname of the @command{pies} executable file.
@item argv
Command line arguments supplied upon its startup.
@item PID
Process ID.
@end table

For example:

@example
@group
$ piesctl id
package: GNU Pies
version: @value{VERSION}
instance: pies
binary: /usr/sbin/pies
argv: /usr/sbin/pies --config-file=/etc/pies/pies.conf
PID: 15679
@end group
@end example

To request a subset of these data, give the items of interest as
command line arguments:

@example
@group
$ piesctl id binary PID
binary: /usr/sbin/pies
PID: 15679
@end group
@end example

@node stop and reboot
@section Instance Management

Two subcommands are provided for stopping and restarting @command{pies}.

@deffn {piesctl} shutdown
Stop the running @command{pies} instance
@end deffn

@deffn {piesctl} reboot
Restart @command{pies} instance.  Upon receiving this command,
@command{pies} will restart itself with the same command line
arguments.  Naturally, this means that all running components will
be restarted as well.
@end deffn

These subcommands do nothing when init process is selected.

@node config
@section piesctl config -- Configuration Management

@deffn {piesctl} config file list
List currently loaded configuration files.
@end deffn

@deffn {piesctl} config file clear
Clear configuration file list
@end deffn

@deffn {piesctl} config file add @var{syntax} @var{file}
Add @var{file} to the list of configuration files.  @var{syntax}
specifies its syntax: @samp{pies}, @samp{inetd}, @samp{meta1}, or
@samp{inittab}.
@end deffn

@deffn {piesctl} config file del[ete] @var{name} [@var{name}...]
Remove listed names from the list of configuration files.
@end deffn

@anchor{config reload}
@deffn {piesctl} config reload
Reload configuration.
@end deffn

@node components
@section Component Management

@anchor{piesctl list}
@deffn {piesctl} list [@var{condition}]
List configured components.  When used without arguments, all
components are listed.  Otherwise, only processes matching
@var{condition} are listed.

  Each output line contains at least two columns.  The first column
lists the tag of the component.  The second one contains @dfn{flags},
describing the type and status of the component.  The first flag
describes the type:

@multitable @columnfractions 0.2 0.7
@headitem Flag @tab Meaning
@item 3        @tab SysV init @samp{ctrlaltdel} component
@item A        @tab Accept-style component
@item B        @tab SysV init @samp{boot} component
@item C        @tab Respawn component
@item c        @tab SysV init @samp{once} component
@item D        @tab SysV init @samp{ondemand} component
@item E        @tab Command being executed
@item F        @tab SysV init @samp{powerfail} component
@item f        @tab SysV init @samp{powerwait} component
@item I        @tab Inetd-style component
@item i        @tab SysV init @samp{sysinit} component
@item k        @tab SysV init @samp{kbrequest} component
@item n        @tab SysV init @samp{powerfailnow} component
@item o        @tab SysV init @samp{powerokwait} component
@item P        @tab Pass-style component
@item R        @tab Output redirector
@item W        @tab SysV init @samp{wait} component
@item w        @tab SysV init @samp{bootwait} component
@end multitable

  The second flag is meaningful only for components.  Its values are:

@multitable @columnfractions 0.2 0.7
@headitem Flag @tab Meaning
@item -        @tab Disabled component
@item f        @tab A finished @samp{once} component
@item L        @tab Inetd listener
@item R        @tab Running component
@item S        @tab Component is stopping
@item s        @tab Component is sleeping
@item T        @tab Component is stopped
@end multitable

  The next column lists the PID (for running components) or socket address
(for Internet listeners), or the string @samp{N/A} if neither of the
above applies.

  If the component is sleeping, the time of its scheduled wake-up is
listed in the next column.

  Rest of line shows the component command line.

@example
@group
$ piesctl list
smtps/stderr R  4697
pmult/stderr R  4677
pmult/stdout R  4676
pmult        CR 4678 /usr/local/sbin/pmult
smar         CR 4680 smar -f /etc/meta1/meta1.conf -d 100
qmgr         CR 4691 qmgr -f /etc/meta1/meta1.conf
smtpc        CR 4696 smtpc -f /etc/meta1/meta1.conf
smtps        PR 4698 smtps -d100 -f /etc/meta1/meta1.conf
finger       IL inet+tcp://0.0.0.0:finger /usr/sbin/in.fingerd -u
eklogin      IL inet+tcp://0.0.0.0:eklogin /usr/sbin/klogind -k -c -e
kshell       IL inet+tcp://0.0.0.0:kshell /usr/sbin/kshd -k -c
eklogin      IR 13836  /usr/local/sbin/klogind -k -c -e
@end group
@end example
@end deffn

Use @var{condition} to select the components to list.  In its simplest
form, @var{condition} is one of the following @dfn{terms}:

@table @code
@item all
Selects all processes, including internal services, such as output
redirectors.

@item active
Selects only active components.

@item component @var{tag}
Selects the component with the given tag.  @xref{Component Statement, tag}.

@item type @var{arg}
Selects processes of the given type.  Argument is @samp{component}, to
select only components, @samp{command}, to select commands or
@samp{redirector} to select output redirectors.  When @command{piesctl
list} is used without arguments, @option{type component} is assumed.

@item mode @var{arg}
Selects components of the given mode (@pxref{Component Statement,
mode}).  E.g. to list @samp{inetd} components:

@example
piesctl list mode inetd
@end example

@item status @var{arg}
Selects processes with the given status.  Argument is one of:

@table @code
@item finished
Component is finished.

@item listener
Component is an inet listener.

@item running
Component is running.

@item sleeping
Component is sleeping.

@item stopped
Component is stopped.

@item stopping
Component has been sent the SIGTERM signal and @command{pies} is
waiting for it to terminate.
@end table
@end table

A term may be preceded by the word @samp{not} to indicate negation of
the condition.  For example, the following command will list inactive
components:

@example
piesctl list not active
@end example

Furthermore, terms can be combined in logical expressions using
boolean @samp{and} and @samp{or} operators:

@example
piesctl list type component and not mode inetd
@end example

Conjunction (@samp{and}) has higher precedence than disjunction
(@samp{or}).  In complex expressions parentheses can be used to
alter the precedence:

@example
piesctl list type component \
        and \( status running or status sleeping \)
@end example

Notice that parentheses must be escaped to prevent them from being
interpreted by the shell.

The following summarizes the syntax of @var{condition} in BNF:

@example
<condition> ::= <disjunction>
<disjunction> ::= <conjunction> | <conjunction> "or" <disjunction>
<conjunction> ::= <unary> | <unary> "and" <conjunction>
<unary> ::= <term> | "not" <condition> | "(" <condition> ")"
<term> ::= "all" | "active" | <keyword> <value>
<keyword> ::= "type" | "mode" | "status" | "component"
<value> ::= <word> | <quoted-string>
<word> ::= <printable> | <word> <printable>
<printable> ::= "A" - "Z" | "a" - "z" | "0" - "9" |
                "_" | "." | "*" | ":" | "@@" | "[" | "]" | "-" | "/"
<quoted-string> ::= """ <string> """
<string> ::= <char> | <string> <char>
<char> ::= <any character except "\" and """> | "\\" | "\""
@end example

@deffn {piesctl} stop @var{condition}
Stop components matching @var{condition}.
@end deffn

@deffn {piesctl} start @var{condition}
Start components matching @var{condition}.
@end deffn

@deffn {piesctl} restart @var{condition}
Restart components.
@end deffn

@node telinit
@section Init Process Management

The @command{piesctl telinit} command communicates with @command{pies}
instance running as @dfn{init} process (PID 1).  @xref{piesctl
telinit}, for a detailed discussion.

@node options
@section @command{Piesctl} Command Line Options

@table @option
@item -c @var{file}
@itemx --config-file=@var{file}
Read configuration from @var{file} instead of the default
@file{/etc/piesctl.conf}.  @xref{piesctl.conf}, for its description.

@item -d
@itemx --dump
Dump obtained responses verbatim.  This is useful mainly for debugging
purposes.

@item -i @var{inst}
@itemx --instance=@var{inst}
Talk to @command{pies} instance @var{inst}.

@item --no-netc
@itemx -N
Don't read @file{~/.netrc} file.

@item -u @var{url}
@itemx --url=@var{url}
Specifies the URL of the communication socket.  @xref{piesctl url},
for a description of allowed URL forms.

@item -v
@itemx --verbose
Enable verbose diagnostics.
@end table

Before parsing, configuration file is preprocessed using external
command defined at build time (normally @command{m4}).  The following
options control this feature:

@table @option
@item -E
Show preprocessed configuration on stdout and exit.

@item --no-preprocessor
Disable the use of the external preprocessor.

@item --preprocessor=@var{cmd}
Use the command @var{cmd} as the external preprocessor, instead of the
default @command{m4}.

@item --define=@var{sym}[=@var{value}]
@itemx -D @var{symbol}[=@var{value}]
Define symbol @var{sym} as having @var{value}, or empty, if
the @var{value} is not given.

@item --include-directory=@var{dir}
@itemx -I @var{dir}
Add directory @var{dir} to the list of directories to be scanned for
preprocessor include files.

@item --undefine=@var{sym}
@itemx -U @var{sym}
Undefine symbol @var{sym}.
@end table

Finally, the following options can be used to obtain on-line assistance:

@table @option
@item --config-help
Show a terse reference to configuration file syntax and exit.

@item -h
@itemx --help
Display command line help summary.

@item --usage
Give a short usage message

@item -V
@itemx --version
Show program version.
@end table

@node piesctl.conf
@section Configuration for @command{piesctl}

  The configuration file @file{/etc/piesctl.conf} helps the
@command{piesctl} tool to determine the URL of the control socket.
This file is not mandatory, and its absence is not considered an
error.  Its syntax is similar to that of @file{/etc/pies.conf}.  The
following statements are defined:

@deffn {piesctl.conf} socket @var{url}
Sets the default socket URL.
@end deffn

@deffn {piesctl.conf} source @var{ip}
Sets the default source IP address.  This is used if the control
socket is of @samp{inet} type.
@end deffn

@deffn {piesctl.conf} instance @var{name}
Configures socket URL and (optionally) source address to use when
communicating with the @command{pies} instance @var{name} (i.e., when
invoked as @command{piesctl -i @var{name}}:

@example
instance @var{name} @{
    # @r{Socket URL for that instance.}
    socket @var{url};
    # Source IP address.
    source @var{ip};
@}
@end example
@end deffn

@anchor{piesctl url}
Valid values for @var{url} in the above statements are:

@table @asis
@item inet://@var{ip}:@var{port}
Use the IPv4 address @var{ip} (may be given as a symbolic host name),
on port @var{port}.

@item local://@var{file}
@itemx file://@var{file}
@itemx unix://@var{file}
Use the @acronym{UNIX} socket file @var{file}.
@end table

The following algorithm is used to determine the name of the
communication socket:

@enumerate 1
@item
If the @option{--url} (@option{-u}) option is given, use its argument.
@item
Determine the instance name (@var{inst}).  If the @option{--instance}
(@option{-i}) is given, @var{inst} is its argument.  Otherwise, assume
@var{inst}=@samp{pies}.
@item
If configuration file @file{/etc/piesctl.conf} exists, read it.  On
success:
@enumerate a
@item
See if the @code{instance @var{inst}} statement is present
and has @code{socket} substatement.  If so, the argument to
@code{socket} gives the socket URL.
@item
Otherwise, if global @code{socket} statement is present, its argument
gives the URL.
@end enumerate
@item
Otherwise, suppose that @command{piesctl} is run on the same box where
the target instance of @command{pies} is running, and see if the file
@file{/etc/@var{inst}.conf} exists.   If so, parse it as
@command{pies} configuration file and look for @command{control} block
statement.  If it has @code{socket} statement, take its argument as
the URL.  @xref{control}.
@item
If socket URL is not determined by these steps, assume
@file{/tmp/@var{inst}.ctl}.
@end enumerate

@node Init Process
@chapter Init -- parent of all processes
@cindex init
  @command{Pies} can be executed directly by the kernel as a program
responsible for starting all other processes (a process with PID 1).
In this case it becomes also the parent of all processes whose natural
parents have died and is responsible for reaping those when they die.

  When invoked this way, @command{pies} reads its configuration from
two files: @file{/etc/inittab} and @file{/etc/pies.init}.  The former has
traditional syntax (@pxref{inittab}) and is retained for compatibility
with another @samp{init} daemons, and the latter is in native
@command{pies} format (@pxref{Syntax}).  Either of the files or even
both of them can be missing.

@anchor{startup states}
  The startup process passes through several states.  Transition between
states is controlled by @dfn{runlevel}, which also defines the set of
components that must be executed.  Startup states are:

@table @code
@item sysinit
System initialization state.  This state marks the beginning of the
startup process.  Only root partition is mounted, and is usually
read-only.  @command{Pies} uses console to output diagnostic messages.

Normally, the configuration instructs @command{pies} to execute at
this point the system initialization script, which checks and mounts the
necessary local file systems, initializes devices and loads kernel modules.

The system then passes to @samp{boot} state, unless the default
runlevel is @samp{S}, in which case the @samp{single} state is selected.

@item boot
Upon entering the @samp{boot} state, @command{pies} attempts to log
the @samp{reboot} login record into the system @file{utmp}/@file{wtmp}
files and executes entries marked with @code{boot} and @code{bootwait}
types.  It then enters the @samp{normal} state.

@item single
This is a fallback state for single-user system.  It is entered only
if the @samp{S} runlevel has been selected initially.  Normally, this
state is used for system maintenance.  The configuration usually
provides a component which executes a single-user shell when entering
this state.  If it does not, @command{pies} executes @samp{/sbin/sulogin}.

@item normal
Upon entering this state, @command{pies} assumes that components
executed previously have brought the system to such condition where
normal communication means can already be used.  This means that the
file systems have been mounted read-write and the @command{syslog}
daemon is operating.  Therefore @command{pies} opens its communication
channels and redirects its diagnostic output to syslog facility
@samp{daemon}.

Then it starts components scheduled for the default runlevel and
begins its normal operation.
@end table

@command{Pies} communication channels are:

@table @file
@item /dev/initctl
A FIFO file for communication using legacy protocol (using @command{telinit}).

@item /dev/init.ctl
UNIX socket for communication using @command{piesctl}.
@end table

@menu
* Runlevels::
* Init Process Configuration::
* Init Command Line::
* Init Environment::
* piesctl telinit::
* telinit command::
@end menu

@node Runlevels
@section Runlevels

Runlevel determines the set of components to be run in normal state.
It is a decimal digit from @samp{0} to @samp{9} or letter @samp{S}.
Traditionally, runlevels are assigned as follows:

@table @asis
@item 0
System halt.
@item 1
@itemx S
Single user mode.
@item 3
Multiuser mode.
@item 4
Multiuser with X11.
@end table

@anchor{Ondemand runlevels}
Additionally, three special runlevels @samp{a}, @samp{b} and @samp{c}
can be used to start @dfn{on-demand} components without actually
changing the runlevel.  Once started, on-demand components persist
through eventual runlevel changes.

@node Init Process Configuration
@section Init Process Configuration
@anchor{inittab}
The two configuration files are read in this order:
@file{/etc/inittab} first, then @file{/etc/pies.init}.  The
@file{/etc/inittab} file is a simple line-oriented file.  Empty lines
and lines beginning with @samp{#} are ignored (except if @samp{#} is
followed by the word @samp{pies}, see below).  Non-empty lines
consist of 4 fields separated by colons:

@example
@var{id}:@var{runlevels}:@var{mode}:@var{command}
@end example

@noindent
where

@table @var
@item id
Component identifier.  A string uniquely identifying this component.

@item runlevels
List of the runlevels for which the component should be run.
Runlevels are listed as a contiguous string of characters, without
any whitespace or delimiters.

@item mode
Component execution mode.

@item command
Command to be executed and its arguments.
@end table

Component execution modes are:

@table @code
@item respawn
  The basic execution mode.  A @dfn{respawn} component is
restarted each time it terminates.   If it is restarted more than 10
times in 2 minutes, @command{pies} puts it in @dfn{sleeping} state for
the next 5 minutes.

@item off
  Disabled component.  The entry is ignored.

@item boot
  The process will be executed during system boot.  The
@samp{runlevel} settings are ignored.

@item bootwait
  The process will be executed during system boot.  No other
components will be started until it has terminated.  The
@samp{runlevel} settings are ignored.

@item sysinit
  The process will be executed during system boot, before any @code{boot}
or @code{bootwait} entries.  The @samp{runlevel} settings are ignored.

@item once
  The process will be executed once when the specified runlevel is
entered.

@item wait
  The process will be started once when the specified runlevel is
entered.  @command{Pies} will wait for its termination before starting
any other processes.

@item ctrlaltdel
  The process will be executed when @command{pies} receives the SIGINT
signal.  Normally this means that the CTRL-ALT-DEL combination has
been pressed on the keyboard.

@item kbrequest
  The process will be executed when a signal from the keyboard handler
is received that indicates that a special key combination was pressed
on the console keyboard.

@item ondemand
  The process will be executed when the specified @dfn{ondemand}
runlevel is called (@samp{a}, @samp{b} and @samp{c}).  No real
runlevel change will occur (@pxref{Ondemand runlevels}).
The process will remain running across any eventual runlevel changes
and will be restarted whenever it terminates, similarly to
@code{respawn} components.

@item powerfail
  The process will be executed when the power goes down.  @command{Pies}
will not wait for the process to finish.

@item powerfailnow
  The process will be executed when the power is failing and the
battery of the external UPS is almost empty.

@item powerokwait
  The process will be executed as soon as @command{pies} is informed that
the power has been restored.

@item powerwait
  The process will be executed when the power goes down.  @command{Pies}
will wait for the process to finish before continuing.
@end table

The special mode @samp{initdefault} declares the default runlevel.  In
the @samp{initdefault} entry, the @var{runlevels} field must consist of
exactly one runlevel character.  Rest of fields are ignored.  For
example, the following instructs @command{pies} that the default
runlevel is @samp{3}:

@example
id:3:initdefault:
@end example

If no @samp{initdefault} entry is present, @command{pies} will ask the
user to input the desired default runlevel upon entering the normal
state.

Inittab must contain at least one entry with @samp{S} in
@var{runlevels} field.   This entry is used for system maintenance and
recovery.  If it is absent, @command{pies} adds the following default
entry implicitly:

@example
~~:S:wait:/sbin/sulogin
@end example

As an exception to traditional syntax, the @samp{#} followed by the
word @samp{pies} (with any amount of white space in between) introduce
a pragmatic comment that modifies the behavior of the configuration
parser.  The following such comments are understood:

@table @code
@item #pies pragma debug @var{n}
Set debugging level @var{n} (a decimal number).  @xref{Pies
Debugging}.

@item #pies pragma next @var{syntax} @var{file}
After parsing @file{/etc/inittab}, read configuration from file
@var{file}, assuming @var{syntax} (@pxref{config syntax}).  Multiple
@samp{next} pragmas are allowed, the named files will be processed in
turn.

The default set up is equivalent to specifying

@example
#pies pragma next pies /etc/pies.init
@end example

@item #pies pragma stop
Stop parsing after this line.  The remaining material is ignored.
@end table

Both the traditional @file{/etc/inittab} and pies-native
@file{/etc/pies.init} files are entirely equivalent, excepting that,
naturally, the latter is more flexible and gives much more
possibilities in defining the system behavior.  The declaration of a
component in @file{/etc/pies.init} can contain all the statements
discussed in @ref{Component Statement}.  The only difference is that
runlevels to start the component is must be specified:

@deffn {Config: component} runlevels @var{string}
Specifies the runlevel to start the component in.  The @var{string}
argument is a string of runlevel characters.
@end deffn

For example, the inittab entry discussed above is equivalent to the
following statement in @file{pies.init} file:

@example
component @var{id} @{
  mode @var{mode};
  runlevels @var{runlevels};
  command @var{command};
@}
@end example

The default runlevel is specified in @file{/etc/pies.init} using
the following construct:

@deffn {Config} initdefault @var{rl}
Declare the default runlevel.  The argument is the runlevel name.
E.g.

@example
initdefault 3;
@end example
@end deffn

If both @file{/etc/inittab} and @file{/etc/pies.init} are present, the
latter can declare components with the same @var{id} as the ones
declared in the former.  In that case, the two entries will be merged,
the latter one overriding the former.  Thus, @file{/etc/pies.init} can
be used to complement definitions in @file{inittab}.  Consider, for
example the following inittab entry:

@example
upd:3:respawn:/usr/libexec/upload
@end example

If @file{pies.init} contains the following:

@example
component upd @{
    user nobody;
    stderr syslog local1;
@}
@end example

@noindent
the result will be equivalent to:

@example
component upd @{
    mode respawn;
    runlevels 3;
    command /usr/libexec/upload;
    user nobody;
    stderr syslog local1;
@}
@end example

@node Init Command Line
@section Init Command Line

The runlevel to run in can be given as argument in the command line:

@example
/sbin/pies 1
@end example

Apart from this, the following command line arguments are recognized:

@table @option
@item -s
@itemx single
Initialize default runlevel @samp{S}.

@item -b
@itemx emergency
Run emergency shell @command{/sbin/sulogin}, prior to initialization.
@end table

@node Init Environment
@section Init Environment

Programs run from @command{pies} init process inherit a basic
environment consisting of the following variables:

@table @option
@item PREVLEVEL=@var{L}
Previous runlevel, or letter @samp{N} if the runlevel hasn't been
changed since startup.

@item RUNLEVEL=@var{L}
Current runlevel.

@item CONSOLE=@var{device}
Pathname of the console device file.

@item INIT_VERSION="GNU Pies @value{VERSION}"
Version of @command{pies}.

@item PATH=/bin:/usr/bin:/sbin:/usr/sbin
@end table

Once the system is booted up, the environment can be controlled using
the @command{piesctl telinit environ} (or @command{pies -T -e}) command.

@node piesctl telinit
@section piesctl telinit

@deffn {piesctl} piesctl telinit runlevel
Report the runlevel and state of the process 1.
@end deffn

@deffn {piesctl} piesctl telinit runlevel @var{n}
Switch to runlevel @var{n}.
@end deffn

@deffn {piesctl} piesctl telinit environ list [@var{NAME}]
List the environment.  If @var{NAME} is given, list only the value of
that variable.
@end deffn

@deffn {piesctl} piesctl telinit environ set @var{NAME}=@var{VALUE}
Set variable @var{NAME} to @var{VALUE}.  The environment is capable to
hold at most 32 variables.
@end deffn

@deffn {piesctl} piesctl telinit environ unset @var{NAME}
Unset variable @var{NAME}.
@end deffn

@node telinit command
@section The Telinit Command

@xopindex{telinit option, introduced}
  When given the @option{-T} (@option{--telinit}) option,
@command{pies} emulates the behavior of the traditional
@command{telinit} command.  This is a legacy way of communicating with
the init process.  The commands are sent via named pipe
@file{/dev/initctl}.  When the @option{-T} option is given, the rest
of command line after it is handled as @command{telinit} options.  The
following command:

@example
pies -T [-t @var{n}] @var{r}
@end example

@noindent
tells init process to switch to runlevel @var{r}.  Possible values for
@var{r} are:

@table @asis
@item 0 to 9
Instructs init to switch to the specified runlevel.
@item S or s
Tells init to switch to the single user mode.
@item a, b, or c
Tells init to enable on-demand components with the specified
runlevel.  The actual runlevel is not changed.
@item Q or q
Tells init to rescan configuration files.
@end table

The @option{-t} (@option{--timeout}) option sets the time to wait
for processes to terminate after sending them the SIGTERM signal.  Any
processes that remain running after @var{n} seconds will be sent the
SIGKILL signal.  The default value is 5 seconds.

This usage is equivalent to the @command{piesctl telinit runlevel}
command (@pxref{piesctl telinit}).

The @option{-e} (@option{--environment}) option modifies the init
process environment.  Its argument is either a variable assignment
@samp{@var{name}=@var{value}} to set a variable, or the name of a
variable to unset it.  Several @option{-e} options can be given to
process multiple variables in a single command.  Note, however, that
given @var{n} @option{-e} options, the total length of their arguments
is limited to 367 - @var{n} bytes.

This option provides a limited subset of the functionality offered by
the  @command{piesctl telinit environ} command.

The table below summarizes all options available in @option{telinit}
mode:

@table @option
@item -t @var{n}
Wait @var{n} seconds for processes to terminate after sending them the
SIGTERM signal.  Any processes that remain running after that time
will be sent the SIGKILL signal.  The default value is 5 seconds.

@item -e @var{var}=@var{value}
Define environment variable @var{var} as having value @var{value}.

@item -e @var{var}
Unset environment variable @var{var}.
@end table

@node Docker Entrypoint
@chapter Using Pies as Entrypoint for Docker Container
@cindex docker
Another use for @command{pies} is as an entrypoint in a docker
container.  This is similar to the @command{init} mode described in
the previous chapter in that @command{pies} runs with PID 1.  However,
in this case @command{pies} uses its regular configuration file.

@opindex --no-init
When started with PID 1 from a docker container, @command{pies}
tries to detect the fact automatically and switch to the entrypoint
mode.  As of version @value{VERSION}, this detection might fail in
containers run under Kubernetes.  For such cases, use the
@option{--no-init} option to inform @command{pies} that it should
run in @code{entrypoint} mode.

The following @file{Dockerfile} fragment illustrates how to configure
@command{pies} to be run from a container:

@example
COPY pies.conf /etc
ENTRYPOINT [ "/usr/sbin/pies", "--foreground", "--stderr" ]
@end example

@noindent
It is supposed, of course, that the configuration file
@file{pies.conf} is available in the same directory as
@file{Dockerfile}.

It is a common practice to supply configuration settings via the
environment variables.  To implement it in @file{pies.conf}, use
either @code{expandenv} or @code{shell} flag (@pxref{Early Environment
Expansion}).  For example:

@example
  flags expandenv;
  command "syslogd -n -R $LOGHOST";
@end example

This will expand the environment variable @env{LOGHOST} and pass its
value as one of the arguments to @command{syslog}.  The usual shell
syntax is supported.  For example, to provide a default value for the
@option{-R} option above (in case @env{LOGHOST} is empty or
undefined), use:

@example
  flags expandenv;
  command "syslogd -n -R $@{LOGHOST:-172.19.255.255@}";
@end example

Quite often a need arises to expand environment variables in other
parts of the configuration file and to conditionally exclude portions
of configuration, depending on whether a particular variable is set.
The following sections describe two approaches to solving this problem.

@menu
* m4 environment::  Expanding Environment Variables in GNU m4.
* xenv::            Specialized Preprocessor Program.
@end menu

@node m4 environment
@section Expanding Environment Variables in GNU m4

Configuration preprocessing (@pxref{Preprocessor}) can be used to
conditionally enable parts of the @file{pies.conf} file, depending
on the value of an environment variable.  The technique described
below assumes that you use GNU @command{m4} as preprocessor.

Define the following two M4 macros:

@deffn {M4 macro} CF_WITH_ENVAR @var{name} @var{text}
Expands the environment variable @var{name} within @var{text}.
The macro does so by temporarily redefining the symbol @var{name} to
the value of the environment variable @var{name} and expanding
@var{text}.

The definition of the macro is:

@example
m4_define(`CF_WITH_ENVAR',m4_dnl
`m4_pushdef(`$1',m4_esyscmd(printf "$`$1'"))m4_dnl
$2`'m4_dnl
m4_popdef(`$1')m4_dnl
')
@end example

This macro allows you to use environment expansion where it is not
normally supported.  Consider, for example, this fragment:

@example
component @{
  CF_WITH_ENVAR(`WORKDIR', `chdir "WORKDIR";')
  ...
@}
@end example

If you set @code{WORKDIR=/var/wd} prior to invoking @command{pies}, it
will actually expand to

@example
component @{
  chdir "/var/wd";
  ...
@}
@end example

@noindent
@xref{Actions Before Startup, chdir}, for details about the
@code{chdir} statement.
@end deffn

@deffn {M4 macro} CF_IF_ENVAR @var{name} @var{if-set} @var{if-unset}
If the environment variable @var{name} is defined and has a non-empty
value, expand @var{if-set}, otherwise expand @var{if-unset}.  Expand
each occurrence of @var{name} in @var{if-set} to the actual value of
the environment variable.

Following is the definition of this macro:

@example
m4_define(`CF_IF_ENVAR',m4_dnl
`CF_WITH_ENVAR(`$1',`m4_ifelse($1,`',$3,$2)')')
@end example

This macro makes it possible to conditionally enable configuration
file fragments depending on whether some environment variable is
defined.  E.g.:

@example
CF_IF_ENVAR(`LOGHOST',`
component logger @{
  command "syslogd -n -R LOGHOST;
@}
')
@end example
@end deffn

Place both macros in a single file and include it at the top of your
@file{pies.conf} using the @code{m4_include} command (@pxref{m4}).

@node xenv
@section Using xenv
@prindex xenv

Another way to expand environment variables in the configuration file
is to use @command{xenv}.  @command{xenv} is a specialized
preprocessor that expands environment variables in its input.  It is
also able to conditionally include parts of text depending on whether
the environment variable is defined.  The program is described in
@uref{https://www.gnu.org.ua/software/xenv/}.

To use @command{xenv} as preprocessor, start @command{pies} as
follows:

@example
pies --foreground --stderr --preprocessor="xenv -s"
@end example

The @option{-s} option instructs @command{xenv} to emit
@dfn{synchronization lines}, that inform @command{pies} about actual
location of configuration statements in case when the expansion adds
or removes portions of text spanning several lines.

You can also combine the functionality of @command{m4} and
@command{xenv} by running

@example
pies --foreground --stderr --preprocessor="xenv -s -m"
@end example

In this case @command{xenv} will automatically feed its output to the
standard input of @command{m4}, started for this purpose.

By default, @command{xenv} uses the shell syntax to expand the
variables.  For example, in the following configuration file
fragment, @samp{$WORKDIR} will expand to the actual value of
the @env{WORKDIR} environment variable:

@example
component @{
  chdir "$WORKDIR";
  ...
@}
@end example

There are two ways to conditionally include portions of text.  The first
one is to use the @samp{$@{X:+W@}} construct.  For example:

@example
component @{
  $@{WORKDIR:+chdir "$WORKDIR";@}
  ...
@}
@end example

Another way is to use the @command{xenv} @samp{$$ifset} (or
@samp{$$ifdef}) statement:

@example
component @{
$$ifset WORKDIR
  chdir "$WORKDIR";
$$endif
  ...
@}
@end example

The difference between @samp{$$ifset X} and @samp{$$ifdef X} is the
same as between @samp{$@{X:+W@}} and @samp{$@{X+W@}},
i.e. @samp{$$ifset} tests whether the variable is set and not-null,
and @samp{$$ifdef} tests only whether it is set, no matter its value.

@command{xenv} extends the shell syntax by providing a @dfn{ternary}
operator.  The construct @samp{$@{X|A|B@}} expands to @samp{A} if
the variable @env{X} is set and to @samp{B} otherwise (as usual,
placing the colon before first @samp{|} checks if the variable is set
and not null).  This allows for writing compact conditionals:

@example
@group
component syslogd @{
   mode respawn;
   command "/sbin/syslogd -n $@{LOGHOST:|-R $LOGHOST|-O /proc/1/fd/1@}";
@}
@end group
@end example

In this example @command{syslogd} is instructed to relay messages to
the IP address specified by the @env{LOGHOST} variable and to send
messages to the container stdout otherwise.

Using shell indirection operator @samp{$} can be confusing in parts of
@command{pies} configuration file that deal with environment variables
by themselves.  The common point of confusion is using @code{env} and
@code{command} statements when @code{shell} or @code{expandenv} flag
is set.  For example:

@example
@group
component X @{
   env @{
      set "HOME=/var/lib/nobody";
   @}
   flags shell;
   command "marb -C $HOME";
@}
@end group
@end example

Here, the intent is to pass @samp{/var/lib/nobody} as the command line
argument to @command{marb}.  However, if @command{pies} was started
with @command{xenv} as preprocessor, the reference @samp{$HOME} will
be expanded by @command{xenv} at the early stage to whatever value the
@env{HOME} variable had at @command{pies} startup.   Consequently,
when it comes to launching the @samp{X} component, the intended
expansion won't take place.

There are three options to handle such cases:

@enumerate 1
@item Escape the @samp{$}

Use backslash to suppress expansion by @command{xenv}:

@example
@group
component X @{
   env @{
      set "HOME=/var/lib/nobody";
   @}
   flags shell;
   command "marb -C \$HOME";
@}
@end group
@end example

@item Use the @dfn{verbatim} operator

This allows to reproduce the desired part of text verbatim.  There are
two verbatim operators: inline operator @samp{$[...]} and block
operator @samp{$$verbatim ... $$end}.  Examples:

@example
@group
component X @{
   env @{
      set "HOME=/var/lib/nobody";
   @}
   flags shell;
   $[command "marb -C $HOME";]
@}
@end group
@end example

or

@example
@group
component X @{
   env @{
      set "HOME=/var/lib/nobody";
   @}
   flags shell;
$$verbatim
   command "marb -C $HOME";
$$end
@}
@end group
@end example

@item Change the indirection operator

The indirection operator @samp{$} can be changed either globally,
by using the @option{-S} option, or locally by using the
@samp{$$sigil} statement.  E.g.:

@example
@group
$$sigil @@
# From this point on, $ looses its special meaning in xenv.

component X @{
   env @{
      set "HOME=/var/lib/nobody";
   @}
   flags shell;
   command "marb -C $HOME @@FILE";
@}
@end group
@end example

In the @code{command} line of this example, @code{@@FILE} will be
expanded by @command{xenv} when processing the configuration file,
and @code{$HOME} will be expanded by shell (to the value
@samp{/var/lib/nobody}, set by the @code{env} statement) when
@command{pies} will start the command.
@end enumerate

@node Configuration Examples
@chapter Configuration Examples
  In this section we provide several examples of working @command{pies}
configuration files.

@menu
* Simple Pies::
* Hairy Pies::
* Inetd Pies::
@end menu

@node Simple Pies
@section Simplest Case: Using Pies to Run Pmult
  The example below runs @command{pmult} (@pxref{pmult, Pmilter
multiplexer program,, mailfromd, Mailfromd Manual}) utility with
the privileges of @samp{meta1} user.  Both standard error and standard
output are redirected to the syslog facility @samp{mail}, priorities
@samp{err} and @samp{info}, correspondingly.

@example
component pmult @{
  command "/usr/local/sbin/pmult";
  user meta1s;
  stderr syslog mail.err;
  stdout syslog mail.info;
@}
@end example

@node Hairy Pies
@section Using Pies to Run Pmult and MeTA1
  The example below is a working configuration file for running
@command{pmult} and all components of MeTA1, configured in
@file{/etc/meta1/meta1.conf}.  The global @code{return-code} statement
is used to configure @command{pies} behavior for some exit codes.

@example
# 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";
@end example

@node Inetd Pies
@section Running Pies as Inetd

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

@example
acl @{
   allow from 10.10.10.0/24;
   allow from 192.168.10.0/27;
   deny from any;
@}

debug 3;

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";
@}
@end example

The following is almost equivalent configuration in @command{inetd}
format:

@example
ftp  stream tcp  nowait  root /usr/sbin/ftpd  ftpd -l -C
pop3 stream tcp  nowait  root /usr/sbin/pop3d pop3d --inetd
@end example

This configuration is ``almost'' equivalent, because the
@command{inetd} format has no way of specifying ACLs and setting the
umask.

@node Command Line Usage
@chapter Command Line Usage

  When run without arguments, @command{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 copy is already running, by
looking for a PID file and verifying that the PID listed there is
alive and responding.  If another copy is running, @command{pies}
refuses to start up.

@anchor{instances}
  It is often necessary to run several copies of @command{pies} with
different configuration files.  To support such usage, @command{pies}
provides a notion of @dfn{instance}.  Pies instance is an independent
invocation of @command{pies} that uses a separate configuration file
and separate state files (@pxref{State Files}).  Instances are created
using the @option{--instance} option:

@table @option
@item --instance=@var{name}
Read configuration from @file{@var{sysconfdir}/@var{name}.conf},
use @var{name} as the base name for state files (i.e., they become
@file{@var{name}.pid}, @file{@var{name}.clt}, etc.) and tag all syslog
messages with @var{name}.
@end table

  For example, the following invocations create three instances of
@command{pies}:

@example
pies
pies --instance=inetd
pies --instance=mta
@end example

  The first instance uses the default configuration and state files.
The second one reads configuration from @file{/etc/inetd.conf}, and
the third one reads it from @file{/etc/mta.conf}.

@anchor{pies-status}
  After startup, you can verify the status of the running process
using the @option{--status} option.

@example
@group
$ pies --status
smtps/stderr R  4697
pmult/stderr R  4677
pmult/stdout R  4676
pmult        CR 4678 /usr/local/sbin/pmult
smar         CR 4680 smar -f /etc/meta1/meta1.conf -d 100
qmgr         CR 4691 qmgr -f /etc/meta1/meta1.conf
smtpc        CR 4696 smtpc -f /etc/meta1/meta1.conf
smtps        PR 4698 smtps -d100 -f /etc/meta1/meta1.conf
finger       IL inet+tcp://0.0.0.0:finger /usr/sbin/in.fingerd -u
eklogin      IL inet+tcp://0.0.0.0:eklogin /usr/sbin/klogind -k -c -e
kshell       IL inet+tcp://0.0.0.0:kshell /usr/sbin/kshd -k -c
eklogin      IR 13836  /usr/local/sbin/klogind -k -c -e
@end group
@end example

@xref{piesctl list}, for a description of the output format.

@anchor{pies-restart}
@xopindex{restart-component, described}
  You can restart any component by using the
@option{--restart-component} (@option{-R}) option, e.g.:

@example
$ pies -R pmult smtps
@end example

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

@example
$ pies --stop
@end example

If you modified the configuration file, you can instruct
@command{pies} to read it again using the @option{--reload}
(@option{-r}) command line option.

The @option{--status}, @option{--restart-component},
@option{--stop}, and @option{--reload} options actually run the
@command{piesctl} command, which provides a powerful tool for managing
@command{pies}.  @xref{piesctl}, for a detailed description.

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

@example
@group
$ 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
@end group
@end example

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

@anchor{trace-prereq}
@xopindex{trace-prereq, described}
  You can also list prerequisites explicitly:

@example
@group
$ pies --trace-prereq
qmgr: smar
smtpc: qmgr
smtps: smar qmgr
@end group
@end example

@noindent
To list prerequisites for a particular component, give its name in
the command line:

@example
@group
$ pies --trace-prereq smtps
smtps: smar qmgr
@end group
@end example

Any number of components can be given in the command line.

@anchor{trace-depend}
A counterpart option @option{--trace-depend} lists dependencies.  Its
usage is similar to the described above:

@example
@group
$ pies --trace-depend
smtps
smtpc
qmgr: smtps, smtpc
smar: smtps, qmgr
@end group
@end example

@example
@group
$ pies --trace-depend qmgr
qmgr: smtps, smtpc
@end group
@end example

@node Invocation
@chapter Pies Invocation

This section summarizes @command{pies} command line options.

@table @option
@opsummary{config-file}
@item --config-file=@var{file}
@item -c @var{file}
Read configuration from @var{file}, instead of the default
@file{/etc/pies.conf}.

@xref{Configuration}.

@opsummary{config-help}
@item --config-help
Show configuration file summary.  @xref{Configuration}.

@opsummary{define}
@item --define=@var{sym}[=@var{value}]
@itemx -D @var{symbol}[=@var{value}]
Define symbol @var{sym} as having @var{value}, or empty, if
the @var{value} is not given.  @xref{Preprocessor}.

@opsummary{debug}
@item --debug=@var{level}
@itemx -x @var{level}
Set debug verbosity level.  @xref{Pies Debugging}, for a description
of @var{level}.

@opsummary{dump-depmap}
@item --dump-depmap
Dump dependency map.  @xref{dump-depmap}.

@item -E
Preprocess configuration file and exit.  @xref{Preprocessor}.

@opsummary{force}
@item --force
Force startup even if another instance may be running.

@opsummary{foreground}
@item --foreground
Remain in foreground.

@item --help
Display a short usage summary and exit.

@opsummary{inetd}
@item --inetd
@itemx -i
Run in @command{inetd}-compatibility mode.  It is roughly
equivalent to @command{pies --instance=inetd --syntax=inetd}.
@xref{inetd}.

@opsummary{include-directory}
@item --include-directory=@var{dir}
@itemx -I @var{dir}
Add directory @var{dir} to the list of directories to be scanned for
preprocessor include files.

@opsummary{instance}
@item --instance=@var{name}
Define the name of the @command{pies} instance.  @xref{instances}.

@opsummary{lint}
@item --lint
@itemx -t

@opsummary{no-init}
@item --no-init
Don't assume @dfn{init mode} (@pxref{Init Process}) if running with PID
1.  @xref{Docker Entrypoint}.

@opsummary{list-shutdown-sequence}
@item --list-shutdown-sequence
List components in order of @dfn{shutdown sequence}.  Each line lists
the sequence stage number and the component name.  @xref{shutdown
sequence}, for a detailed discussion of its meaning.

@opsummary{no-preprocessor}
@item --no-preprocessor
Disable the use of the external preprocessor.

@xref{Preprocessor}.

@opsummary{preprocessor}
@item --preprocessor=@var{cmd}
Use the command @var{cmd} as the external preprocessor, instead of the
default @command{m4}.

@xref{Preprocessor}.

@opsummary{source-info}
@item --source-info
Show source info with debugging messages.  @xref{source-info}.

@opsummary{status}
@item --status
@itemx -s
Start @command{piesctl list} to obtain information about the running
processes.  @xref{piesctl list}.

@opsummary{stderr}
@item --stderr
Log to standard error.

@opsummary{stop}
@item --stop
@itemx -S
Stop the running instance.  This is equivalent to running
@command{piesctl shutdown}.

@opsummary{syntax}
@item --syntax=@var{type}
Define the syntax for parsing the configuration files specified by any
@option{--config-file} options that follow this one.  Possible values
for @var{type} are:

@table @code
@item pies
Native @command{pies} configuration.  @xref{Configuration}.

@item inetd
@samp{Inetd}-style configuration files.  @xref{inetd.conf}.

@item meta1
@samp{meta1}-style configuration files.  @xref{include-meta1}.

@item inittab
@samp{Inittab} file.  @xref{Init Process}.
@end table

@xref{config syntax}, for a detailed description of this option.

@opsummary{syslog}
@item --syslog
Log to syslog.  This is the default.

@opsummary{telinit}
@item --telinit
@item -T
Emulate the @command{telinit} legacy interface.  The rest of command
line following this option is processed as @command{telinit} options.
@xref{telinit command}, for a detailed description of these.

@opsummary{trace-depend}
@item --trace-depend
List dependencies for components named in the command line.  Without
arguments, dependencies for each component are listed.  @xref{trace-depend}.

@opsummary{trace-prereq}
@item --trace-prereq
List prerequisites for components named in the command line.  Without
arguments, prerequisites for each component are listed.  @xref{trace-prereq}.

@opsummary{rate}
@item --rate=@var{r}
Set maximum connection rate (connections per second) for inetd-style
components.  @xref{max-rate,, inetd component rate}.

@opsummary{reload}
@opsummary{hup}
@item -r
@itemx --reload
@itemx --hup
Reread the configuration files.  This is equivalent to running
@command{piesctl config reload} (@pxref{config reload}).

@opsummary{restart-component}
@item -R
@itemx --restart-component
Restart components named in the command line.  @xref{pies-restart}.

@item --version
Display program version and license information and exit.

@opsummary{undefine}
@item --undefine=@var{sym}
@itemx -U @var{sym}
Undefine symbol @var{sym}.  @xref{Preprocessor}.

@item --usage
Display a short summary of available options and exit.
@end table

@node Reporting Bugs
@chapter How to Report a Bug

  Send bug-reports and suggestions to @email{bug-pies@@gnu.org.ua}.

  If you think you've found a bug, please be sure to include maximum
information needed to reliably reproduce it, or at least to analyze
it.  The information needed is:

@itemize
@item Version of the package you are using.
@item Compilation options used when configuring the package.
@item Run-time configuration (@file{pies.conf} file and the command
line options used).
@item Detailed description of the bug.
@item Conditions under which the bug appears.
@end itemize

@node inetd configuration
@anchor{inetd.conf}
@appendix @file{Inetd.conf} Format
@include inetd.texi

@node User-Group ACLs
@appendix User-Group ACLs
@include usr-acl.texi

@node Control API
@appendix Control API
@include ctl.texi

@node Copying This Manual
@appendix GNU Free Documentation License
@include fdl.texi

@node Concept Index
@unnumbered Concept Index

This is a general index of all issues discussed in this manual

@printindex cp

@ifset WEBDOC
@ifhtml
@node This Manual in Other Formats
@unnumbered This Manual in Other Formats
@include otherdoc.texi
@end ifhtml
@end ifset

@bye
