Systemd Unit Types and Dependencies

systemd.service(5). 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

This section describes the remaining unit types in systemd, including timer, swap, path, slice, and scope units, and explains their functions. It details the naming conventions for units and highlights systemd's special units. The documentation outlines the various types of dependencies between units, such as requirement and ordering dependencies, and how systemd manages these dependencies. It also covers how applications request state changes of units through 'jobs' and how systemd activates the default.target unit on boot, which is typically aliased to graphical.target or multi-user.target. Finally, it mentions how systemd enables or disables units on the first boot according to preset policies.