Home • Explore • Blog • CI
☰



man-pages
4th chunk of `init.man`
5d49d7991f55c939319bf5ffd1f28535974ef0f85654601e0000000100000fa2
 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 directory. Packages should alter the content of these directories only with the enable and disable commands of the systemctl(1) tool. Full list of directories is
           provided in systemd.unit(5).

       User unit directories
           Similar rules apply for the user unit directories. However, here the XDG Base Directory specification[6] is followed to find units. Applications should place their unit files in the directory returned by
           pkg-config systemd --variable=systemduserunitdir. Global configuration is done in the directory reported by pkg-config systemd --variable=systemduserconfdir. The enable and disable commands of the systemctl(1)
           tool can handle both global (i.e. for all users) and private (for one
Title: Systemd Transactions, Boot Tasks, and Unit Directories
Summary
Systemd uses a transaction system to ensure requested operations are consistent and safe, verifying that unit order is cycle-free and resolving any conflicts before adding jobs to the run queue. Transactions are generated independently of unit states, meaning that even starting an already started unit will still trigger a transaction and potentially activate inactive dependencies. Systemd natively implements various boot tasks, such as setting the hostname and configuring the loopback network device. Systemd utilizes unit directories to load configuration files, differentiating between system and user unit directories and leveraging pkg-config to find the relevant paths for installation and configuration.