Systemd Overview

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?

Units as Managed Objects

A unit is systemd's named model of a resource or activity. Common unit types include:

.service for processes and daemons
.socket for socket activation
.mount and .automount for filesystems
.timer and .path for event-driven activation
.target for grouping and synchronization
.device, .swap, .slice, and .scope for 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?

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?

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?

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?

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.

Practice

In the practice terminal, run: ps -p 1 -o pid,comm,args= It shows the process that is PID 1. Then run: ls /etc/systemd/system/ to see the local unit configuration directory.

Check PID 1 with ps, then look inside /etc/systemd/system.