102 systemd Interview Questions and Answers (2026)

A target is a special unit that groups other units to represent a synchronization point or system state; targets replace SysVinit runlevels but are more flexible because they are named, composable dependency groups rather than fixed numbers.

• What a target is: A .target unit has no process of its own; it just pulls in other units via Wants=/Requires= to define a milestone (e.g. "network is up", "multi-user text mode").

• How they replace runlevels:

  • Runlevels were a single integer state; targets are named and can depend on each other, so many can be combined and reached simultaneously.

  • Compatibility symlinks map old runlevels (runlevel3.target to multi-user.target).

• Common targets:

  1. multi-user.target: multi-user text mode (old runlevel 3).

  2. graphical.target: multi-user with GUI (runlevel 5), pulls in multi-user.target.

  3. rescue.target: single-user recovery (runlevel 1).

  4. emergency.target: minimal shell, root FS read-only, almost nothing started.

  5. reboot.target, poweroff.target: shutdown states.

• Switch or query them with systemctl isolate and systemctl set-default.

systemd is the modern init system and service manager used by most Linux distributions: it is the first userspace process (PID 1) and is responsible for booting the system, starting and supervising services, and managing system state throughout its lifetime.

• Init system: Runs as PID 1, brings the system from kernel handoff to a fully usable state.

• Service manager: Starts, stops, restarts, and monitors daemons, restarting them on failure and tracking their processes via cgroups.

• Dependency-based and parallel: Uses declarative unit files with explicit dependencies to start things concurrently and in the right order.

• A broader platform: Beyond init, it provides logging (journald), timers, mounts, network and login management, offering a consistent interface (systemctl) across distributions.

A unit is the basic object systemd manages: any resource it knows how to start, stop, or supervise is represented by a unit, described in a declarative configuration file and named with a suffix indicating its type.

• Unit files: INI-style text files found in /usr/lib/systemd/system (packaged) and /etc/systemd/system (admin overrides, higher priority).

• Common unit types:

  1. .service: a daemon or process to run.

  2. .socket: a listening socket for socket activation.

  3. .target: a group of units / synchronization point.

  4. .mount and .automount: filesystem mount points.

  5. .timer: scheduled activation (a cron replacement).

  6. .device, .path, .slice, .scope: devices, path watches, and cgroup resource grouping.

• Common infrastructure: All units share dependency directives (Requires=, After=) and are controlled uniformly through systemctl.

A service unit file is an INI-style file typically organized into three sections: [Unit] for metadata and dependencies, [Service] for how the process runs, and [Install] for how it is enabled at boot.

• [Unit]: Description and documentation plus ordering/dependency directives: Description=, After=, Requires=, Wants=.

• [Service]:

  • How to run the daemon: ExecStart= (the command), Type= (simple, forking, notify, oneshot).

  • Restart policy and environment: Restart=, ExecStop=, User=, Environment=.

• [Install]: Used by systemctl enable: WantedBy= (usually multi-user.target) creates the symlink that pulls the service in at boot.

systemd keeps an in-memory representation of all units, so editing a file on disk does not change the running configuration until systemctl daemon-reload re-parses the files and rebuilds that internal state.

• systemd caches units in memory: On boot it reads all unit files and builds a dependency graph; it does not re-read the disk on every command.

• What daemon-reload does: Re-reads unit files, applies drop-ins, and regenerates the dependency tree, without stopping running services.

• Important distinction:

  • daemon-reload reloads the manager's config; it does not restart the service.

  • You still need systemctl restart <unit> for the new settings to take effect on the actual process.

• Skipping it causes stale state: systemd may warn that a unit changed on disk, or keep running the old definition.

• systemctl edit runs the reload automatically; manual file edits do not.

A unit is the basic object systemd manages: any resource it can start, stop, and monitor. The unit type (given by the file extension) determines what kind of resource it represents and which directives are valid.

• .service: a daemon or process: The most common type; controls starting/stopping a program (web servers, databases).

• .socket: socket activation: Listens on a socket and starts the paired .service on first connection, enabling on-demand startup.

• .target: grouping and synchronization: No process of its own; a milestone that pulls in other units (e.g. multi-user.target, the replacement for runlevels).

• .timer: scheduled activation: A cron replacement that triggers a service on a calendar or monotonic schedule.

• .mount / .automount: filesystem mounts: Manage mount points; .automount mounts on first access.

• Other types:

  • .device: expose kernel/udev devices as units.

  • .path: activate a service when a file/directory changes.

  • .slice: organize processes into a cgroup hierarchy for resource control.

  • .scope: manage externally-created processes (not started by systemd).

  • .swap: manage swap space.

A .service file is an INI-style file split into sections; you configure behavior mainly through directives in the [Service] section, with [Unit] for metadata/dependencies and [Install] for enablement.

• [Unit] section: Description=, Documentation=, and ordering/dependency directives like After=, Requires=.

• [Service] section (the behavior):

  • Type=: launch model (simple, forking, oneshot, notify).

  • ExecStart=, ExecStartPre=, ExecStop=, ExecReload=: lifecycle commands.

  • Restart=, RestartSec=: failure recovery.

  • User=, WorkingDirectory=, Environment=, EnvironmentFile=: execution context.

• [Install] section: WantedBy= defines what enabling the unit hooks it into (usually multi-user.target); read only by systemctl enable.

• Apply changes with systemctl daemon-reload then systemctl restart <unit>.

start affects the current runtime (activate the service now), while enable affects boot behavior (activate it automatically on future boots): they are independent and neither implies the other.

• systemctl start:

  • Activates the unit immediately in the running system.

  • Does not survive a reboot: after restart it will not come back unless enabled.

• systemctl enable:

  • Creates symlinks (based on the unit's [Install] section, usually into a target's .wants/ dir) so it starts at boot.

  • Does not start it right now.

