kea/doc/guide/logging.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [
<!ENTITY mdash  "&#x2014;" >
]>

  <!-- Note: Please use the following terminology:
       - daemon - one process (e.g. kea-dhcp4)
       - component - one piece of code within a daemon (e.g. libdhcp or hooks)
       - server - currently equal to daemon, but the difference will be more
                  prominent once we add client or relay support
       - logger - one instance of isc::log::Logger
       - structure - an element in config file (e.g. "Dhcp4")

       Do not use:
       - module => daemon
    -->

<chapter id="logging">
  <title>Logging</title>

  <section>
    <title>Logging Configuration</title>
    <para>
      During its operation Kea may produce many messages. They differ in
      severity (some are more important than others) and source (some are
      produced by specific components, e.g. hooks). It is useful to understand
      which log messages are needed and which are not, and configure your
      logging appropriately. For example, debug level messages can be safely
      ignored in a typical deployment. They are, however, very useful when
      debugging a problem.
    </para>

    <para>
      The logging system in Kea is configured through the
      Logging section in your configuration
      file. All daemons (e.g. DHCPv4 and DHCPv6 servers) will use the
      configuration in the Logging section to see
      what should be logged and to where. This allows for sharing identical
      logging configuration between daemons.
    </para>

    <section>
      <title>Loggers</title>
      <para>
        Within Kea, a message is logged through an entity called a
        "logger". Different components log messages through different
        loggers, and each logger can be configured independently of
        one another. Some components, in particular the DHCP server
        processes, may use multiple loggers to log messages pertaining
        to different logical functions of the component. For example,
        the DHCPv4 server uses one logger for messages
        pertaining to packet reception and transmission, another
        logger for messages related to lease allocation and so on.
        Some of the libraries used by the Kea servers, e.g. libdhcpsrv,
        use their own loggers.
      </para>

      <para>
        Users implementing hooks libraries (code attached to the server at
        runtime) are responsible for creating the loggers used by those
        libraries. Such loggers should have unique names, different
        from the logger names used by Kea. In this way the
        messages output by the hooks library can be distinguished from
        messages issued by the core Kea code. Unique names also allow
        the loggers to be configured independently of loggers used
        by Kea.  Whenever it makes sense, a hook library can use multiple
        loggers to log messages pertaining to different logical parts
        of the library.
      </para>

      <para>
        In the Logging section of a configuration file you can specify the
        configuration for zero or more loggers (including loggers used by the
        proprietary hooks libraries). If there are no loggers specified, the
        code will use default values: these cause Kea to log messages of INFO
        severity or greater to standard output. There is also a small
        time window after Kea has been started, but has not yet read its
        configuration. Logging in this short period can be controlled
        using environment variables. For details, see <xref linkend="logging-during-startup"></xref>.
      </para>

      <para>
        The three main elements of a logger configuration are:
        <command>name</command> (the component that is generating the messages),
        the <command>severity</command> (what to log), and the
        <command>output_commands</command> (where to log).  There is also a
        <command>debuglevel</command> element, which is only relevant if
        debug-level logging has been selected.
      </para>

      <section>
        <title>name (string)</title>
        <para>
          Each logger in the system has a name, the name being that of the
          component binary file using it to log messages. For instance, if you
          want to configure logging for the DHCPv4 server, you add an entry
          for a logger named <quote>kea-dhcp4</quote>. This configuration will
          then be used by the loggers in the DHCPv4 server, and all the
          libraries used by it (unless a library defines its own logger and
          there is specific logger configuration that applies to that logger).
        </para>

        <para>
          When tracking down an issue with the server's operation, use of
          DEBUG logging is required to obtain the verbose output needed for
          problems diagnosis.  However, the high verbosity is likely to
          overwhelm the logging system in cases when the server
          is processing high volume traffic. To mitigate this problem, use
          can be made of the fact that Kea uses multiple loggers for different
          functional parts of the server and that each of these can be configured independently.
          If the user is reasonably confident that a problem originates
          in a specific function of the server, or that the problem is related
          to the specific type of operation, they may enable high verbosity
          only for the relevant logger, so limiting the debug messages
          to the required minimum.
        </para>

        <para>
          The loggers are associated with a particular library or binary
          of Kea. However, each library or binary may (and usually does)
          include multiple loggers. For example, the DHCPv4 server binary
          contains separate loggers for: packet parsing, for dropped packets,
          for callouts etc.
        </para>

        <para>
          The loggers form a hierarchy.  For each program in Kea, there is
          a "root" logger, named after the program (e.g. the root logger for
          kea-dhcp (the DHCPv4 server) is named kea-dhcp4.  All other loggers
          are children of this logger, and are named accordingly, e.g. the
          the allocation engine in the DHCPv4 server logs messages using
          a logger called kea-dhcp4.alloc-engine.
        </para>

        <para>
          This relationship is important as each child logger derives its
          default configuration from its parent root logger.
          In the typical case, the root logger configuration
          is the only logging configuration specified in the configuration
          file and so applies to all loggers. If an entry is made for
          a given logger, any attributes specified override those of
          the root logger, whereas any not specified are inherited from it.
        </para>

        <para>
          To illustrate this, suppose you are using the DHCPv4 server
          with the root logger <quote>kea-dhcp4</quote> logging at the
          INFO level. In order to enable DEBUG verbosity for the DHCPv4
          packet drops, you must create configuration entry for the
          logger called <quote>kea-dhcp4.bad-packets</quote> and specify
          severity DEBUG for this logger. All other configuration
          parameters may be omitted for this logger if the logger should
          use the default values specified in the root logger's
          configuration.
        </para>

        <!-- we don't support asterisk anymore.
        <para>
          One special case is that of a component name of <quote>*</quote>
          (asterisks), which is interpreted as <emphasis>any</emphasis>
          component. You can set global logging options by using this,
          including setting the logging configuration for a library
          that is used by multiple daemons (e.g. <quote>*.config</quote>
          specifies the configuration library code in whatever
          daemon is using it).
        </para> -->

        <para>
          If there are multiple logger specifications in the configuration
          that might match a particular logger, the specification with the
          more specific logger name takes precedence. For example, if there
          are entries for both <quote>kea-dhcp4</quote> and
          <quote>kea-dhcp4.dhcpsrv</quote>, the DHCPv4 server &mdash; and all
          libraries it uses that are not dhcpsrv &mdash; will log messages
          according to the configuration in the first entry
          (<quote>kea-dhcp4</quote>).
        </para>

        <para>
          Currently defined loggers are:
        </para>
        <itemizedlist>
          <listitem>
            <simpara>
              <command>kea-ctrl-agent</command> - the root logger for the
              Control Agent exposing RESTful control API. All components used
              by the Control Agent inherit the settings from this logger.
            </simpara>
          </listitem>

          <listitem>
            <simpara>
              <command>kea-ctrl-agent.http</command> - a logger which outputs
              log messages related to receiving, parsing and sending HTTP
              messages.
            </simpara>
          </listitem>

          <listitem>
            <simpara>
              <command>kea-dhcp4</command> - the root logger for the DHCPv4
              server. All components used by the DHCPv4 server inherit the
              settings from this logger.
            </simpara>
          </listitem>

          <listitem>
            <simpara>
              <command>kea-dhcp4.alloc-engine</command> - used by the lease
              allocation engine, which is responsible for managing leases in the
              lease database, i.e. create, modify and remove DHCPv4 leases as a
              result of processing messages from the clients.
            </simpara>
          </listitem>

          <listitem>
            <simpara>
              <command>kea-dhcp4.bad-packets</command> - used by the DHCPv4
              server daemon for logging inbound client packets that were dropped
              or to which the server responded with a DHCPNAK. It allows
              administrators to configure a separate log output that contains
              only packet drop and reject entries.
            </simpara>
          </listitem>

          <listitem>
            <simpara>
              <command>kea-dhcp4.callouts</command> - used to log messages
              pertaining to the callouts registration and execution for the
              particular hook point.
            </simpara>
          </listitem>

          <listitem>
            <simpara>
              <command>kea-dhcp4.commands</command> - used to log messages
              relating to the handling of commands received by the the DHCPv4
              server over the command channel.
            </simpara>
          </listitem>

          <listitem>
            <simpara>
              <command>kea-dhcp4.ddns</command> - used by the DHCPv4 server to
              log messages related to the Client FQDN and Hostname option
              processing. It also includes log messages related to the relevant
              DNS updates.
            </simpara>
          </listitem>

          <listitem>
            <simpara>
              <command>kea-dhcp4.dhcp4</command> - used by the DHCPv4 server
              daemon to log basic operations.
            </simpara>
          </listitem>

          <listitem>
            <simpara>
              <command>kea-dhcp4.dhcpsrv</command> - the base logger for the
              libdhcpsrv library.
            </simpara>
          </listitem>

          <listitem>
            <simpara>
              <command>kea-dhcp4.eval</command> - used to log messages relating
              to the client classification expression evaluation code.
            </simpara>
          </listitem>

          <listitem>
            <simpara>
              <command>kea-dhcp4.hooks</command> - used to log messages related
              to management of hooks libraries, e.g.  registration and
              deregistration of the libraries, and to the initialization of the
              callouts execution for various hook points within the DHCPv4
              server.
            </simpara>
          </listitem>

          <listitem>
            <simpara>
              <command>kea-dhcp4.hosts</command> - used within the libdhcpsrv
              and it logs messages related to the management of the DHCPv4 host
              reservations, i.e. retrieval of the reservations and adding new
              reservations.
            </simpara>
          </listitem>

          <listitem>
            <simpara>
              <command>kea-dhcp4.leases</command> - used by the DHCPv4 server to
              log messages related to the lease allocation.  The messages
              include detailed information about the allocated or offered
              leases, errors during the lease allocation etc.
            </simpara>
          </listitem>

          <listitem>
            <simpara>
              <command>kea-dhcp4.options</command> - used by the DHCPv4 server
              to log messages related to processing of the options in the DHCPv4
              messages, i.e. parsing options, encoding options into on-wire
              format and packet classification using options contained in the
              received packets.
            </simpara>
          </listitem>

          <listitem>
            <simpara>
              <command>kea-dhcp4.packets</command> - this logger is mostly used
              to log messages related to transmission of the DHCPv4 packets,
              i.e. packet reception and sending a response. Such messages
              include information about the source and destination IP addresses
              and interfaces used to transmit packets. The logger is also used
              to log messages related to subnet selection, as this selection is
              usually based on the IP addresses and/or interface names, which
              can be retrieved from the received packet, even before the DHCPv4
              message carried in the packet is parsed.
            </simpara>
          </listitem>

          <listitem>
            <simpara>
              <command>kea-dhcp6</command> - the root logger for the DHCPv6
              server. All components used by the DHCPv6 server inherit the
              settings from this logger if there is no specialized logger
              provided.
            </simpara>
          </listitem>

          <listitem>
            <simpara>
              <command>kea-dhcp6.alloc-engine</command> - used used by the lease
              allocation engine, which is responsible for managing leases in the
              lease database, i.e. create, modify and remove DHCPv6 leases as a
              result of processing messages from the clients.
            </simpara>
          </listitem>

          <listitem>
            <simpara>
              <command>kea-dhcp6.bad-packets</command> - used used by the DHCPv6
              server daemon for logging inbound client packets that were
              dropped.
            </simpara>
          </listitem>

          <listitem>
            <simpara>
              <command>kea-dhcp6.callouts</command> - used to log messages
              pertaining to the callouts registration and execution for the
              particular hook point.
            </simpara>
          </listitem>

          <listitem>
            <simpara>
              <command>kea-dhcp6.commands</command> - used to log messages
              relating to the handling of commands received by the the DHCPv6
              server over the command channel.
            </simpara>
          </listitem>

          <listitem>
            <simpara>
              <command>kea-dhcp6.ddns</command> - this logger is used by the
              DHCPv6 server to log messages related to the Client FQDN option
              processing. It also includes log messages related to the relevant
              DNS updates.
            </simpara>
          </listitem>

          <listitem>
            <simpara>
              <command>kea-dhcp6.dhcp6</command> - used DHCPv6 server daemon to
              log basic operations.
            </simpara>
          </listitem>

          <listitem>
            <simpara>
              <command>kea-dhcp6.dhcpsrv</command> - the base logger for the
              libdhcpsrv library.
            </simpara>
          </listitem>

          <listitem>
            <simpara>
              <command>kea-dhcp6.eval</command> - used to log messages relating
              to the client classification expression evaluation code.
            </simpara>
          </listitem>

          <listitem>
            <simpara>
              <command>kea-dhcp6.hooks</command> - this logger is used to log
              messages related to management of hooks libraries, e.g.
              registration and deregistration of the libraries, and to the
              initialization of the callouts execution for various hook points
              within the DHCPv6 server.
            </simpara>
          </listitem>

          <listitem>
            <simpara>
              <command>kea-dhcp6.hosts</command> - used within the libdhcpsrv
              and it logs messages related to the management of the DHCPv6 host
              reservations, i.e. retrieval of the reservations and adding new
              reservations.
            </simpara>
          </listitem>

          <listitem>
            <simpara>
              <command>kea-dhcp6.leases</command> - used by the DHCPv6 server to
              log messages related to the lease allocation.  The messages
              include detailed information about the allocated or offered
              leases, errors during the lease allocation etc.
            </simpara>
          </listitem>

          <listitem>
            <simpara>
              <command>kea-dhcp6.options</command> - used by the DHCPv6 server
              to log messages related to processing of the options in the DHCPv6
              messages, i.e. parsing options, encoding options into on-wire
              format and packet classification using options contained in the
              received packets.
            </simpara>
          </listitem>

          <listitem>
            <simpara>
              <command>kea-dhcp6.packets</command> - this logger is mostly used
              to log messages related to transmission of the DHCPv6 packets,
              i.e. packet reception and sending a response. Such messages
              include the information about the source and destination IP
              addresses and interfaces used to transmit packets. This logger is
              also used to log messages related to subnet selection, as this
              selection is usually based on the IP addresses and/or interface
              names, which can be retrieved from the received packet, even
              before the DHCPv6 message carried in the packet is parsed.
            </simpara>
          </listitem>

          <listitem>
            <simpara>
              <command>kea-dhcp-ddns</command> - the root logger for the
              kea-dhcp-ddns daemon. All components used by this daemon inherit
              the settings from this logger if there is no specialized logger
              provided.
            </simpara>
          </listitem>

          <listitem>
            <simpara>
              <command>kea-dhcp-ddns.dctl</command> - the logger used by the
              kea-dhcp-ddns daemon for logging basic information about the
              process, received signals and triggered reconfigurations.
            </simpara>
          </listitem>

          <listitem>
            <simpara>
              <command>kea-dhcp-ddns.dhcpddns</command> - the logger used by the
              kea-dhcp-ddns daemon for logging events related to DDNS operations.
            </simpara>
          </listitem>

          <listitem>
            <simpara>
              <command>kea-dhcp-ddns.dhcp-to-d2</command> - used by the
              kea-dhcp-ddns daemon for logging information about events dealing
              with receiving messages from the DHCP servers and adding them to
              the queue for processing.
            </simpara>
          </listitem>

          <listitem>
            <simpara>
              <command>kea-dhcp-ddns.d2-to-dns</command> - used by the
              kea-dhcp-ddns daemon for logging information about events dealing
              with sending and receiving messages with the DNS servers.
            </simpara>
          </listitem>
        </itemizedlist>

        <para>
          Note that user-defined hook libraries should not use any of those
          loggers but should define new loggers with names that correspond to
          the libraries using them. Suppose that the user created the library
          called <quote>libpacket-capture</quote> to dump packets received and
          transmitted by the server to the file. The appropriate name for the
          logger could be <command>kea-dhcp4.packet-capture</command>. (Note
          that the hook library implementor only specifies the second part of
          this name, i.e. <quote>packet-capture</quote>. The first part is a
          root logger name and is prepended by the Kea logging system.) It is
          also important to note that since this new logger is a child of a root
          logger, it inherits the configuration from the root logger, something
          that can be overridden by an entry in the configuration file.
        </para>

        <para>
          The list of loggers above excludes any loggers implemented in hooks
          libraries. Please consult the documentation for the libraries for the
          names of the loggers they define.
        </para>

        <para>
          Additional loggers may be defined in future versions of Kea. The
          easiest way to find out the logger name is to configure all logging to
          go to a single destination and look for specific logger names. See
          <xref linkend="logging-message-format"/> for details.
        </para>
      </section>

      <section>
        <title>severity (string)</title>
        <para>
          This specifies the category of messages logged.  Each message is
          logged with an associated severity which may be one of the following
          (in descending order of severity):
        </para>

        <itemizedlist>
          <listitem>
            <simpara>
              FATAL - associated with messages generated by a condition that is
              so serious that the server cannot continue executing.
            </simpara>
          </listitem>

          <listitem>
            <simpara>
              ERROR- associated with messages generated by an error condition.
              The server will continue executing, but the results may not be as
              expected.
            </simpara>
          </listitem>

          <listitem>
            <simpara>
              WARN - indicates an out of the ordinary condition.  However, the
              server will continue executing normally.
            </simpara>
          </listitem>

          <listitem>
            <simpara>
              INFO - an informational message marking some event.
            </simpara>
          </listitem>

          <listitem>
            <simpara>
              DEBUG - messages produced for debugging purposes.
            </simpara>
          </listitem>
        </itemizedlist>

        <para>
          When the severity of a logger is set to one of these values, it will
          only log messages of that severity and above (e.g. setting the logging
          severity to INFO will log INFO, WARN, ERROR and FATAL messages).  The
          severity may also be set to NONE, in which case all messages from that
          logger are inhibited.
        </para>

        <note>
          <para>
            The keactrl tool, described in <xref linkend="keactrl"/>, can be
            configured to start the servers in the verbose mode. If this is the
            case, the settings of the logging severity in the configuration file
            will have no effect, i.e. the servers will use logging severity of
            DEBUG regardless of the logging settings specified in the
            configuration file. If you need to control severity via
            configuration file, please make sure that the
            <parameter>kea_verbose</parameter> value is set to "no" within the
            keactrl configuration.
          </para>
        </note>
      </section>

      <section>
        <title>debuglevel (integer)</title>
        <para>
          When a logger's severity is set to DEBUG, this value specifies what
          level of debug messages should be printed. It ranges from 0 (least
          verbose) to 99 (most verbose). If severity for the logger is not
          DEBUG, this value is ignored.
        </para>
      </section>

      <section>
        <title>output_options (list)</title>
        <para>
          Each logger can have zero or more <option>output_options</option>.
          These specify where log messages are sent. These are explained in
          detail below.
        </para>

        <section>
          <title>output (string)</title>
          <para>
            This value determines the type of output. There are several special
            values allowed here: <command>stdout</command> (messages are printed
            on standard output), <command>stderr</command> (messages are printed
            on stderr), <command>syslog</command> (messages are logged to syslog
            using default name, <command>syslog:name</command> (messages are
            logged to syslog using specified name). Any other value is
            interpreted as a filename to which messages should be written.
          </para>
        </section>

        <section>
          <title>flush (true of false)</title>
          <para>
            Flush buffers after each log message. Doing this will reduce
            performance but will ensure that if the program terminates
            abnormally, all messages up to the point of termination are output.
            The default is "true".
          </para>
        </section>

        <section>
          <title>maxsize (integer)</title>
          <para>
            Only relevant when the destination is a file. This is maximum size
            in bytes that a log file may reach.  When the maximum size is
            reached, the file is renamed and a new file opened. For example,
            a ".1" is appended to the name &mdash; if a ".1" file exists, it
            is renamed ".2", etc. This is referred to as rotation.
          </para>
          <para>
            The default value is 10240000 (10MB).  The smallest value that may
            be specified without disabling rotation is 204800. Any value less than
            this, including 0, disables rotation.
          </para>
          <note>
            <simpara>
              Due to a limitation of the underlying logging library (log4cplus),
              rolling over the log files (from ".1" to ".2", etc) may show odd
              results: There can be multiple small files at the timing of roll
              over.  This can happen when multiple processes try to roll over
              the files simultaneously.  Version 1.1.0 of log4cplus solved this
              problem, so if this version or later of log4cplus is used to
              build Kea, it should not happen.  Even for older versions it is
              normally expected to happen rarely unless the log messages are
              produced very frequently by multiple different processes.
            </simpara>
          </note>
        </section>

        <section>
          <title>maxver (integer)</title>
          <para>
            Only relevant when the destination is file and rotation is enabled
            (i.e. maxsize is large enough).  This is maximum number of rotated
            versions that will be kept. Once that number of files has been
            reached, the oldest file, "log-name.maxver", will be discarded
            each time the log rotates. In other words, at most there will be
            the active log file plus maxver rotated files.  The minimum and
            default value is 1.
          </para>
        </section>
      </section>

      <section>
        <title>Example Logger Configurations</title>
        <para>
          In this example we want to set the global logging to write to the
          console using standard output.
        </para>

<screen><userinput>"Logging": {
    "loggers": [
        {
            "name": "kea-dhcp4",
            "output_options": [
                {
                    "output": "stdout"
                }
            ],
            "severity": "WARN"
        }
    ]
}</userinput> </screen>

        <para>
          In this second example, we want to store debug log messages in a file
          that is at most 2MB and keep up to 8 copies of old logfiles.  Once the
          logfile grows to 2MB, it will be renamed and a new file file be
          created.
        </para>

<screen><userinput>"Logging": {
    "loggers": [
        {
            "name": "kea-dhcp6",
            "output_options": [
                {
                    "output": "/var/log/kea-debug.log",
                    "maxver": 8,
                    "maxsize": 204800,
                    "flush": true
                }
            ],
            "severity": "DEBUG",
            "debuglevel": 99
        }
   ]
}</userinput></screen>
      </section>

    </section>

    <section id="logging-message-format">
      <title>Logging Message Format</title>
      <para>
        Each message written  to the configured logging destinations comprises a
        number of components that identify the origin of the message and, if the
        message indicates a problem, information about the problem that may be
        useful in fixing it.
      </para>

      <para>
        Consider the message below logged to a file:

<screen>2014-04-11 12:58:01.005 INFO  [kea-dhcp4.dhcpsrv/27456]
    DHCPSRV_MEMFILE_DB opening memory file lease database: type=memfile universe=4</screen>
      </para>

      <para>
        Note: the layout of messages written to the system logging file (syslog)
        may be slightly different.  This message has been split across two lines
        here for display reasons; in the logging file, it will appear on one
        line.
      </para>

      <para>
        The log message comprises a number of components:

       <variablelist>
         <varlistentry>
           <term>2014-04-11 12:58:01.005</term>
<!-- TODO: timestamp repeated even if using syslog? -->
           <listitem>
             <para>
               The date and time at which the message was generated.
              </para>
            </listitem>
          </varlistentry>

          <varlistentry>
            <term>INFO</term>
            <listitem>
              <para>
                The severity of the message.
              </para>
            </listitem>
          </varlistentry>

          <varlistentry>
            <term>[kea-dhcp4.dhcpsrv/27456]</term>
            <listitem>
              <para>
                The source of the message.  This comprises two elements: the Kea
                process generating the message (in this case,
                <command>kea-dhcp4</command>) and the component within the
                program from which the message originated
                (<command>dhcpsrv</command>, which is the name of the common
                library used by DHCP server implementations). The number after
                the slash is a process id (pid).
              </para>
            </listitem>
          </varlistentry>

          <varlistentry>
            <term>DHCPSRV_MEMFILE_DB</term>
            <listitem>
              <para>
                The message identification.  Every message in Kea has a unique
                identification, which can be used as an index into the
                <ulink url="kea-messages.html"><citetitle>Kea Messages
                Manual</citetitle></ulink>
                (<ulink url="http://kea.isc.org/docs/kea-messages.html" />)
                from which more information can be obtained.
              </para>
            </listitem>
          </varlistentry>

          <varlistentry>
            <term>opening memory file lease database: type=memfile universe=4</term>
            <listitem>
              <para>
                A brief description.  Within this text, information relating to
                the condition that caused the message to be logged will be
                included.  In this example, the information is logged that the
                in-memory lease database backend will be used to store DHCP
                leases.
              </para>
            </listitem>
          </varlistentry>
        </variablelist>
      </para>
    </section>

    <section id="logging-during-startup">
      <title>Logging During Kea Startup</title>
      <para>
        The logging configuration is specified in the configuration file.
        However, when Kea starts, the file is not read until some way into the
        initialization process.  Prior to that, the logging settings are set to
        default values, although it is possible to modify some aspects of the
        settings by means of environment variables. Note that in the absence of
        any logging configuration in the configuration file, the settings of
        (possibly modified) default configuration will persist while the program
        is running.
      </para>
      <para>
        The following environment variables can be used to control the behavior
        of logging during startup:
      </para>

      <variablelist>
        <varlistentry>
          <term>KEA_LOCKFILE_DIR</term>
          <listitem>
            <para>
              Specifies a directory where the logging system should create its
              lock file. If not specified, it is
              <replaceable>prefix</replaceable>/var/run/kea, where
              <replaceable>prefix</replaceable> defaults to /usr/local.  This
              variable must not end with a slash. There is one special value:
              "none", which instructs Kea to not create lock file at all. This
              may cause issues if several processes log to the same file.
            </para>
          </listitem>
        </varlistentry>

        <varlistentry>
          <term>KEA_LOGGER_DESTINATION</term>
          <listitem>
            <para>
              Specifies logging output. There are several special values.
              <variablelist>
                <varlistentry>
                  <term>stdout</term>
                  <listitem>
                    <para>
                      Log to standard output.
                    </para>
                  </listitem>
                </varlistentry>

                <varlistentry>
                  <term>stderr</term>
                  <listitem>
                    <para>
                      Log to standard error.
                    </para>
                  </listitem>
                </varlistentry>

                <varlistentry>
                  <term>syslog<optional>:<replaceable>fac</replaceable></optional></term>
                  <listitem>
                    <para>
                      Log via syslog. The optional
                      <replaceable>fac</replaceable> (which is separated from
                      the word "syslog" by a colon) specifies the facility to be
                      used for the log messages. Unless specified, messages will
                      be logged using the facility "local0".
                    </para>
                  </listitem>
                </varlistentry>
              </variablelist>
              Any other value is treated as a name of the output file. If not
              specified otherwise, Kea will log to standard output.
            </para>
          </listitem>
        </varlistentry>
      </variablelist>
    </section>
  </section>
</chapter>