Init · Lesson 5 of 7
Systemd Overview
0 / 5 checkpoints answered
Systemd is the PID 1 init and service manager used by many current Linux distributions. The systemd project also provides logging, device, login, network, time, and other components, but distributions can choose which parts to deploy.
Confirming the Running Manager
Inspect live state rather than the existence of installed directories:
$ ps -p 1 -o pid,comm,args=
$ systemctl is-system-running
/usr/lib/systemd/ can exist on a system where another program is PID 1, and a container can expose its own PID namespace. systemctl also has user-manager and remote/container modes, so identify which manager an operation targets.
CheckWhat most directly identifies systemd as the system init manager?
press 1/2/3 to answer · → next lesson
Units as Managed Objects
A unit is systemd's named model of a resource or activity. Common unit types include:
.servicefor processes and daemons.socketfor socket activation.mountand.automountfor filesystems.timerand.pathfor event-driven activation.targetfor grouping and synchronization.device,.swap,.slice, and.scopefor other managed resources
Unit state is not always “running.” A mount can be mounted, a timer waiting, a device present, and a target active after its dependencies are reached.
CheckWhich unit type commonly groups other units and provides a synchronization point?
press 1/2/3 to answer · → next lesson
Unit Load Paths and Overrides
System units can be loaded from distribution and administrator paths such as:
/usr/lib/systemd/system/for package-provided units on many distributions/run/systemd/system/for runtime-generated or transient configuration/etc/systemd/system/for persistent local administrator configuration and overrides
Exact vendor paths can differ. Higher-priority local configuration overrides lower-priority files with the same unit name. Prefer drop-in overrides created with systemctl edit UNIT over copying and modifying a complete vendor file, so package updates remain visible.
CheckWhere should persistent local system-unit overrides normally reside?
press 1/2/3 to answer · → next lesson
Dependencies and Ordering
Systemd builds a transaction from dependency relationships. Wants= and Requires= pull other units into a transaction with different strength. Before= and After= specify ordering when both units are scheduled; they do not by themselves cause another unit to start.
An After=network.target line does not prove that usable connectivity, DNS, or a specific remote endpoint is ready. Services must use the appropriate network-online integration or implement their own retry and readiness behavior.
CheckWhat does After=other.service specify by itself?
press 1/2/3 to answer · → next lesson
Targets and the Default Boot Transaction
default.target is commonly an alias to a target such as multi-user.target or graphical.target. Systemd starts a transaction for that target and its dependencies, allowing unrelated work to proceed concurrently while enforcing explicit ordering.
Targets resemble runlevels only at a broad compatibility level. Multiple targets can be active simultaneously, custom targets can be created, and target activity does not mean every service on the machine is healthy.
CheckWhat does default.target normally select?
press 1/2/3 to answer · → next lesson
Summary
You can now describe systemd in terms of live managers, units, and transactions.
- Confirm systemd through the relevant PID 1 and manager connection.
- Match resource types to unit suffixes.
- Place local overrides above vendor configuration.
- Separate dependency strength, ordering, and application readiness.
- Treat targets as groupings and milestones rather than exclusive states.
Lesson complete
You finished Systemd Overview. Nice work — keep the momentum going.