\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,
51 Franklin Street, Fifth Floor,
Boston, MA 02110-1301 USA 

Copyright @copyright{} 2005-2016 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 Syntaxes.
* Pies Debugging::           Debugging @command{Pies}.
* piesctl::                  Communication with Running @command{pies} Instances.
* Init Process::             Using @command{Pies} as Parent of All Processes.
* Configuration Examples::   Examples of Configuration Files.
* Command Line Usage::
* Invocation::
* Reporting Bugs::

Appendices

* inetd.conf::           @file{Inetd.conf} Format.
* User-Group ACLs::
* Copying This Manual::  The GNU Free Documentation License.
* Concept Index::        Index of Concepts.

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

Pies Configuration File

* Syntax::               Configuration File Syntax
* 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::
* Preprocessor::         Using preprocessor to improve the configuration.

Component Statement

* Prerequisites::
* Component Privileges::
* Resources::
* 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.

  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 side.  

@anchor{respawn}
@cindex respawn components
  A @dfn{respawn} component is restarted each time it terminates.  If
it terminates too often, @command{pies} puts it in sleep mode 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
  @dfn{Inetd}-style components are not executed right after @command{pies}
startup.  Instead, @command{pies} opens a socket for each of them and
listens for connections on these sockets.  When a connection arrives,
it decides what component the socket corresponds to, and invokes this
component to handle the connection.  In this case, the connection is
bound to 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
after start-up, and starts the component binary.  Once the component
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 component itself.

@anchor{accept-style}
@cindex accept-style components
  The last flavor are @dfn{accept-style} components, which are handled
basically as @samp{inetd-style} ones, except that after binding to the
socket @command{pies} immediately starts the component, without
waiting for an actual connection.

  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.  The same
ordering applies when starting or stopping component dependencies, 

  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
* 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::
* Preprocessor::         Using preprocessor to improve the configuration.
@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.

@ignore
  Two or more adjacent quoted strings are concatenated, which gives
another way to split long strings over several lines to improve
readability.  The following fragment produces the same result as in the
example above:

@example
@group
"a long string may be"
" split over several lines"
@end group
@end example
@end ignore
@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
@subsection Using Preprocessor to Improve the Configuration.
@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}>
@itemx #include @var{file}
The contents of the file @var{file} is included.  There are three possible
use cases.

If @var{file} is an absolute file name, the named file is included.
An error message will be issued if it does not exist.

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 form with angle brackets searches for file in the
@dfn{include search path}, while the second one looks for it in the
current working directory first, and, if not found there, in the
include search path.  If the file is not found, an error message will
be issued.

@cindex include search path, preprocessor
@cindex include directories, preprocessor
@cindex preprocessor include search path
@anchor{include search path}
The include search path is:

@enumerate 1
@item
@xopindex{include-directory, described}
Any directories supplied with the @option{-I} (@option{--include-directory})
command line option.  These directories are scanned in the same order
as they appear in the command line.

@item @file{@var{prefix}/share/pies/@value{VERSION}/include}
@item @file{@var{prefix}/share/pies/include}
@end enumerate

@noindent
where @var{prefix} is the installation prefix.

@kwindex #include_once
@item #include_once <@var{file}>
@itemx #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
  The obtained material is then passed to @command{m4} for
preprocessing.  For a complete user manual, refer
to
@ifnothtml
@ref{Top, GNU M4 manual, GNU M4, m4, GNU M4 macro processor}.
@end ifnothtml
@ifhtml
@uref{http://www.gnu.org/software/m4/manual}.
@end ifhtml
In this subsection we assume the reader is sufficiently
acquainted with @command{m4} macro processor.

@flindex pp-setup
  The external preprocessor is invoked with @option{-s} flag, instructing
it to include line synchronization information in its output.  This
information is then used by the parser to display meaningful
diagnostic.  An initial set of macro definitions is supplied by the 
@file{pp-setup} file, located in
@file{@var{$prefix}/share/pies/@value{VERSION}/include} directory.

The default @file{pp-setup} file renames all @command{m4} built-in
macro names so they all start with the prefix @samp{m4_}.  This
is similar to GNU m4 @option{--prefix-builtin} options, but has an
advantage that it works with non-GNU @command{m4} implementations as
well.

The include path for @command{m4} is set as described above.

Additional preprocessor symbols may be defined and existing
definitions cancelled using the following command line options:

@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

Finally, the @command{m4} output is 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.
@end table

@node Component Statement
@section Component Statement
@kwindex component

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

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

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:

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

@table @asis
@item exec
@itemx respawn
  Define a @samp{respawn} component (@pxref{respawn}).  This is
the default.
  
@item inetd
@itemx nostartaccept
  Define an @samp{inetd-style} component (@pxref{inetd-style}).
  
@item pass
@itemx pass-fd 
  Define a @samp{meta1-style} component (@pxref{meta1-style}).
  
@item accept
  Define a @samp{accept-style} component (@pxref{accept-style}).
@end table

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

@table @asis
@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} program @var{name}
Full file name of the component binary.  This binary will be executed
(via @command{/bin/sh -c}) each time @command{pies} decides it needs
to start the component.

