LFCS Service Configuration Practice Question
Exhibit
$ cat /etc/systemd/system/backup.service [Unit] Description=Backup Service After=network.target [Service] Type=oneshot ExecStart=/usr/local/bin/backup.sh User=backup Restart=on-failure RestartSec=30 [Install] WantedBy=multi-user.target $ systemctl show backup.service -p Restart Restart=no
Refer to the exhibit. The service unit file has Restart=on-failure, but systemctl show displays Restart=no. What is the most likely reason?
⚠ Common exam trap
Linux Foundation often tests the distinction between editing a unit file and reloading the daemon, trapping candidates who assume changes take effect immediately without running `systemctl daemon-reload`.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
The unit file was edited but systemctl daemon-reload was not run.
The most likely reason is that the unit file was edited but `systemctl daemon-reload` was not executed. When a service unit file is modified, systemd does not automatically reload the configuration; it continues to use the cached version until `systemctl daemon-reload` is run. This explains why `systemctl show` displays `Restart=no` despite the file containing `Restart=on-failure`.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The User=backup directive overrides Restart.
Why it's wrong here
User= sets the account the service runs as; it has no bearing on restart behaviour, so it cannot force Restart=no. It is tempting because a drop-in override can alter unit settings, but only directives of the same name override, and User= is not one of them.
- ✓
The unit file was edited but systemctl daemon-reload was not run.
Why this is correct
Editing a unit file does not alter the loaded configuration; systemd caches unit definitions until `systemctl daemon-reload` re-reads them. Because the stale in-memory copy still holds the original `Restart=no`, `systemctl show` reports that value, satisfying the stem's mismatch between the file's `Restart=on-failure` and the displayed setting.
- ✗
The unit is not enabled.
Why it's wrong here
Enabling controls whether the unit starts at boot, not the Restart policy reported by systemctl show. It is tempting because a disabled unit is a common cause of services not running, but here the unit is active; the override comes from a drop-in file that redefines Restart.
- ✗
The Restart directive is only valid for Type=simple.
Why it's wrong here
Restart= is valid for Type=simple, forking, notify and others; it is not restricted to Type=simple. It is tempting because Type=simple is the default and most commonly paired with Restart, but the actual cause is a later drop-in file overriding the directive.
Go deeper
Related to this question
About these practice questions
One of 406 original LFCS practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This LFCS practice question is part of Courseiva's free Linux Foundation certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the LFCS exam.