chiark / gitweb /
main: replace --running-as= by --session and --system do mimic related tools and...
[elogind.git] / man / systemd.xml
index 2775672..d19094c 100644 (file)
                 are mostly equivalent when invoked from normal login sessions. See
                 <citerefentry><refentrytitle>telinit</refentrytitle><manvolnum>8</manvolnum></citerefentry>
                 for more information.</para>
+
+                <para>When run as system instance, systemd interprets
+                the configuration file
+                <filename>system.conf</filename>, otherwise
+                <filename>session.conf</filename>. See
+                <citerefentry><refentrytitle>systemd.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
+                for more information.</para>
         </refsect1>
 
         <refsect1>
                                 text and exits.</para></listitem>
                         </varlistentry>
                         <varlistentry>
-                                <term><option>--unit=</option></term>
-
-                                <listitem><para>Set default unit to
-                                activate on startup. If not specified
-                                defaults to
-                                <filename>default.target</filename>.</para></listitem>
-                        </varlistentry>
-                        <varlistentry>
-                                <term><option>--running-as=</option></term>
-
-                                <listitem><para>Tell systemd to run in
-                                a particular mode. Argument is one of
-                                <option>system</option>,
-                                <option>session</option>. Normally it
-                                should not be necessary to pass this
-                                option, as systemd automatically
-                                detects the mode it is started
-                                in. This call is hence of little use
-                                except for
-                                debugging.</para></listitem>
-                        </varlistentry>
-                        <varlistentry>
                                 <term><option>--test</option></term>
 
                                 <listitem><para>Determine startup
                                 definition files.</para></listitem>
                         </varlistentry>
                         <varlistentry>
-                                <term><option>--confirm-spawn</option></term>
-
-                                <listitem><para>Ask for confirmation when spawning processes.</para></listitem>
-                        </varlistentry>
-                        <varlistentry>
                                 <term><option>--introspect=</option></term>
 
                                 <listitem><para>Extract D-Bus
                                 interface introspection data. This is
-                                mostly useful at build at install time
+                                mostly useful at install time
                                 to generate data suitable for the
                                 D-Bus interfaces
                                 repository. Optionally the interface
                                 is dumped.</para></listitem>
                         </varlistentry>
                         <varlistentry>
+                                <term><option>--unit=</option></term>
+
+                                <listitem><para>Set default unit to
+                                activate on startup. If not specified
+                                defaults to
+                                <filename>default.target</filename>.</para></listitem>
+                        </varlistentry>
+                        <varlistentry>
+                                <term><option>--system</option></term>
+                                <term><option>--session</option></term>
+
+                                <listitem><para>Tell systemd to run a
+                                system instance (resp. session
+                                instance), even if the process ID is
+                                not 1 (resp. is 1), i.e. system is not
+                                (resp. is) run as init process.
+                                Normally it should not be necessary to
+                                pass these options, as systemd
+                                automatically detects the mode it is
+                                started in. These options are hence of
+                                little use except for
+                                debugging.</para></listitem>
+                        </varlistentry>
+                        <varlistentry>
+                                <term><option>--dump-core</option></term>
+
+                                <listitem><para>Dump core on crash. This switch has no effect when run as session instance.</para></listitem>
+                        </varlistentry>
+                        <varlistentry>
+                                <term><option>--crash-shell</option></term>
+
+                                <listitem><para>Run shell on crash. This switch has no effect when run as session instance.</para></listitem>
+                        </varlistentry>
+                        <varlistentry>
+                                <term><option>--confirm-spawn</option></term>
+
+                                <listitem><para>Ask for confirmation when spawning processes. This switch has no effect when run as session instance.</para></listitem>
+                        </varlistentry>
+                        <varlistentry>
+                                <term><option>--show-status</option></term>
+
+                                <listitem><para>Show terse service status information while booting. This switch has no effect when run as session instance.</para></listitem>
+                        </varlistentry>
+                        <varlistentry>
+                                <term><option>--log-target=</option></term>
+
+                                <listitem><para>Set log
+                                target. Argument must be one of
+                                <option>console</option>,
+                                <option>syslog</option>,
+                                <option>kmsg</option>,
+                                <option>syslog-or-kmsg</option>,
+                                <option>null</option>.</para></listitem>
+                        </varlistentry>
+                        <varlistentry>
                                 <term><option>--log-level=</option></term>
 
                                 <listitem><para>Set log level. As
                                 <option>debug</option>.</para></listitem>
                         </varlistentry>
                         <varlistentry>
-                                <term><option>--log-target=</option></term>
-
-                                <listitem><para>Set log
-                                target. Argument must be one of
-                                <option>console</option>,
-                                <option>syslog</option>,
-                                <option>kmsg</option>,
-                                <option>syslog-or-kmsg</option>,
-                                <option>null</option>.</para></listitem>
-                        </varlistentry>
-                        <varlistentry>
                                 <term><option>--log-color=</option></term>
 
                                 <listitem><para>Highlight important
         </refsect1>
 
         <refsect1>