To supply command line arguments, use @code{command} statement.
@end deffn
  
@deffn {Config: component} command @var{string}
Command line for the program.  The argument should be just as
arguments normally are, starting with the name of the program.  The
latter may be different from the one specified to @code{program}
statement.  Its value will be available to the 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 @asis
@kwindex disable
@item disable
This component is disabled, i.e.@: @command{pies} will parse and
remember its settings, but will not start it.

@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 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.conf, wait}.

@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 internal
@item internal
This is an internal inetd component.  @xref{builtin}.

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

@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 siggroup
@item siggroup
This flag affects the behavior of @command{pies} when a stopped
process fails to terminate within a predefined timeout
(@pxref{shutdown-timeout}.  Normally @command{pies} would send the
@samp{SIGKILL} signal to such a process.  If this flag is set,
@command{pies} would send @samp{SIGKILL} to the process group of this
process instead.
@end table
@end deffn

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

@menu
* Prerequisites::
* Component Privileges::
* Resources::
* 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, @emph{defined before
this component}, or one of the following words:

@table @asis
@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 @var{string}.  The
argument 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} 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}.

@item -@var{name}
Unset the environment variable @var{name}.

@item -@var{name}=@var{val}
Unset the environment variable @var{name} only if its value is @var{val}.

@item @var{name}
Retain the environment variable @var{name}.

@item @var{name}=@var{value}
Define environment variable @var{name} to have given @var{value}.

@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.

@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. 
@end table
@end deffn

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

@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}.

  If the component exits with an exit code listed in @var{codes}
or is terminated on a signal listed in @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_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
  Output redirectors allow to redirect the 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 @asis
@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 a syslog channel.  The syslog priority is given by the
@var{channel} argument.  Allowed values are: @samp{emerg},
@samp{alert}, @samp{crit}, @samp{err}, @samp{warning}, @samp{notice},
@samp{info}, @samp{debug}.  The facility is inherited from the
@code{syslog} statement (@pxref{syslog}), or from the @code{facility}
statement (see below), if given.

Example:

@example
stderr syslog err;
@end example
@end table
@end deffn

@deffn {Config: component} facility @var{syslog-facility}
Specify the syslog facility to use in syslog redirectors.  Allowed 
@var{syslog-facility} values are: @samp{user}, @samp{daemon},
@samp{auth}, @samp{authpriv}, @samp{mail}, @samp{cron}, @samp{local0}
through @samp{local7} (all names case-insensitive), or a facility number.
@end deffn

@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 @asis
@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 @asis
@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 @asis
@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 @samp{exec | wait | accept | inetd | nostartaccept | pass-fd | pass};
  
  # @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{Override default syslog facility for this component.}
  facility @var{facility};
  # @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{Resources, env}.
  env @var{assignments};
  
  # @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 canonical_program_name @tab @samp{pies}
@item program_name @tab Program name of the @command{pies} binary.
@item package      @tab Package name (@samp{GNU Pies}).
@item instance     @tab Instance name (@pxref{instances}).
@item version      @tab Package version (@value{VERSION}).
@item component    @tab Name of the terminated component.
@item termination  @tab Termination cause (see below).
@item 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 @asis
@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 @{
  facility local1;
  stderr syslog 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.

@anchor{syslog}
@deffn {Config} syslog @{ @dots{} @}
This block statement configures logging via syslog.  It has two
substatements:
@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} 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), or a facility
number.
@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.
@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 @asis
@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 @asis
@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 @asis
@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 -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
@command{m4}.  The following options control this feature:

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

@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
include files.  @xref{include search path}.

@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.

  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 @asis
@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 @asis
@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 @asis
@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 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;
  facility mail;
  stderr syslog err;
  stdout syslog 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}.

@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{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.

@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
include files.  @xref{include search path}.

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

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

@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 @asis
@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{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.conf
@appendix @file{Inetd.conf} Format
@include inetd.texi

@node User-Group ACLs
@appendix User-Group ACLs
@include usr-acl.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

@bye
