move man pages to appropriate directories

1 files changed, 0 insertions, 313 deletions

diff --git a/man/systemd.timer.xml b/man/systemd.timer.xml
deleted file mode 100644
index 0fa95e97a8..0000000000
--- a/man/systemd.timer.xml
+++ /dev/null
@@ -1,313 +0,0 @@
-<?xml version='1.0'?> <!--*- Mode: nxml; nxml-child-indent: 2; indent-tabs-mode: nil -*-->
-<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
-
-<!--
-  This file is part of systemd.
-
-  Copyright 2010 Lennart Poettering
-
-  systemd is free software; you can redistribute it and/or modify it
-  under the terms of the GNU Lesser General Public License as published by
-  the Free Software Foundation; either version 2.1 of the License, or
-  (at your option) any later version.
-
-  systemd is distributed in the hope that it will be useful, but
-  WITHOUT ANY WARRANTY; without even the implied warranty of
-  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-  Lesser General Public License for more details.
-
-  You should have received a copy of the GNU Lesser General Public License
-  along with systemd; If not, see <http://www.gnu.org/licenses/>.
--->
-
-<refentry id="systemd.timer">
-  <refentryinfo>
-    <title>systemd.timer</title>
-    <productname>systemd</productname>
-
-    <authorgroup>
-      <author>
-        <contrib>Developer</contrib>
-        <firstname>Lennart</firstname>
-        <surname>Poettering</surname>
-        <email>lennart@poettering.net</email>
-      </author>
-    </authorgroup>
-  </refentryinfo>
-
-  <refmeta>
-    <refentrytitle>systemd.timer</refentrytitle>
-    <manvolnum>5</manvolnum>
-  </refmeta>
-
-  <refnamediv>
-    <refname>systemd.timer</refname>
-    <refpurpose>Timer unit configuration</refpurpose>
-  </refnamediv>
-
-  <refsynopsisdiv>
-    <para><filename><replaceable>timer</replaceable>.timer</filename></para>
-  </refsynopsisdiv>
-
-  <refsect1>
-    <title>Description</title>
-
-    <para>A unit configuration file whose name ends in
-    <literal>.timer</literal> encodes information about a timer
-    controlled and supervised by systemd, for timer-based
-    activation.</para>
-
-    <para>This man page lists the configuration options specific to
-    this unit type. See
-    <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
-    for the common options of all unit configuration files. The common
-    configuration items are configured in the generic [Unit] and
-    [Install] sections. The timer specific configuration options are
-    configured in the [Timer] section.</para>
-
-    <para>For each timer file, a matching unit file must exist,
-    describing the unit to activate when the timer elapses. By
-    default, a service by the same name as the timer (except for the
-    suffix) is activated. Example: a timer file
-    <filename>foo.timer</filename> activates a matching service
-    <filename>foo.service</filename>. The unit to activate may be
-    controlled by <varname>Unit=</varname> (see below).</para>
-
-    <para>Note that in case the unit to activate is already active at the time the timer elapses it is not restarted,
-    but simply left running. There is no concept of spawning new service instances in this case. Due to this, services
-    with <varname>RemainAfterExit=</varname> set (which stay around continously even after the service's main process
-    exited) are usually not suitable for activation via repetitive timers, as they will only be activated once, and
-    then stay around forever.</para>
-  </refsect1>
-
-  <refsect1>
-    <title>Automatic Dependencies</title>
-
-    <para>Timer units automatically gain a <varname>Before=</varname>
-    dependency on the service they are supposed to activate.</para>
-
-    <para>Unless <varname>DefaultDependencies=</varname> in the <literal>[Unit]</literal> section is set to
-    <option>false</option>, all timer units will implicitly have dependencies of type <varname>Requires=</varname> and
-    <varname>After=</varname> on <filename>sysinit.target</filename>, a dependency of type <varname>Before=</varname>
-    on <filename>timers.target</filename>, as well as <varname>Conflicts=</varname> and <varname>Before=</varname> on
-    <filename>shutdown.target</filename> to ensure that they are stopped cleanly prior to system shutdown.  Timer units
-    with at least one <varname>OnCalendar=</varname> directive will have an additional <varname>After=</varname>
-    dependency on <filename>timer-sync.target</filename> to avoid being started before the system clock has been
-    correctly set. Only timer units involved with early boot or late system shutdown should disable the
-    <varname>DefaultDependencies=</varname> option.</para>
-  </refsect1>
-
-  <refsect1>
-    <title>Options</title>
-
-    <para>Timer files must include a [Timer] section, which carries
-    information about the timer it defines. The options specific to
-    the [Timer] section of timer units are the following:</para>
-
-    <variablelist class='unit-directives'>
-      <varlistentry>
-        <term><varname>OnActiveSec=</varname></term>
-        <term><varname>OnBootSec=</varname></term>
-        <term><varname>OnStartupSec=</varname></term>
-        <term><varname>OnUnitActiveSec=</varname></term>
-        <term><varname>OnUnitInactiveSec=</varname></term>
-
-        <listitem><para>Defines monotonic timers relative to different
-        starting points: <varname>OnActiveSec=</varname> defines a
-        timer relative to the moment the timer itself is activated.
-        <varname>OnBootSec=</varname> defines a timer relative to when
-        the machine was booted up. <varname>OnStartupSec=</varname>
-        defines a timer relative to when systemd was first started.
-        <varname>OnUnitActiveSec=</varname> defines a timer relative
-        to when the unit the timer is activating was last activated.
-        <varname>OnUnitInactiveSec=</varname> defines a timer relative
-        to when the unit the timer is activating was last
-        deactivated.</para>
-
-        <para>Multiple directives may be combined of the same and of
-        different types. For example, by combining
-        <varname>OnBootSec=</varname> and
-        <varname>OnUnitActiveSec=</varname>, it is possible to define
-        a timer that elapses in regular intervals and activates a
-        specific service each time.</para>
-
-        <para>The arguments to the directives are time spans
-        configured in seconds. Example: "OnBootSec=50" means 50s after
-        boot-up. The argument may also include time units. Example:
-        "OnBootSec=5h 30min" means 5 hours and 30 minutes after
-        boot-up. For details about the syntax of time spans, see
-        <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
-
-        <para>If a timer configured with <varname>OnBootSec=</varname>
-        or <varname>OnStartupSec=</varname> is already in the past
-        when the timer unit is activated, it will immediately elapse
-        and the configured unit is started. This is not the case for
-        timers defined in the other directives.</para>
-
-        <para>These are monotonic timers, independent of wall-clock
-        time and timezones. If the computer is temporarily suspended,
-        the monotonic clock stops too.</para>
-
-        <para>If the empty string is assigned to any of these options,
-        the list of timers is reset, and all prior assignments will
-        have no effect.</para>
-
-        <para>Note that timers do not necessarily expire at the
-        precise time configured with these settings, as they are
-        subject to the <varname>AccuracySec=</varname> setting
-        below.</para></listitem>
-
-      </varlistentry>
-
-      <varlistentry>
-        <term><varname>OnCalendar=</varname></term>
-
-        <listitem><para>Defines realtime (i.e. wallclock) timers with
-        calendar event expressions. See
-        <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry>
-        for more information on the syntax of calendar event
-        expressions. Otherwise, the semantics are similar to
-        <varname>OnActiveSec=</varname> and related settings.</para>
-
-        <para>Note that timers do not necessarily expire at the
-        precise time configured with this setting, as it is subject to
-        the <varname>AccuracySec=</varname> setting
-        below.</para></listitem>
-      </varlistentry>
-
-      <varlistentry>
-        <term><varname>AccuracySec=</varname></term>
-
-        <listitem><para>Specify the accuracy the timer shall elapse
-        with. Defaults to 1min. The timer is scheduled to elapse
-        within a time window starting with the time specified in
-        <varname>OnCalendar=</varname>,
-        <varname>OnActiveSec=</varname>,
-        <varname>OnBootSec=</varname>,
-        <varname>OnStartupSec=</varname>,
-        <varname>OnUnitActiveSec=</varname> or
-        <varname>OnUnitInactiveSec=</varname> and ending the time
-        configured with <varname>AccuracySec=</varname> later. Within
-        this time window, the expiry time will be placed at a
-        host-specific, randomized, but stable position that is
-        synchronized between all local timer units. This is done in
-        order to optimize power consumption to suppress unnecessary
-        CPU wake-ups. To get best accuracy, set this option to
-        1us. Note that the timer is still subject to the timer slack
-        configured via
-        <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>'s
-        <varname>TimerSlackNSec=</varname> setting. See
-        <citerefentry><refentrytitle>prctl</refentrytitle><manvolnum>2</manvolnum></citerefentry>
-        for details. To optimize power consumption, make sure to set
-        this value as high as possible and as low as
-        necessary.</para></listitem>
-      </varlistentry>
-
-      <varlistentry>
-        <term><varname>RandomizedDelaySec=</varname></term>
-
-        <listitem><para>Delay the timer by a randomly selected, evenly
-        distributed amount of time between 0 and the specified time
-        value. Defaults to 0, indicating that no randomized delay
-        shall be applied. Each timer unit will determine this delay
-        randomly each time it is started, and the delay will simply be
-        added on top of the next determined elapsing time. This is
-        useful to stretch dispatching of similarly configured timer
-        events over a certain amount time, to avoid that they all fire
-        at the same time, possibly resulting in resource
-        congestion. Note the relation to
-        <varname>AccuracySec=</varname> above: the latter allows the
-        service manager to coalesce timer events within a specified
-        time range in order to minimize wakeups, the former does the
-        opposite: it stretches timer events over a time range, to make
-        it unlikely that they fire simultaneously. If
-        <varname>RandomizedDelaySec=</varname> and
-        <varname>AccuracySec=</varname> are used in conjunction, first
-        the randomized delay is added, and then the result is
-        possibly further shifted to coalesce it with other timer
-        events happening on the system. As mentioned above
-        <varname>AccuracySec=</varname> defaults to 1min and
-        <varname>RandomizedDelaySec=</varname> to 0, thus encouraging
-        coalescing of timer events. In order to optimally stretch
-        timer events over a certain range of time, make sure to set
-        <varname>RandomizedDelaySec=</varname> to a higher value, and
-        <varname>AccuracySec=1us</varname>.</para></listitem>
-      </varlistentry>
-
-      <varlistentry>
-        <term><varname>Unit=</varname></term>
-
-        <listitem><para>The unit to activate when this timer elapses.
-        The argument is a unit name, whose suffix is not
-        <literal>.timer</literal>. If not specified, this value
-        defaults to a service that has the same name as the timer
-        unit, except for the suffix. (See above.) It is recommended
-        that the unit name that is activated and the unit name of the
-        timer unit are named identically, except for the
-        suffix.</para></listitem>
-      </varlistentry>
-
-
-      <varlistentry>
-        <term><varname>Persistent=</varname></term>
-
-        <listitem><para>Takes a boolean argument. If true, the time
-        when the service unit was last triggered is stored on disk.
-        When the timer is activated, the service unit is triggered
-        immediately if it would have been triggered at least once
-        during the time when the timer was inactive. This is useful to
-        catch up on missed runs of the service when the machine was
-        off. Note that this setting only has an effect on timers
-        configured with <varname>OnCalendar=</varname>. Defaults
-        to <varname>false</varname>.
-        </para></listitem>
-      </varlistentry>
-
-      <varlistentry>
-        <term><varname>WakeSystem=</varname></term>
-
-        <listitem><para>Takes a boolean argument. If true, an elapsing
-        timer will cause the system to resume from suspend, should it
-        be suspended and if the system supports this. Note that this
-        option will only make sure the system resumes on the
-        appropriate times, it will not take care of suspending it
-        again after any work that is to be done is finished. Defaults
-        to <varname>false</varname>.</para></listitem>
-      </varlistentry>
-
-      <varlistentry>
-        <term><varname>RemainAfterElapse=</varname></term>
-
-        <listitem><para>Takes a boolean argument. If true, an elapsed
-        timer will stay loaded, and its state remains queriable. If
-        false, an elapsed timer unit that cannot elapse anymore is
-        unloaded. Turning this off is particularly useful for
-        transient timer units that shall disappear after they first
-        elapse. Note that this setting has an effect on repeatedly
-        starting a timer unit that only elapses once: if
-        <varname>RemainAfterElapse=</varname> is on, it will not be
-        started again, and is guaranteed to elapse only once. However,
-        if <varname>RemainAfterElapse=</varname> is off, it might be
-        started again if it is already elapsed, and thus be triggered
-        multiple times. Defaults to
-        <varname>yes</varname>.</para></listitem>
-      </varlistentry>
-    </variablelist>
-  </refsect1>
-
-  <refsect1>
-      <title>See Also</title>
-      <para>
-        <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
-        <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
-        <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
-        <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
-        <citerefentry><refentrytitle>systemd.time</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
-        <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
-        <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
-        <citerefentry><refentrytitle>prctl</refentrytitle><manvolnum>2</manvolnum></citerefentry>
-      </para>
-  </refsect1>
-
-</refentry>