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.
Init · Lesson 5
Systemd Overview
Learn how systemd loads units, resolves dependencies, activates targets, and manages system and user resources.
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.
What most directly identifies systemd as the system init manager?
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.
Which unit type commonly groups other units and provides a synchronization point?
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.
Where should persistent local system-unit overrides normally reside?
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.
What does After=other.service specify by itself?
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.
What does default.target normally select?
Lesson complete
You finished Systemd Overview
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.
Keep your learning progress
Create a free account to save this lesson and continue learning on any device.
Create a free account