processes and
       the systemd units they belong to.).

       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 /dev/initctl interface is
       provided, and compatibility implementations of the various SysV client
       tools are available. In addition to that, various established Unix
       functionality such as /etc/fstab or the utmp database are supported.

       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.

       Note that transactions are generated independently of a unit's state at
       runtime, hence, for example, if a start job is requested on an already
       started unit, it will still generate a transaction and wake up any
       inactive dependencies (and cause propagation of other jobs as per the
       defined relationships). This is because the enqueued job is at the time
       of execution compared to the target unit's state and is marked
       successful and complete when both satisfy. However, this job also pulls
       in other dependencies due to the defined relationships and thus leads
       to, in our example, start jobs for any of those inactive units getting
       queued as well.

       systemd contains native implementations of various tasks that need to be
       executed as part of the boot process. For example, it sets the hostname
       or configures the loopback network device. It also sets up and mounts
       various API file systems, such as /sys/ or /proc/.

       For more information about the concepts and ideas behind systemd, please
       refer to the Original Design Document[2].

       Note that some but not all interfaces provided by systemd are covered by
       the Interface Portability and Stability Promise[3].

       Units may be generated dynamically at boot and system manager reload
       time, for example based on other configuration files or parameters
       passed on the kernel command line. For details, see
       systemd.generator(7).

       The D-Bus API of systemd is described in org.freedesktop.systemd1(5) and
       org.freedesktop.LogControl1(5).

       Systems which invoke systemd in a container or initrd environment should
       implement the Container Interface[4] or initrd Interface[5]
       specifications, respectively.

DIRECTORIES
       System unit directories
           The systemd system manager reads unit configuration from various
           directories. Packages that want to install unit files shall place
           them in the directory returned by pkg-config systemd
           --variable=systemdsystemunitdir. Other directories checked are
           /usr/local/lib/systemd/system and /lib/systemd/system. User
           configuration always takes precedence.  pkg-config systemd
           --variable=systemdsystemconfdir returns the path of the system
           configuration