Home • Explore • Blog • CI
☰



man-pages
2nd chunk of `init.man`
caf3a6658ae80a4f21291a13ce3d8065ae2c74c5defb89ca0000000100000fa4
    2. Socket units, which encapsulate local IPC or network sockets in the system, useful for socket-based activation. For details about socket units, see systemd.socket(5), for details on socket-based activation and
           other forms of activation, see daemon(7).

        3. Target units are useful to group units, or provide well-known synchronization points during boot-up, see systemd.target(5).

        4. Device units expose kernel devices in systemd and may be used to implement device-based activation. For details, see systemd.device(5).

        5. Mount units control mount points in the file system, for details see systemd.mount(5).

        6. Automount units provide automount capabilities, for on-demand mounting of file systems as well as parallelized boot-up. See systemd.automount(5).

        7. Timer units are useful for triggering activation of other units based on timers. You may find details in systemd.timer(5).

        8. Swap units are very similar to mount units and encapsulate memory swap partitions or files of the operating system. They are described in systemd.swap(5).

        9. Path units may be used to activate other services when file system objects change or are modified. See systemd.path(5).

       10. Slice units may be used to group units which manage system processes (such as service and scope units) in a hierarchical tree for resource management purposes. See systemd.slice(5).

       11. Scope units are similar to service units, but manage foreign processes instead of starting them as well. See systemd.scope(5).

       Units are named as their configuration files. Some units have special semantics. A detailed list is available in systemd.special(7).

       systemd knows various kinds of dependencies, including positive and negative requirement dependencies (i.e.  Requires= and Conflicts=) as well as ordering dependencies (After= and Before=). NB: ordering and
       requirement dependencies are orthogonal. If only a requirement dependency exists between two units (e.g.  foo.service requires bar.service), but no ordering dependency (e.g.  foo.service after bar.service) and both
       are requested to start, they will be started in parallel. It is a common pattern that both requirement and ordering dependencies are placed between two units. Also note that the majority of dependencies are implicitly
       created and maintained by systemd. In most cases, it should be unnecessary to declare additional dependencies manually, however it is possible to do this.

       Application programs and units (via dependencies) may request state changes of units. In systemd, these requests are encapsulated as 'jobs' and maintained in a job queue. Jobs may 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
Title: Systemd Unit Types and Dependencies
Summary
This section details various systemd unit types including Socket, Target, Device, Mount, Automount, Timer, Swap, Path, Slice, and Scope units. It explains how units are named and highlights special units. The document also describes systemd's dependency system, including requirement (Requires=, Conflicts=) and ordering dependencies (After=, Before=), noting that many dependencies are implicitly managed. It explains how systemd handles state change requests via 'jobs' and mentions the default.target unit activated on boot, usually aliased to graphical.target or multi-user.target. Finally, it notes that systemd follows a preset policy on first boot and only keeps a minimal set of units loaded in memory.