\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-2019 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 < @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 ::= ::= | "or" ::= | "and" ::= | "not" | "(" ")" ::= "all" | "active" | ::= "type" | "mode" | "status" | "component" ::= | ::= | ::= "A" - "Z" | "a" - "z" | "0" - "9" | "_" | "." | "*" | ":" | "@@" | "[" | "]" | "-" | "/" ::= """ """ ::= | ::= | "\\" | "\"" @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{no-init} @item --no-init Don't assume @dfn{init mode} (@pxref{Init Process} if running with PID 1. This option is useful if you intend to run @command{pies} as a process manager in a docker container. @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