• They are orthogonal:

  • Use enable --now to both enable and start in one step.

  • A service can be running but not enabled (won't survive reboot) or enabled but stopped (will start next boot).

systemctl is the primary tool for managing units: runtime actions (start, stop, restart) change state now, while enable/disable change boot behavior, and status inspects current state.

• Runtime control:

  • systemctl start nginx activates it now; systemctl stop nginx deactivates it now.

  • systemctl restart nginx stops then starts.

• Boot control:

  • systemctl enable nginx makes it autostart at boot; systemctl disable nginx removes that.

  • Combine with --now to also start/stop immediately.

• Inspection:

  • systemctl status nginx shows active state and recent logs.

  • systemctl is-active, is-enabled, is-failed give scriptable one-word answers.

• After editing a unit file, run systemctl daemon-reload so systemd re-reads it.

Run systemctl status <unit>: it shows whether the unit is loaded and enabled, its current active state, the main process (PID), the cgroup, and the most recent journal lines, giving a quick health snapshot.

• Loaded line: Shows the unit file path plus enablement (enabled, disabled, masked): tells you boot behavior.

• Active line:

  • active (running): up with a live process.

  • active (exited): ran successfully and finished (common for oneshot units).

  • inactive (stopped), failed (exited non-zero or crashed), activating/deactivating (transitional).

• Process and resources: Main PID, memory usage, and the CGroup tree of child processes.

• Recent logs: Tail of journal output; for full logs use journalctl -u <unit>.

• For failures, note the Main PID: ... (code=exited, status=...) line: the exit code points to the cause.

These three sub-commands answer yes/no questions about a unit and communicate via exit codes plus a short word on stdout, which makes them ideal building blocks for scripts.

• systemctl is-active: Prints active, inactive, activating, etc.; exit 0 only when active.

• systemctl is-enabled: Reports whether it starts at boot: enabled, disabled, static, masked.

• systemctl is-failed: Exit 0 (and prints failed) when the unit is in the failed state.

• Why they're script-friendly: Exit codes let you branch without parsing verbose output; add -q to suppress the text.

systemctl enable --now both enables a unit (so it starts automatically on boot) and starts it immediately in the current session, in one command.

• The two operations:

  • enable: creates the .wants symlinks from the [Install] section so boot will pull it in (persistent).

  • --now: equivalent to also running systemctl start right away (immediate, current runtime).

• Why combine them: enable alone doesn't start the service, and start alone doesn't survive reboot; --now gives you both at once.

• Symmetry: disable --now disables and stops the unit together.

Both inject environment variables into a service's execution: Environment= sets them inline in the unit file, while EnvironmentFile= loads them from an external file, keeping config (and secrets) out of the unit.

• Environment=:

  • One or more KEY=value pairs; can appear multiple times.

  • Best for a few static values visible right in the unit.

• EnvironmentFile=:

  • Points to a file of KEY=value lines, read at start time.

  • Prefix the path with - to make a missing file non-fatal.

  • Good for environment-specific or sensitive config you don't want in the unit.

• Precedence and notes:

  • Later assignments override earlier ones; Environment= is applied after EnvironmentFile=.

  • These are not shell scripts: no command substitution or variable expansion from the file itself.

RestartSec defines how long systemd waits after a service exits before restarting it: it inserts a delay between the death of the old process and the launch of a new one.

• What it controls:

  • The cooldown before each restart attempt (default is a short 100ms).

  • Accepts time spans like 5s, 2min.

• Interaction with Restart=:

  • Only relevant when Restart= is set to something other than no; it governs the pause between the triggering exit and the next start.

  • A longer delay avoids hammering a failing dependency (e.g. a database that is still coming up).

• Interaction with the start limit: Because it spreads attempts over time, it directly affects whether you trip StartLimitBurst within StartLimitIntervalSec.

journalctl queries the journal with filters you compose on the command line: by unit, by time range, and by boot session, and these can be combined freely.

• By service (unit):

  • journalctl -u nginx.service shows only that unit's logs.

  • Add -f to follow live, -e to jump to the end.

• By time: --since and --until accept timestamps or natural language, e.g. --since "2 hours ago" or --since today.

• By boot:

  • journalctl -b is the current boot; -b -1 the previous one.

  • journalctl --list-boots enumerates available boots (requires persistent storage for older boots).

• Other useful filters: -p err filters by priority, -k shows kernel messages, -o json changes output format.

systemd-journald is the logging daemon of systemd: it collects log records from the kernel, services' stdout/stderr, syslog, and the native journal API into a single structured, indexed store that you read back with journalctl.

• What it collects: Kernel messages (kmsg), service stdout/stderr, classic syslog, audit, and native structured entries.

• How entries are stored: As key-value records with metadata (unit, PID, UID, priority, boot ID) attached automatically, not just a text line.

• Interacting via journalctl:

  • journalctl with no args shows everything; filter with -u (unit), -b (boot), --since, -p (priority), -f (follow).

  • Filter on any stored field, e.g. journalctl _PID=1234 or _UID=1000.

Use journalctl -b -1 to show the previous boot, provided persistent storage is enabled so old boots are retained.

• Boot offsets: journalctl -b (or -b 0) is the current boot; -b -1 is the one before, -b -2 two before, and so on.

• List available boots: journalctl --list-boots prints each stored boot with its index and boot ID; you can also pass a full boot ID to -b.

• Requires persistence: With volatile storage the journal lives in /run and is wiped on reboot, so previous boots are unavailable.

A timer activates a service by name matching: a foo.timer automatically triggers foo.service, or you override the target explicitly with the Unit= directive in the [Timer] section.

• Implicit pairing by name: By default the timer starts the service with the same base name (backup.timer → backup.service).

• Explicit pairing with Unit=: Use it when the names differ, e.g. Unit=cleanup.service inside nightly.timer.

• Enabling the timer, not the service: You run systemctl enable --now foo.timer; the service is oneshot-style and started on schedule.

systemctl list-timers lists all active timers with their next and last firing times, giving you an at-a-glance schedule overview and a countdown to the next run.

• Columns it shows:

  • NEXT and LEFT: the next elapse time and time remaining.

  • LAST and PASSED: when it last fired and how long ago.

  • UNIT and ACTIVATES: the timer name and the service it triggers.

• Useful flags:

  • --all also shows inactive timers.

  • Rows are sorted by soonest next elapse.

• Primary use: Quickly verify a timer is enabled and will fire when you expect.

They control startup/shutdown ordering only, not whether a unit is pulled in: After= means start this unit after the listed one, Before= means start it before.

• Ordering vs requirement are independent: After=/Before= say nothing about pulling a unit in; you still need Wants= or Requires= for that.

• They are inverses: A After=B is equivalent to B Before=A; you only need one side.

• Behavior on shutdown: Ordering is reversed at stop time: if A starts after B, A is stopped before B.

• Common pattern: Combine both purposes, e.g. Requires=network.target plus After=network.target, so the unit both needs and waits for it.

Use systemctl list-dependencies to see the tree of units a given unit pulls in; by default it shows the recursive set of units the target wants/requires, expandable to more detail with flags.

• Basic usage:

  • systemctl list-dependencies UNIT prints a recursive tree following Requires=, Wants=, and similar pull-in dependencies.

  • Dots/colors indicate each unit's current active state.

• Useful flags:

  • --reverse: show what depends on this unit instead.

  • --after / --before: show ordering relationships rather than requirement ones.

  • --all: fully expand target units instead of collapsing them.

• Authoritative per-unit view: systemctl show UNIT prints the resolved dependency properties directly, e.g. Wants=, Requires=, After=, Before=, ConsistsOf=.

Targets are synchronization points that group units to bring the system to a defined state; they replaced SysV runlevels. The common ones map to console-only, graphical, multi-user, and special states.

• multi-user.target: Full multi-user system with networking, no GUI (like old runlevel 3). Typical default on servers.

• graphical.target: Adds a display manager/GUI on top of multi-user.target (like runlevel 5). Default on desktops.

• rescue.target and emergency.target: Minimal single-user recovery states for troubleshooting.

• poweroff.target, reboot.target, halt.target: Shut down, reboot, or halt the machine.

• Building-block targets: sysinit.target, basic.target, network.target are pulled in by higher targets rather than selected directly.

Point the default.target symlink at the target you want; systemctl set-default does this for you. The default target is what systemd activates at the end of boot.

• Set persistently: systemctl set-default multi-user.target relinks /etc/systemd/system/default.target to that unit.

• Inspect current default: systemctl get-default prints where the symlink points.

• Switch at runtime (not persistent): systemctl isolate graphical.target changes the current target now without editing the default.

• Override for one boot: Append systemd.unit=rescue.target to the kernel command line at the boot loader.

User= and Group= run the service as an unprivileged account instead of root, so a compromised process only holds that account's limited permissions.

• Principle of least privilege:

  • Without them a service runs as root and can touch almost anything on the system.

  • Running as a dedicated low-privilege user contains the blast radius of an exploit.

• How they work:

  • systemd drops privileges to the named UID/GID before executing ExecStart=.

  • The account should own only the files the service needs, enforcing separation from other services.

• Related option: If you don't want to pre-create an account, DynamicUser=yes gives a transient user for the service's lifetime.

SysVinit boots by running numbered shell scripts sequentially in a fixed order, while systemd is a declarative, dependency-driven manager that starts services in parallel based on what they actually need.

• Execution model:

  • SysVinit runs scripts in /etc/rc.d one after another in lexical order (S01, S02...), so slow scripts block everything behind them.

  • systemd starts units concurrently and only waits where a real dependency exists.

• Dependency management:

  • SysVinit encodes ordering implicitly through script numbering, which is fragile and manual.

  • systemd declares relations explicitly with Requires=, Wants=, After=, and Before=.

• Socket and bus activation: systemd can create listening sockets first and start the service on demand, letting dependent services start before the daemon is fully up (further parallelizing boot).

• Configuration style: SysVinit uses imperative shell scripts; systemd uses declarative INI-style unit files that are simpler and consistent.

• Process supervision: systemd tracks every service's processes in a cgroup, so it can reliably monitor, restart, and clean up daemons: SysVinit largely forgets about a process once its script exits.

After the kernel finishes initializing, it executes systemd as PID 1, the first userspace process and ancestor of everything else; systemd then resolves the dependency tree of the default target and activates units in parallel to reach it.

• Kernel hands off to PID 1: The kernel mounts the root filesystem and runs /sbin/init (a symlink to systemd), which inherits PID 1 and reaps orphaned processes.

• Determine the goal state: systemd looks up default.target (a symlink, usually to graphical.target or multi-user.target).

• Build and satisfy the dependency graph: It pulls in everything that target Wants=/Requires=, ordering with After=/Before=, and starts independent units simultaneously.

• Reach the target: Once all wanted units are active, the target is reached and the system is fully booted; systemctl get-default shows the configured goal.

systemd is a suite, not just PID 1: it ships a family of daemons and tools that share its unit and D-Bus infrastructure to handle logging, device events, login sessions, time, networking, and name resolution.

• systemd-journald: Collects and stores structured, indexed logs from the kernel and services, queried with journalctl.

• systemd-udevd: The device manager: handles hotplug events and creates/manages device nodes in /dev.

• systemd-logind: Manages user logins, sessions, seats, and power/idle actions.

• systemd-networkd: Optional network configuration and management daemon.

• systemd-resolved: Provides DNS name resolution and caching.

• systemd-timesyncd: Lightweight SNTP client for keeping the clock synchronized.

• Client tooling: systemctl (control units), journalctl (logs), timedatectl, hostnamectl, loginctl provide a consistent CLI.

Unit files live in three main directories, each with a different owner and purpose; when the same unit name exists in more than one, systemd loads exactly one based on a fixed priority where the admin-controlled location wins over the vendor default.

• The three main locations:

  • /usr/lib/systemd/system/: vendor/package-supplied units (managed by the distro, do not edit).

  • /run/systemd/system/: runtime-generated units, volatile and lost on reboot.

  • /etc/systemd/system/: local admin units and overrides, highest priority.

• Precedence order (highest wins):

  1. /etc/systemd/system/ (admin)

  2. /run/systemd/system/ (runtime)

  3. /usr/lib/systemd/system/ (vendor)

• Full-file replacement vs drop-ins:

  • A same-named file in a higher-priority dir fully replaces the lower one.

  • Drop-ins in unit.d/ directories instead merge on top without replacing.

• For user units, equivalents live under ~/.config/systemd/user/, /etc/systemd/user/, and /usr/lib/systemd/user/.

• Use systemctl cat <unit> to see which file is actually in effect.

Never edit vendor files under /usr/lib/systemd/system/ directly, since package updates overwrite them; instead use drop-in files or a full copy in /etc/systemd/system/, both of which survive upgrades.

• Drop-in files (preferred):

  • Small .conf snippets placed in a /etc/systemd/system/<unit>.d/ directory.

  • They are merged on top of the vendor unit, so you override only the directives you care about.

  • Created easily with systemctl edit <unit>, which opens an editor and reloads for you.

• Full override (when you need to replace everything): Run systemctl edit --full <unit>, or copy the file to /etc/systemd/system/ and edit it.

• Resetting list-type directives: Options like ExecStart= or Environment= append by default; assign an empty value first (e.g. ExecStart=) to clear before setting a new one.

• Verify with systemctl cat <unit>, which shows the base file and all applied drop-ins in order.

systemd-sysusers declaratively creates system users and groups from configuration files, so packages can ensure the accounts their services need exist without running imperative useradd commands in install scripts.

• The problem it solves:

  • Services often run as a dedicated unprivileged user; that account must exist before the service starts.

  • Replaces error-prone shell logic in package post-install scripts with a declarative approach.

• How it works:

  • Reads .conf files from /usr/lib/sysusers.d/ and /etc/sysusers.d/.

  • Each line declares an entity by type: u (user + group), g (group), m (add user to group), r (UID/GID range).

  • Idempotent: it only creates entries that are missing, so it is safe to run repeatedly.

• Especially useful for image-based and read-only-root systems where declarative provisioning is preferred.

A template unit is a unit file whose name contains an @ before the suffix (e.g. foo@.service): it is a blueprint from which many instances are created at runtime, each parameterized by an instance name.

• Template vs instance:

  • The template file is foo@.service; an instance is foo@bar.service, where bar is the instance identifier.

  • You start/enable the instance, not the template: systemctl start foo@bar.service.

• Instance specifiers substitute the name:

  • %i is the instance name; %I is the same but unescaped (for paths).

  • So one file can serve many configs, e.g. ExecStart=/usr/bin/daemon --config /etc/foo/%i.conf.

• When to use it:

  • Multiple near-identical services differing only by a parameter: per-user, per-port, per-device, per-tty (getty@tty1.service).

  • Avoids copy-pasting one unit file per instance; you maintain a single template.

• Per-instance overrides are still possible via drop-ins in foo@bar.service.d/.

tmpfiles.d is a declarative configuration system for creating, cleaning, and removing files and directories, applied by the systemd-tmpfiles tool: instead of shell scripts, you write one line per file/dir describing its type, path, mode, owner, and age.

• Configuration locations: /usr/lib/tmpfiles.d/ (vendor), /etc/tmpfiles.d/ (admin, wins), /run/tmpfiles.d/ (runtime).

• Line format:

  • Columns: type, path, mode, user, group, age, argument.

  • Type letters: d (create dir), f (create file), L (symlink), D (dir, cleaned on boot), r/R (remove).

• When it runs:

  • systemd-tmpfiles-setup.service creates entries early at boot.

  • systemd-tmpfiles-clean.timer periodically removes files older than the age field (aging/cleanup).

• The age column drives cleanup: E.g. 10d deletes files untouched for 10 days; leave blank for no aging.

• Run manually with systemd-tmpfiles --create or --clean to apply without waiting for boot/timer.

systemd-run launches a command as a transient unit: a service, scope, or timer that systemd creates on the fly (in memory, no unit file on disk) and manages like any other unit, then discards when done.

• Transient means no persistent file: The unit exists only for its lifetime; nothing is written to /etc/systemd/system/.

• What it gives you over a bare shell command:

  • Full cgroup resource control (--property=MemoryMax=, CPUQuota=) and isolation.

  • Logging to the journal, and lifecycle management via systemctl.

• Common uses:

  • Run an ad-hoc job under a resource cap without writing a unit.

  • Schedule a one-off timed run with --on-active= or --on-calendar= (transient timer).

  • --scope to run in the current context (not forked by systemd) while still tracked in a cgroup.

systemctl mask makes a unit impossible to start by symlinking it to /dev/null, whereas disable only removes its boot-time autostart symlinks but still allows manual or dependency-triggered starts.

• disable:

  • Removes the [Install] symlinks so it won't start at boot.

  • You can still systemctl start it manually, and other units can pull it in as a dependency.

• mask:

  • Symlinks the unit to /dev/null, so all starts fail (manual and dependency-triggered).

  • A hard "off switch": nothing can activate it until unmask.

• When to mask: To guarantee a service never runs (e.g. conflicting service, or forcing it off despite other units wanting it).

• Reverse with systemctl unmask (mask) or enable (disable).

restart fully stops and starts the service (new process, connections dropped), while reload tells the running process to re-read its config without restarting; reload-or-restart reloads if supported and otherwise falls back to a restart.

• restart:

  • Kills the current process and launches a fresh one: brief downtime, connections/state lost.

  • Needed for changes a running process can't pick up (binary upgrade, changed ExecStart).

• reload:

  • Sends the reload action defined by ExecReload= (often SIGHUP): process keeps running and re-reads config.

  • Only works if the unit defines ExecReload=; otherwise it fails.

• reload-or-restart: Reloads when the unit supports it, else restarts: safe default in scripts where you don't know if reload is defined.

• Rule of thumb: prefer reload for config-only changes to avoid downtime; restart when the code or unit itself changed.

systemctl isolate switches the system into a new target, starting every unit that target requires and stopping every running unit that isn't part of it: it changes the whole system's active state to match one target.

• What it does:

  • Activates the named unit and its dependencies, then deactivates anything not pulled in, similar to changing runlevels in SysV init.

  • Only works on units with AllowIsolate=yes (targets set this by default).

• Common uses:

  • Drop to a minimal shell for maintenance: systemctl isolate rescue.target.

  • Switch between graphical and text sessions: systemctl isolate multi-user.target.

• Difference from a plain start: start only adds units; isolate also stops units outside the new target, reshaping the whole system.

• Caution: It can abruptly stop running services (including sessions), so it's disruptive on a live system.

systemctl cat shows the raw unit files and their drop-ins as written on disk, while systemctl show prints the fully parsed, computed runtime properties as key/value pairs.

• systemctl cat:

  • Concatenates the actual source: the main unit file plus any .d/*.conf overrides, with a comment showing each file path.

  • Best for seeing what an admin authored and where directives come from.

• systemctl show:

  • Reports systemd's internal state and resolved values (defaults filled in, dependencies expanded), one Property=Value per line.

  • Filter with -p, e.g. systemctl show -p Restart nginx.

• Rule of thumb: Use cat to read/debug configuration, show to query effective values programmatically.

Enabling a unit reads its [Install] section and creates symlinks that express dependencies: WantedBy= tells systemd which target should pull in this unit, and enabling materializes that as a symlink inside that target's .wants directory.

• How the symlink is created:

  • For WantedBy=multi-user.target, enabling makes /etc/systemd/system/multi-user.target.wants/foo.service pointing at the real unit file.

  • When that target starts, systemd starts every unit symlinked in its .wants directory.

• Role of WantedBy:

  • It declares a reverse (weak) dependency: Wants= from the target's side, so failure to start won't block the target.

  • RequiredBy= works the same but creates .requires symlinks (a hard dependency).

• Consequences:

  • A unit with no [Install] section is static and can't be enabled this way.

  • disable just removes the symlinks; the unit file stays put.

Type= tells systemd how the main process behaves and, crucially, how to decide the service has finished starting up so dependent units can proceed.

• simple (default): The ExecStart process is the main process; systemd considers it started as soon as it's forked, before it's actually ready.

• exec: Like simple but readiness waits until the binary is executed (exec succeeds), catching early failures.

• forking: For traditional daemons that fork and let the parent exit; readiness is when the parent exits. Pair with PIDFile=.

• oneshot: Runs to completion then exits; considered active only after the command finishes. Use RemainAfterExit=yes to keep it "active".

• notify / notify-reload: The service signals readiness explicitly via sd_notify(READY=1); the most accurate readiness signal.

• dbus: Ready when it acquires the name given in BusName= on the D-Bus.

• Why it matters: Ordering with After= only helps if the type reports readiness correctly; notify or forking with a PID file avoid starting dependents too early.

Restart= tells systemd under which exit conditions to automatically restart a service, which is the core of its self-healing behavior for long-running daemons.

• Common values:

  • no (default): never restart automatically.

  • on-failure: restart on non-zero exit, signal, timeout, or watchdog (typical choice).

  • on-abnormal: restart on signal, timeout, or watchdog, but not on plain non-zero exit.

  • on-success, on-abort, on-watchdog: narrower triggers.

  • always: restart no matter how it exited (even clean stops from the process itself).

• Rate limiting:

  • RestartSec= sets the delay before restarting.

  • StartLimitIntervalSec= and StartLimitBurst= stop a crash loop; exceeding the limit puts the unit in failed.

• Important nuance: A manual systemctl stop is never overridden by Restart=; it only reacts to unexpected exits.

These directives define the lifecycle commands of a service; systemd runs them in a fixed order around the main process, and the Pre/Post hooks let you prepare and clean up.

• Execution order on start:

  1. ExecStartPre: setup commands run before the main process (e.g. create dirs, validate config).

  2. ExecStart: the main command (only one, except for oneshot).

  3. ExecStartPost: runs after the main process has been started/considered up.

• Stopping and reloading:

  • ExecStop: command to stop the service gracefully (systemd otherwise sends SIGTERM).

  • ExecReload: reloads configuration without a full restart, often kill -HUP $MAINPID.

• Failure handling in Pre/Post:

  • If any ExecStartPre command fails, the service is not started and goes to failed.

  • Prefix a command with - to ignore its failure, e.g. ExecStartPre=-/usr/bin/optional-step.

  • Each directive can appear multiple times; they run sequentially in listed order.

RemainAfterExit=yes tells systemd to consider a service active even after its main process has exited, so a unit that just runs a command once still shows as running rather than dead.

• Default behavior without it: When the process exits, the service becomes inactive (dead), even for a successful Type=oneshot run.

• With RemainAfterExit=yes: The unit stays in the active (exited) state after the command finishes.

• Why it matters for one-shots:

  • Many one-shots do setup work (mount, load a module, apply sysctl) and leave no process behind.

  • Keeping them active lets other units depend on them and lets systemctl stop trigger an ExecStop= teardown.

You use PIDFile= to tell systemd where a forking daemon writes the PID of its main process, so systemd can track and manage the correct process after the original launcher exits.

• Primarily for Type=forking:

  • The command starts, forks a background daemon, and the parent exits, so systemd loses sight of which process is the real one.

  • The PID file lets systemd identify the main process to monitor and to signal on stop.

• Path requirements:

  • Should be an absolute path; conventionally under /run/.

  • The daemon (not systemd) is responsible for creating it.

• When you do NOT need it: For Type=simple, Type=exec, or Type=notify, systemd already knows the main process directly.

Type=forking is for classic Unix daemons that double-fork and detach: systemd runs the start command, waits for the parent to exit, and treats the surviving background process as the service, which is why it needs a PIDFile= to know which process that is.

• The forking lifecycle:

  • The launched process forks a child (the real daemon) and the original parent exits.

  • systemd interprets the parent's exit as "startup complete."

• Why PIDFile matters:

  • Without it, systemd must guess the main PID from the cgroup, which is unreliable if there are several processes.

  • With PIDFile=, systemd reads the exact main PID to monitor for crashes and to signal on stop.

• Modern alternative: Prefer Type=simple/Type=notify and run the daemon in the foreground where possible; it avoids fork races entirely.

systemd connects a service's stdout and stderr to destinations you choose with StandardOutput= and StandardError=; by default both go to the journal, so journalctl captures everything the process prints.

• Default: the journal:

  • Output is captured via journald and tagged with the unit, so journalctl -u name retrieves it.

  • No need for the app to implement its own logging or log rotation.

• Common target values:

  • journal: send to the journal (the usual default).

  • null: discard the output.

  • tty: connect to a terminal.

  • file:/path or append:/path: write to a specific file.

  • inherit: use whatever the manager was given.

• Practical tip: Have the app log to stdout/stderr (not its own files) and let the journal handle the rest.

They are timeouts that bound how long systemd waits for a service to start up or shut down before it takes forceful action: TimeoutStartSec guards startup, TimeoutStopSec guards shutdown.

• TimeoutStartSec:

  • Max time allowed for a start to complete (readiness signaled per Type=, e.g. exec exit, fork, or sd_notify).

  • If exceeded, the unit is considered failed and killed.

• TimeoutStopSec:

  • Max time to wait after sending the stop signal (SIGTERM) before escalating to SIGKILL.

  • Ensures a hung process cannot block shutdown indefinitely.

• Shortcut and special values:

  • TimeoutSec= sets both at once.

  • Set to infinity (or 0) to disable, useful for legitimately slow-starting jobs.

• Role in service management: Prevents units from hanging the boot or a transaction, and gives predictable failure detection that can trigger restarts or OnFailure=.

OnFailure= lists one or more units that systemd activates automatically when the current unit enters the failed state, making it the hook for automated recovery, alerting, or cleanup.

• When it fires: Only on transition into the failed state (nonzero exit, timeout, signal, exhausted restart limit), not on a clean stop.

• Common uses:

  • Trigger a notification unit (email, Slack) or run a repair/failover script.

  • Often paired with a templated handler like notify@%n.service to pass the failed unit name.

• Behavior detail:

  • Controlled by OnFailureJobMode= (how the triggered job is enqueued).

  • It is complementary to, not a replacement for, Restart=: restart tries to keep the service alive, OnFailure= reacts once it has truly failed.

systemd-journald stores logs as structured, indexed records in a centralized binary journal rather than as loose text files, which makes filtering, correlation, and trust far stronger than plain files or traditional syslog.

• Structured records: Each entry carries typed fields (unit, PID, priority, boot ID) so you query by field instead of grepping strings.

• Centralized collection: One store for kernel, services, and syslog, so a single journalctl query correlates events across sources and time.

• Rich, trustworthy metadata: Fields like the originating unit and UID are added by the daemon and cannot be forged by the logging process, unlike free-text syslog lines.

• Operational features: Automatic rotation and size limits, indexing for fast time/boot queries, and optional cryptographic sealing (FSS) to detect tampering.

• Trade-off to acknowledge: The binary format needs journalctl to read; many setups still forward to syslog for archival and existing tooling.

By default the journal is volatile (stored under /run/log/journal and lost on reboot); you make it persistent by setting Storage=persistent so it is written to /var/log/journal.

• Configure storage:

  • Edit /etc/systemd/journald.conf and set Storage=persistent.

  • Storage=auto (the common default) becomes persistent only if /var/log/journal already exists.

• Create the directory (for auto): sudo mkdir -p /var/log/journal then systemd-tmpfiles --create --prefix /var/log/journal.

• Apply the change: Restart the daemon with systemctl restart systemd-journald.

• Bound disk usage: Limit growth with SystemMaxUse=, SystemKeepFree=, and retention via MaxRetentionSec=.

• Verify: journalctl --list-boots should now show prior boots.

Filter by time with --since/--until, by severity with -p, and by indexed journal fields using FIELD=value match expressions.

• Time: --since "2024-01-01 10:00" and --until accept absolute stamps or relative terms like "1 hour ago" and yesterday.

• Priority: -p err shows that level and worse; use a range like -p warning..err. Levels run emerg (0) to debug (7).

• Fields:

  • Match on indexed fields: _SYSTEMD_UNIT=ssh.service, _PID=1234, _UID=1000.

  • journalctl -F <FIELD> lists all values a field has; multiple matches on the same field are OR, across fields are AND.

• Convenience shortcuts: -u unit for a unit, -k for kernel messages, -f to follow live.

Volatile storage keeps the journal in memory under /run/log/journal (lost on reboot), while persistent storage writes to disk under /var/log/journal so logs survive reboots.

• Controlled by Storage= in journald.conf:

  • volatile: only in /run, never on disk.

  • persistent: on disk, creating /var/log/journal if needed.

  • auto (default): persistent only if /var/log/journal already exists, otherwise volatile.

  • none: logging disabled (forwarding still possible).

• Enable persistence: Create the directory (mkdir -p /var/log/journal) or set Storage=persistent, then restart systemd-journald.

• Trade-off: Persistent enables cross-boot debugging (-b -1) at the cost of disk; volatile is lighter but loses history on reboot.

Cap journal disk usage with SystemMaxUse= and related settings in journald.conf, and reclaim space on demand with journalctl --vacuum-* options.

• Config-based limits:

  • SystemMaxUse= caps total space on persistent storage; RuntimeMaxUse= does the same for volatile /run.

  • SystemKeepFree= leaves a minimum free; SystemMaxFileSize= bounds individual files and thus rotation granularity.

  • MaxRetentionSec= and MaxFileSec= apply time-based rotation.

• On-demand vacuuming: --vacuum-size=500M trims to a size, --vacuum-time=2weeks by age, --vacuum-files=10 by file count.

• Rotation: journald rotates automatically when limits are hit; force it with journalctl --rotate. Check current usage with journalctl --disk-usage.

journald doesn't write to /var/log/messages directly; a syslog daemon (like rsyslog) reads records from journald and writes traditional text logs, letting you keep both the structured journal and classic syslog tooling.

• How forwarding works:

  • journald exposes /run/systemd/journal/syslog; rsyslog's imjournal (or the socket) pulls entries from it.

  • ForwardToSyslog=yes in journald.conf enables the handoff; related options include ForwardToKMsg, ForwardToConsole, ForwardToWall.

• Why keep both:

  • Central log shipping: rsyslog forwards over the network (RFC 5424/TCP/TLS) to a SIEM or log server.

  • Compatibility with existing text-based tooling, log parsers, and retention policies.

  • The journal adds rich metadata and indexed queries that plain syslog lacks.

-o selects the display format, from human-readable short variants to machine-readable json; JSON is for programmatic parsing and shipping to log pipelines.

• Human-readable: short (default, syslog-like), short-iso and short-precise for exact timestamps, short-monotonic for boot-relative times.

• Detailed:

  • verbose shows every field of each entry, useful for discovering fields to filter on.

  • cat prints only the message text, no metadata.

• Machine-readable: json (one object per line), json-pretty (indented), json-sse/json-seq for streaming.

• When to use JSON: Parsing with jq, feeding into scripts, or exporting to log aggregators; preserves all structured fields and binary-safe data.

systemd timers are unit files that trigger a service on a schedule; they integrate with the systemd ecosystem (logging, dependencies, resource control) in ways cron cannot, though cron remains simpler for trivial cases.

• Integrated logging and status: Output goes to the journal (journalctl -u foo.service); systemctl list-timers shows next/last run and inspect state easily.

• Missed-run handling: Persistent=true runs a job that was missed while the machine was off; cron just skips it.

• Dependencies and environment: The triggered service can declare After=, Requires=, resource limits, sandboxing, and a defined environment: no cron PATH surprises.

• Flexible timing: Calendar and monotonic triggers, plus RandomizedDelaySec= and AccuracySec= to jitter and batch wakeups.

• Trade-off: Cron is a single crontab line; timers need two units (.timer plus .service), so they are more verbose for simple jobs.

OnCalendar= fires at wall-clock times (like cron), while monotonic timers like OnBootSec= and OnUnitActiveSec= fire relative to an event, measured in elapsed time since that event.

• OnCalendar= (realtime):

  • Uses calendar expressions, e.g. OnCalendar=*-*-* 02:00:00 for daily 2am, or shortcuts like daily and weekly.

  • Best for jobs tied to a clock time; pairs with Persistent=true to catch up missed runs.

• Monotonic timers (relative):

  • OnBootSec=: time after system boot.

  • OnStartupSec=: time after systemd itself started.

  • OnActiveSec=: time after the timer unit is activated.

  • OnUnitActiveSec=: time after the associated service last ran, ideal for recurring intervals like every 15 minutes.

• Key distinction: Monotonic times are unaffected by clock changes and express intervals; calendar times express absolute points on the clock. Combine OnBootSec + OnUnitActiveSec for an initial-plus-repeat pattern.

Persistent=true makes a timer remember the last time it fired by storing a timestamp on disk, so if the machine was off (or the timer inactive) at the scheduled moment, the job runs once as soon as possible after boot instead of being silently skipped.

• Only meaningful with OnCalendar=: It tracks the last realtime elapse; monotonic timers (OnBootSec=, OnUnitActiveSec=) don't need it.

• Behavior on missed runs:

  • Without it, a schedule that passed while the system was down never fires; with it, systemd catches up.

  • It runs the job only once at catch-up, not once per missed interval.

• State storage: Timestamps live under /var/lib/systemd/timers/, so the state survives reboots.

• This is the systemd equivalent of anacron for laptops/desktops that aren't always on.

Yes: systemd timers are the modern default, but cron still wins where simplicity, portability, or per-user email semantics matter more than integration with the systemd stack.

• Portability and familiarity: cron exists on non-systemd systems (BSDs, minimal containers, Alpine); a crontab is portable across them.

• Simplicity for quick jobs: One crontab -e line versus writing a .timer plus a .service file.

• Built-in mail on output: cron emails stdout/stderr to the user automatically; with timers you inspect the journal instead.

• Environments without systemd: Minimal containers often lack a running systemd as PID 1, making timers unavailable.

• Otherwise timers are preferred: They add logging via the journal, dependencies, resource control, Persistent= catch-up, and randomized delays.

Requirement dependencies decide whether other units get pulled in and activated, while ordering dependencies decide in what sequence units start or stop. They are completely independent axes: one controls existence, the other controls timing.

• Requirement dependencies (Wants, Requires):

  • Wants=: pulls the other unit in, but your unit still starts even if it fails (soft).

  • Requires=: pulls it in, and if it fails to start your unit is also stopped/not started (hard).

• Ordering dependencies (After, Before):

  • After=B: your unit starts only once B has finished starting.

  • They only sequence units that are already being started; they do not cause B to be started.

• The crucial distinction:

  • Requires= without After= means B is pulled in but may start concurrently with your unit (a common bug).

  • Ordering says nothing about pulling units in; requirement says nothing about order.

Because the two directives solve different problems and neither implies the other: the Wants/Requires ensures the dependency is actually started, and the After ensures it is fully up before your service runs.

• One alone is insufficient:

  • Requires=db.service alone: the DB is pulled in but may start at the same instant, so your app can connect before it's ready.

  • After=db.service alone: correct order if the DB is started, but nothing guarantees it is started at all.

• Together they give the intuitive meaning: "Start the DB, and start me only after it's up."

• Choosing the strength: Use Requires= + After= for a hard dependency, Wants= + After= for an optional one.

Conflicts= declares a negative dependency: starting a unit that conflicts with another causes the other to be stopped, and vice versa, so the two can never run at the same time.

• Mutual exclusion:

  • If A has Conflicts=B, starting A stops B, and starting B stops A.

  • It's implicitly symmetric.

• Typical uses:

  • Ensuring only one of two services binding the same port/resource runs.

  • Target switching: rescue.target conflicts with normal multi-user services to tear them down.

• Ordering caveat: Like other dependencies, Conflicts= doesn't define order; combine with After=/Before= if the stop must happen before the start.

Both pull in other units as dependencies, but Requires= is a hard dependency while Wants= is soft: Wants= tolerates the dependency failing, Requires= does not.

• Requires= (strong):

  • If the required unit fails to start or is later stopped, this unit is also stopped/deactivated.

  • Note: it is a requirement dependency only, not an ordering one, so pair it with After= to guarantee sequencing.

• Wants= (weak):

  • Tries to start the dependency, but if it fails this unit still starts.

  • The preferred, most robust way to express optional relationships.

• Practical guidance:

  • Use Wants= unless the unit genuinely cannot function without the dependency.

  • Both are commonly declared via the .wants/ and .requires/ symlink directories created by WantedBy=/RequiredBy=.

BindsTo= is an even stronger requirement dependency that follows the state of another unit, while Conflicts= is the opposite: it declares that two units cannot run at the same time.

• BindsTo=:

  • Like Requires=, but this unit stops whenever the bound unit stops for any reason, including it disappearing unexpectedly (not just an explicit stop or failure).

  • Useful for binding a service to hardware/device units: if the device vanishes, the service is torn down.

• Conflicts=:

  • Starting this unit stops the conflicting unit, and vice versa: they are mutually exclusive.

  • Used for mutually exclusive targets/modes (e.g. rescue.target conflicting with the normal boot) or two daemons that can't share a port.

  • It is a requirement-style dependency only; add Before=/After= if the stop must be ordered relative to the start.

systemd-analyze measures boot performance so you can see where time goes and which units gate others. It reads timing data systemd already records for each unit's activation, then presents it in different views.

• Overall timing: Plain systemd-analyze prints total boot time split into firmware, loader, kernel, and userspace (initrd + init).

• systemd-analyze blame:

  • Lists each unit sorted by how long it took to initialize, slowest first.

  • Caveat: a slow unit isn't necessarily on the critical path (units start in parallel), so a big number here may not delay boot.

• systemd-analyze critical-chain:

  • Shows the tree of units that actually gated boot, following ordering dependencies to what delayed the target being reached.

  • The @ timestamp is when the unit activated; the + value is how long it took. This is what you optimize.

• Other useful subcommands: systemd-analyze plot > boot.svg for a visual timeline; dot to graph dependencies.

• Workflow: use blame to spot slow units, then critical-chain to confirm which ones truly delay boot before disabling or tuning them.

Both are single-user recovery modes, but rescue.target brings up a more usable system while emergency.target is the most minimal state possible for fixing a broken system.

• rescue.target:

  • Mounts local filesystems, starts basic services (via sysinit.target and basic.target), and gives a root shell.

  • No networking or multi-user services. Comparable to old single-user mode.

• emergency.target:

  • Starts almost nothing: only a root shell with the root filesystem mounted read-only and no other units.

  • Use it when even rescue.target fails, e.g. a broken /etc/fstab prevents mounting filesystems.

• Reaching them: systemctl isolate or kernel argument systemd.unit=emergency.target; both prompt for the root password.

You set resource directives in the [Service] (or [Slice]) section of a unit file; systemd translates them to cgroup controller settings. They fall into CPU, memory, and I/O groups, using either hard limits or proportional weights.

• CPU: CPUQuota= caps absolute CPU time (e.g. CPUQuota=50%); CPUWeight= sets relative share under contention; AllowedCPUs= pins to specific cores.

• Memory: MemoryMax= is a hard limit (OOM-kills on breach); MemoryHigh= is a soft throttle; MemoryLow= protects a minimum under pressure.

• I/O (block devices, cgroup v2): IOWeight= for proportional bandwidth; IOReadBandwidthMax= / IOWriteBandwidthMax= to cap throughput per device.

• Tasks: TasksMax= limits the number of processes/threads (via the pids controller).

• Apply without editing files: systemctl set-property foo.service MemoryMax=500M sets it live and persistently.

Both are inspection tools for the cgroup tree: systemd-cgls shows a static tree of cgroups and the processes in them, while systemd-cgtop is a live, top-like view of per-cgroup resource usage.

• systemd-cgls:

  • Prints the cgroup hierarchy as a tree (slices, scopes, services) with the PIDs and command lines under each.

  • Great for answering "which unit does this process belong to?" and seeing structure.

• systemd-cgtop:

  • Refreshes continuously, sorting cgroups by CPU, memory, I/O, or task count.

  • Lets you spot which service or slice is actually consuming resources in real time.

  • Accurate numbers may require the relevant accounting to be enabled (CPUAccounting=, MemoryAccounting=).

• Together: systemd-cgls answers "what is the structure," systemd-cgtop answers "what is costing resources right now."

Both restrict filesystem access via namespaces: ProtectSystem= makes the OS directories read-only or inaccessible, while ProtectHome= hides or read-onlys users' home directories.

• ProtectSystem=:

  • yes: /usr and /boot become read-only.

  • full: also makes /etc read-only.

  • strict: the entire filesystem is read-only except /dev, /proc, /sys; grant writes with ReadWritePaths=.

• ProtectHome=:

  • yes: /home, /root, /run/user appear empty and inaccessible.

  • read-only: visible but not writable.

  • tmpfs: replaced with an empty tmpfs mount.

• Protection provided:

  • They prevent a compromised or buggy service from modifying system binaries/config or reading and tampering with user data.

  • Most services never need to write there, so these are cheap, high-value hardening defaults.

PrivateTmp=yes gives a service its own private, isolated /tmp and /var/tmp via a mount namespace, so it cannot see or interfere with temp files from other processes.

• How it works:

  • systemd sets up a private mount namespace and mounts fresh tmpfs directories over /tmp and /var/tmp.

  • These are automatically cleaned up when the service stops.

• Why it is useful:

  • Security: prevents symlink attacks and snooping on world-writable temp files shared across processes.

  • Isolation: two instances of a service won't collide on temp file names.

  • Hygiene: leftover temp files can't leak between runs.

• Caveat: because the /tmp is private, files the service writes there are invisible to other services expecting to read them.

A .mount unit represents a filesystem mount point that systemd controls, letting it order, track, and manage mounts like any other unit instead of relying solely on mount commands.

• Naming is derived from the path:

  • The unit name is the mount path with slashes turned into dashes: /var/log becomes var-log.mount.

  • Use systemd-escape to compute names safely.

• Relationship to /etc/fstab: systemd-fstab-generator converts /etc/fstab entries into .mount units at boot, so you rarely write them by hand.

• Key directives: What= (device/source), Where= (mount point, must match unit name), Type= and Options=.

• Benefit: ordering and dependencies: Other units can depend on a mount with RequiresMountsFor=, and systemd parallelizes and orders mounts against local-fs.target.

A .path unit watches for filesystem events (a file appearing, changing, or a directory becoming non-empty) and starts a matching service when the condition is met, giving you event-driven activation.

• Watch directives (in the [Path] section):

  • PathExists=: triggers when a given path exists.

  • PathChanged= / PathModified=: triggers on close-after-write or on any write.

  • DirectoryNotEmpty=: triggers when a directory has contents (great for spool/queue dirs).

• What it activates: By default a foo.path starts foo.service; override with Unit=.

• Implementation:

  • Uses inotify under the hood, so watching is efficient (no polling).

  • Enable the .path unit so it runs at boot and monitors continuously.

An .automount unit sets up a mount point that is mounted lazily on first access, while the paired .mount unit describes the actual mount and only runs when something touches the path.

• .mount is eager: It mounts at boot (or when its dependencies are pulled in), consuming resources whether or not anyone uses it.

• .automount is on-demand:

  • systemd installs an autofs watch on the Where= path; the first access blocks briefly while the corresponding .mount activates.

  • Ideal for rarely-used, slow, or removable mounts (NFS, network shares) so boot isn't delayed or blocked.

• Pairing and options:

  • A .automount and a same-named .mount work together; TimeoutIdleSec= can auto-unmount after inactivity.

  • In /etc/fstab, add the x-systemd.automount option to generate this automatically.

The per-user manager is a separate systemd instance (systemd --user) that each logged-in user gets, managing that user's own units; systemctl --user talks to it instead of the system-wide PID 1 manager.

• Scope and privileges:

  • Runs as the user (no root), so its services can't perform privileged operations.

  • Started per user by systemd-logind via user@UID.service.

• Unit locations:

  • User units live in ~/.config/systemd/user/, /etc/systemd/user/, and /usr/lib/systemd/user/.

  • System units live in /etc/systemd/system/ etc. and are controlled by plain systemctl.

• Targets differ: User instance uses default.target (not multi-user.target) and its own bus (DBUS_SESSION_BUS_ADDRESS).

• Lifecycle caveat: By default the user manager stops when the last session ends; use lingering to keep it running (see enable-linger).

systemd-logind is the service that tracks user logins, managing sessions, seats, and user objects, and coordinating access to hardware and power actions.

• Core concepts it tracks:

  • Session: a single login (a TTY, SSH, or GUI login), each placed in its own .scope cgroup.

  • Seat: a set of hardware (screen, keyboard, mouse) assigned to one physical workspace; seat0 is the default.

  • User: aggregates all of one user's sessions and owns the user@UID.service manager.

• Responsibilities:

  • Grants device access (via ACLs / udev tags) to the active session so the logged-in user controls the hardware.

  • Handles power and idle actions: lid switch, power/suspend keys, and inhibitor locks.

  • Manages $XDG_RUNTIME_DIR creation and cleanup, and triggers lingering user managers.

• Tooling: Inspect with loginctl list-sessions, loginctl list-seats, and loginctl show-session.

systemd-logind watches ACPI power events (power button, suspend key, lid switch) and takes a configurable action defined in logind.conf, such as suspending or powering off, but it defers to the desktop environment when one has taken an inhibitor lock.

• Key settings in /etc/systemd/logind.conf:

  • HandlePowerKey, HandleLidSwitch, HandleSuspendKey, HandleHibernateKey each accept values like poweroff, suspend, hibernate, ignore, or lock.

  • HandleLidSwitchExternalPower and HandleLidSwitchDocked override behaviour when on AC or docked.

• Inhibitor locks: A GUI (GNOME, KDE) can take a lock so logind ignores the raw event and lets the DE handle it; systemd-inhibit --list shows active locks.

• Applying changes: Edit the config and run systemctl restart systemd-logind (note: this may disrupt active sessions).

Work outward from status to logs to configuration: confirm what systemd thinks happened, read the journal for the actual error, then validate the unit and its environment.

1. Check the status: systemctl status <unit> shows active/failed state, the exit code, and the last log lines.

2. Read the logs: journalctl -u <unit> -b for this boot; add -e to jump to the end or -f to follow live.

3. Interpret the failure: Note Result= (e.g. exit-code, timeout, signal) and the exit status to distinguish a crash from a config or permission error.

4. Validate the unit: systemd-analyze verify <unit> catches syntax/directive mistakes; systemctl cat <unit> shows the effective merged file including drop-ins.

5. Reproduce manually: Run the ExecStart command as the service user to isolate app errors from unit issues; check WorkingDirectory, User, and environment.

6. Reload and retry: After edits, systemctl daemon-reload then restart; forgetting the reload is a common cause of stale behaviour.