+                <title>Concepts</title>
+
+                <para>systemd provides a dependency system between
+                various entities called "units". Units encapsulate
+                various objects that are relevant for system boot-up
+                and maintainance. The majority of units are configured
+                in unit configuration files, whose syntax and basic
+                set of options is described in
+                <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+                however some are created automatically from other
+                configuration or dynamically from system state. Units
+                may be active (meaning started, bound, plugged in, ...
+                depending on the unit type), or inactive (meaning
+                stopped, unbound, unplugged, ...), as well as in the
+                process of being activated or deactivated,
+                i.e. between the two states. The following unit types
+                are available:</para>
+
+                <orderedlist>
+                        <listitem><para>Service units, which control
+                        daemons and the processes they consist of. For
+                        details see
+                        <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
+
+                        <listitem><para>Socket units, which
+                        encapsulate local IPC or network sockets in
+                        the system, useful for socket-based
+                        activation. For details about socket units see
+                        <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+                        for details on socket-based activation and
+                        other forms of activation, see
+                        <citerefentry><refentrytitle>daemon</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para></listitem>
+
+                        <listitem><para>Target units are useful to
+                        group units, or provide well-known
+                        synchronization points during boot-up, see
+                        <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
+
+                        <listitem><para>Device units expose kernel
+                        devices in systemd and may be used to
+                        implement device-based activation. For details
+                        see
+                        <citerefentry><refentrytitle>systemd.device</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
+
+                        <listitem><para>Mount units control mount
+                        points in the file system, for details see
+                        <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
+
+                        <listitem><para>Automount units provide
+                        automount capabilities, for on-demand mounting
+                        of file systems as well as parallelized
+                        boot-up. See
+                        <citerefentry><refentrytitle>systemd.automount</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
+
+                        <listitem><para>Snapshot units can be used to
+                        temporarily save the state of the set of
+                        systemd units, which later may be restored by
+                        activating the saved snapshot unit. For more
+                        information see
+                        <citerefentry><refentrytitle>systemd.automount</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
+
+                        <listitem><para>Timer units are useful for
+                        triggering activation of other units based on
+                        timers. You may find details in
+                        <citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
+
+                        <listitem><para>Swap units are very similar to
+                        mount units and encapsulated memory swap
+                        partitions or files of the operating
+                        systemd. They are described in <citerefentry><refentrytitle>systemd.swap</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
+
+                        <listitem><para>Path units may be used
+                        to activate other services when file system
+                        objects change or are modified. See
+                        <citerefentry><refentrytitle>systemd.path</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
+
+                </orderedlist>
+
+                <para>Units are named as their configuration
+                files. Some units have special semantics. A detailed
+                list you may find in
+                <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
+
+                <para>On boot systemd activates the target unit
+                <filename>default.target</filename> whose job is to
+                activate on-boot services and other on-boot units by
+                pulling them in via dependencies. Usually the unit
+                name is just an alias (symlink) for either
+                <filename>graphical.target</filename> (for
+                fully-featured boots into the UI) or
+                <filename>multi-user.target</filename> (for limited
+                console-only boots for use in embedded or server
+                environments, or similar; a subset of
+                graphical.target). However it is at the discretion of
+                the administrator to configure it as an alias to any
+                other target unit. See
+                <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+                for details about these target units.</para>
+
+                <para>Processes systemd spawns are placed in
+                individual Linux control groups named after the unit
+                which they belong to in the private systemd
+                hierarchy. (see <ulink
+                url="http://www.kernel.org/doc/Documentation/cgroups/cgroups.txt">cgroups.txt</ulink>
+                for more information about control groups, or short
+                "cgroups"). systemd uses this to effectively keep
+                track of processes. Control group information is
+                maintained in the kernel, and is accessible via the
+                file system hierarchy (beneath
+                <filename>/cgroup/systemd/</filename>), or in tools
+                such as
+                <citerefentry><refentrytitle>ps</refentrytitle><manvolnum>1</manvolnum></citerefentry>
+                (<command>ps xawf -eo pid,user,cgroup,args</command>
+                is particularly useful to list all processes and the
+                systemd units they belong to.).</para>
+
+                <para>systemd is compatible with the SysV init system
+                to a large degree: SysV init scripts are supported and
+                simply read as an alternative (though limited)
+                configuration file format. The SysV
+                <filename>/dev/initctl</filename> interface is
+                provided, and compatibility implementations of the
+                various SysV client tools are available. In addition to
+                that, various established Unix functionality such as
+                <filename>/etc/fstab</filename> or the
+                <filename>utmp</filename> database are
+                supported.</para>
+
+                <para>systemd has a minimal transaction system: if a
+                unit is requested to start up or shut down it will add
+                it and all its dependencies to a temporary
+                transaction. Then, it will verify if the transaction
+                is consistent (i.e. whether the ordering of all units
+                is cycle-free). If it is not, systemd will try to fix
+                it up, and removes non-essential jobs from the
+                transaction that might remove the loop. Also, systemd
+                tries to suppress non-essential jobs in the
+                transaction that would stop a running service. Finally
+                it is checked whether the jobs of the transaction
+                contradict jobs that have already been queued, and
+                optionally the transaction is aborted then. If all
+                worked out and the transaction is consistent and
+                minimized in its impact it is merged with all already
+                outstanding jobs and added to the run
+                queue. Effectively this means that before executing a
+                requested operation, systemd will verify that it makes
+                sense, fixing it if possible, and only failing if it
+                really cannot work.</para>
+
+                <para>Systemd contains native implementations of
+                various tasks that need to be executed as part of the
+                boot process. For example, it sets the host name or
+                configures the loopback network device. It also sets
+                up and mounts various API file systems, such as
+                <filename>/sys</filename> or
+                <filename>/proc</filename>.</para>
+
+                <para>For more information about the concepts and
+                ideas behind systemd please refer to the <ulink
+                url="http://0pointer.de/blog/projects/systemd.html">Original
+                Design Document</ulink>.</para>
+        </refsect1>
+
+        <refsect1>
                 <title>Directories</title>
 
                 <variablelist>
                                 when figuring out whether a service
                                 shall be enabled. Note that a service
                                 unit with a native unit configuration
