succeed or can fail, their
       execution is ordered based on the ordering dependencies of the units
       they have been scheduled for.

       On boot systemd activates the target unit default.target 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 graphical.target (for fully-featured boots into the UI) or
       multi-user.target (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 systemd.special(7) for details about these
       target units.

       On first boot, systemd will enable or disable units according to preset
       policy. See systemd.preset(5) and "First Boot Semantics" in machine‐
       id(5).

       systemd only keeps a minimal set of units loaded into memory.
       Specifically, the only units that are kept loaded into memory are those
       for which at least one of the following conditions is true:

        1. It is in an active, activating, deactivating or failed state (i.e.
           in any unit state except for "inactive")

        2. It has a job queued for it

        3. It is a dependency of at least one other unit that is loaded into
           memory

        4. It has some form of resource still allocated (e.g. a service unit
           that is inactive but for which a process is still lingering that
           ignored the request to be terminated)

        5. It has been pinned into memory programmatically by a D-Bus call

       systemd will automatically and implicitly load units from disk — if they
       are not loaded yet — as soon as operations are requested for them. Thus,
       in many respects, the fact whether a unit is loaded or not is invisible
       to clients. Use systemctl list-units --all to comprehensively list all
       units currently loaded. Any unit for which none of the conditions above
       applies is promptly unloaded. Note that when a unit is unloaded from
       memory its accounting data is flushed out too. However, this data is
       generally not lost, as a journal log record is generated declaring the
       consumed resources whenever a unit shuts down.

       Processes systemd spawns are placed in individual Linux control groups
       named after the unit which they belong to in the private systemd
       hierarchy. (see Control Groups v2[1] 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 /sys/fs/cgroup/),
       or in tools such as systemd‐cgls(1) or ps(1) (ps xawf -eo
       pid,user,cgroup,args is particularly useful to list all 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