Sample questions
Linux Systemd Service ManagementDifficulty 1
A systemd unit file for a service is typically split into which three sections, and what does each one primarily hold?
- a[Unit], [Service], [Install] — general metadata/dependencies, service-specific execution settings, and installation (enablement) info, respectively✓
- b[Meta], [Process], [Boot] — metadata, runtime process settings, and boot ordering, respectively, a naming scheme some engineers assume by analogy with Windows Service Manager property categories
- c[Config], [Run], [Start] — configuration values, the run command, and a separate start trigger similar to a Makefile target, respectively, though no such section names exist in the systemd unit grammar
- d[Header], [Body], [Footer] — a naming convention borrowed from HTTP, purely cosmetic and silently ignored by systemd's unit file parser at load time
Explanation:A typical .service unit has [Unit] (general metadata and relationships to other units, e.g. Description=, After=), [Service] (how the process itself is run, e.g. ExecStart=, Restart=), and [Install] (how enabling the unit hooks it into a target, e.g. WantedBy=). The other section names do not exist in systemd.
Linux Systemd Service ManagementDifficulty 1
In a .service unit file, what kind of directives typically belong in the [Unit] section?
- aThe exact command line used to start the service process (ExecStart=), since [Unit] is sometimes incorrectly assumed to hold the primary execution directive instead of [Service]
- bGeneral metadata and unit relationships — such as Description=, After=, Requires= — that apply regardless of the unit's type✓
- cOnly the WantedBy= directive that controls which target enables the unit, conflating [Unit]'s ordering hints with the enablement wiring that actually lives in [Install]
- dRestart policy directives such as Restart=on-failure, under the mistaken assumption that failure-handling belongs with general unit metadata rather than the service-specific execution block
Explanation:[Unit] holds generic, type-independent metadata and ordering/dependency directives (Description=, After=, Requires=, Wants=). ExecStart= and Restart= belong in [Service]; WantedBy= belongs in [Install].
Linux Systemd Service ManagementDifficulty 1
Which directive would you expect to find in the [Service] section of a systemd unit rather than in [Unit] or [Install]?
- aDescription=, a human-readable one-line summary of the unit that also shows up in
systemctl status output and journal entries - bAfter=, an ordering hint relative to other units that many engineers assume also implies a hard dependency like Requires=
- cExecStart=, defining the command that is run when the service starts✓
- dWantedBy=, the target that pulls this unit in when enabled, a directive that is often mistakenly expected inside [Service] itself
Explanation:ExecStart= is a [Service]-section directive: it defines the actual command systemd runs for this specific service. Description= and After= are generic [Unit] directives; WantedBy= is an [Install] directive.
Linux Systemd Service ManagementDifficulty 1
What is the purpose of the [Install] section in a unit file?
- aIt defines the process that is actually executed by the service, since [Install] is sometimes mistakenly treated as an alternate place to declare ExecStart= alongside [Service]
- bIt only holds documentation strings meant for humans reading the file, similar to a code comment block that systemd itself never parses or acts on at runtime
- cIt sets resource limits like CPU and memory quotas for the service, a responsibility that actually belongs to cgroup-related directives such as CPUQuota= inside [Service]
- dIt defines how the unit is hooked into targets (e.g. WantedBy=) so that
systemctl enable knows which symlink to create for boot-time activation✓
Explanation:[Install] is only consulted by systemctl enable/disable: it tells systemd which target's .wants/ directory should get a symlink to this unit. It has no effect on how the service actually runs.
Linux Systemd Service ManagementDifficulty 2
A junior engineer runs systemctl start myapp and the service comes up correctly. After the next reboot, though, it is not running. What is the most likely explanation?
- a
systemctl start starts a service immediately for the current session but does not create the boot-time symlink that systemctl enable creates✓ - bThe unit file must have been deleted automatically after the first start, which does not match how systemd persists unit files on disk independently of runtime state
- c
systemctl start only works when the machine is already fully booted, so it can never take effect after any future reboot — conflating the transient runtime state start manages with the persistent boot-time symlinks that only enable creates - dServices always require a
systemctl daemon-reload after every reboot, and that step was skipped, even though daemon-reload only re-parses changed unit definitions and has nothing to do with automatic startup on boot
Explanation:start and enable are independent actions: start affects only the current runtime state, while enable is what makes systemd bring the unit up automatically on future boots by creating a symlink under the relevant target's .wants/ directory.
Linux Systemd Service ManagementDifficulty 1
What information does systemctl status myapp.service typically show at a glance?
- aOnly whether the associated network port is open, treating
systemctl status as equivalent to a port-scanning tool like ss rather than a unit-state summary - bWhether the unit is active/inactive/failed, since when, the main PID, and a short tail of recent log lines✓
- cOnly the contents of the unit file, without any runtime state, as if it behaved like a plain
cat of the file stored on disk - dOnly the last exit code, without any timestamp information, ignoring the active-state and main PID fields the command actually prints
Explanation:systemctl status gives a compact runtime summary: current active state, how long it has been in that state, the main process PID (if running), and the most recent journal lines for that unit — useful as a first triage step.