-                                file can be started by activating it
+                                file cannot be started by activating it
                                 in the SysV runlevel link
                                 farm.</para></listitem>
                         </varlistentry>
         </refsect1>
 
         <refsect1>
+                <title>Kernel Command Line</title>
+
+                <para>When run as system instance systemd parses a few kernel command line arguments:</para>
+
+                <variablelist>
+                        <varlistentry>
+                                <term><varname>systemd.unit=</varname></term>
+
+                                <listitem><para>Overrides the unit to
+                                activate on boot. Defaults to
+                                <filename>default.target</filename>. This
+                                may be used to temporarily boot into a
+                                different boot unit, for example
+                                <filename>rescue.target</filename> or
+                                <filename>emergency.service</filename>. See
+                                <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>
+                                for details about these
+                                units.</para></listitem>
+                        </varlistentry>
+
+                        <varlistentry>
+                                <term><varname>systemd.log_target=</varname></term>
+                                <term><varname>systemd.log_level=</varname></term>
+                                <term><varname>systemd.log_color=</varname></term>
+                                <term><varname>systemd.log_location=</varname></term>
+
+                                <listitem><para>Controls log output,
+                                with the same effect as the
+                                <varname>$SYSTEMD_LOG_TARGET</varname>, <varname>$SYSTEMD_LOG_LEVEL</varname>, <varname>$SYSTEMD_LOG_COLOR</varname>, <varname>$SYSTEMD_LOG_LOCATION</varname>
+                                environment variables described above.</para></listitem>
+                        </varlistentry>
+
+                        <varlistentry>
+                                <term><varname>systemd.dump_core=</varname></term>
+
+                                <listitem><para>Takes a boolean
+                                argument. If <option>true</option>
+                                systemd dumps core when it
+                                crashes. Otherwise no core dump is
+                                created. Defaults to
+                                <option>true</option>.</para></listitem>
+                        </varlistentry>
+
+                        <varlistentry>
+                                <term><varname>systemd.crash_shell=</varname></term>
+
+                                <listitem><para>Takes a boolean
+                                argument. If <option>true</option>
+                                systemd spawns a shell when it
+                                crashes. Otherwise no core dump is
+                                created. Defaults to
+                                <option>false</option>, for security
+                                reasons, as the shell is not protected
+                                by any password
+                                authentication.</para></listitem>
+                        </varlistentry>
+
+                        <varlistentry>
+                                <term><varname>systemd.crash_chvt=</varname></term>
+
+                                <listitem><para>Takes an integer
+                                argument. If positive systemd
+                                activates the specified virtual
+                                terminal when it crashes. Defaults to
+                                <literal>-1</literal>.</para></listitem>
+                        </varlistentry>
+
+                        <varlistentry>
+                                <term><varname>systemd.show_status=</varname></term>
+
+                                <listitem><para>Takes a boolean
+                                argument. If <option>true</option>
+                                shows terse service status updates on
+                                the console during bootup. Defaults to
+                                <option>true</option>.</para></listitem>
+                        </varlistentry>
+
+                </variablelist>
+        </refsect1>
+
+        <refsect1>
                 <title>Sockets and FIFOs</title>
 
                 <variablelist>