systemd Interview Questions: Service Dependencies, Restart Loops, and Logs

systemd interview questions often sound like command-line trivia, but strong answers show how you move from a service symptom to a testable cause. For a unit that will not start, explain the dependency graph, process exit, restart policy, and journal evidence as one chain. A restart loop is not fixed by restarting faster: first determine why the process exits.

What does systemd actually guarantee?

Start with the unit graph. A unit can require another unit, want it, or be ordered before or after it. Those are related but distinct ideas: Requires= and Wants= affect which units are pulled into a transaction; After= and Before= express ordering. After=network-online.target alone does not start that target, and reaching it does not prove that a particular remote API or database is healthy.

That distinction is a common interview hinge. If an application must have another local unit started first, state the requirement and the ordering separately. If it needs a remote dependency, describe bounded application-level retries, timeouts, and a clear unhealthy state instead of treating a boot target as a readiness probe.

How do you debug a unit that repeatedly restarts?

Build a timeline before editing the unit. Check systemctl status example.service for the latest state and exit result, then inspect journalctl -u example.service -b for this boot. If restarts have buried the first failure, narrow by time or inspect the earliest relevant entries. The first causal error is more useful than the final restart message.

1. Confirm the unit name, active state, last result, and recent restart count.
2. Read the unit and any drop-ins with systemctl cat example.service.
3. Check the exact executable, arguments, working directory, user, environment files, and file permissions.
4. Compare Type= with the process behavior. A forking daemon, a foreground process, and a one-shot command have different completion signals.
5. Change one suspected cause, reload the manager if unit files changed, then observe a full start and stop cycle.

For example, an ExecStart=/opt/app/server command may work in an interactive shell because the shell supplies a PATH, current directory, or environment variable that the service does not have. Prefer explicit executable paths and declared environment. Do not copy secrets into a unit file or paste them into interview notes.

When is a restart policy the wrong fix?

Restart=on-failure can recover a process after a transient crash; it cannot repair a missing configuration file, invalid credentials, or a deterministic bad deployment. Restart=always may be appropriate for some long-running services, but it still needs a deliberate start-rate policy and useful alerting. Otherwise a permanent fault becomes a noisy loop that consumes resources and obscures the original error.

Distinguish three cases in your answer: a transient fault that is safe to retry, a persistent configuration fault that needs operator action, and a clean exit that represents successful completion. Explain what exit statuses mean for the service and how the chosen policy treats them. Avoid presenting one restart setting as universally correct; the service type and recovery objective decide.

How should dependencies and shutdown ordering be explained?

Describe the relationship from the consumer's perspective. If service A must be available before B begins, say whether B should pull A into the transaction and whether B must start after A. Then ask what should happen when A stops. Ordering constraints also matter during shutdown, where systemd reverses applicable start ordering. A robust service still handles dependency loss at runtime; startup ordering is not a permanent health guarantee.

Directive or evidence	What it answers	What it does not prove
Wants=	Should another unit be pulled in as a weaker relationship?	That it starts successfully or is ready
Requires=	Is the other unit required for this transaction?	That the application-level dependency is reachable
After=	Which unit is ordered first?	That the earlier unit is healthy
Journal and exit result	What happened during this attempt?	That a later restart fixed the root cause

What is a strong answer to a realistic incident prompt?

Suppose a newly deployed API enters a restart loop after boot. A weak answer immediately adds a longer delay or changes Restart=. A stronger answer first asks whether the failure is deterministic, identifies the first nonzero exit, checks the effective unit including drop-ins, and verifies the runtime user can read its configuration. If the log says the database is unavailable, distinguish a local ordering issue from remote readiness and connection retry behavior.

Then make the smallest reversible change. State the success condition: the service reaches its expected active state, responds to a health check, and remains stable beyond the prior failure interval. Also state the rollback and what logs or metrics you will watch. In an interview, this sequence demonstrates diagnosis, not just familiarity with commands.

What should you inspect when status looks healthy but the service is not?

“Active” describes a unit state, not necessarily application correctness. A process can remain alive while requests fail, serve stale data, or be unable to reach a downstream service. Pair systemd state with an application-level health signal and the relevant request or dependency logs. If the unit is considered started too early, explain whether the service's notification/readiness mechanism matches its actual startup lifecycle.

Also distinguish the manager’s view from the process’s view: the service may run as a different user, under a different environment, with different filesystem access and resource limits than your shell. Reproduce those conditions instead of declaring success because a command works as root.

How can you make the interview answer precise?

Use this compact structure: name the observed symptom; identify the systemd state and first relevant log; explain the unit relationship or process contract; test one cause; verify both unit and application health; and describe recovery limits. If the prompt omits details, say which version, unit type, or failure policy you would confirm. That is better than inventing defaults.

Common follow-up questions

• DoesAfter=start the named unit? No. It defines ordering; a dependency or another transaction must pull the unit in.
• Doesnetwork-online.targetmean my database is ready? No. It is not a per-destination application health check.
• Should every service use automatic restart? No. Choose policy based on whether a failure is retryable, how completion is represented, and how persistent faults are surfaced.
• Where do you start when logs are noisy? Establish the unit and boot/time window, then find the earliest causal failure before tuning restart behavior.

Sources and further reading

• systemd.service documentation: service types and restart behavior
• systemd.unit documentation: dependencies and ordering

Research checked September 23, 2026. Unit semantics and available directives can vary by systemd version; verify the target environment.