LFCS systemctl start Practice Question
A system administrator configures a web server using systemd. After creating a custom service unit file, the administrator runs `systemctl daemon-reload` but the service still fails to start with a 'Unit not found' error. What is the most likely cause?
⚠ Common exam trap
Candidates often overthink the directory paths and forget that a simple typo in the service name is the most common cause of 'Unit not found' errors. The trap is focusing on file placement rather than the exact command used to start the service.
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 service name was misspelled in the `systemctl start` command.
The 'Unit not found' error after `systemctl daemon-reload` typically indicates that systemd cannot locate a unit with the specified name. While correct placement of unit files is important, systemd scans both /etc/systemd/system/ and /usr/lib/systemd/system/ after a daemon-reload. Therefore, placing a custom unit in /usr/lib/systemd/system/ would not cause this error. The most likely cause is that the service name was misspelled in the `systemctl start` command. A simple typo would lead to a 'Unit not found' message because systemd looks for an exact match. Other options like forgetting `systemctl enable` or group membership do not affect unit discovery at start time.
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 administrator forgot to run `systemctl enable` before starting the service.
Why it's wrong here
enable only creates symlinks for boot-time start; it does not affect unit discovery, so 'Unit not found' persists. It is tempting because forgetting enable is a frequent systemd mistake, and would be correct if the unit were found but failed to start automatically at boot.
- ✗
The unit file is placed in /usr/lib/systemd/system/ instead of /etc/systemd/system/.
Why it's wrong here
/usr/lib/systemd/system/ is a valid unit search path, so placement there does not cause 'Unit not found'. It is tempting because /etc/systemd/system/ is the conventional location for custom units, and would be correct if the file were in a non-searched directory.
- ✗
The administrator is not in the 'systemd' group.
Why it's wrong here
systemd has no 'systemd' group governing unit visibility; permissions are not group-based in this way. It is tempting because permission errors are common causes of service failures, and group membership would be correct if the unit file itself were unreadable by the invoking user.
- ✓
The service name was misspelled in the `systemctl start` command.
Why this is correct
systemd resolves units by exact filename, so a typographical error in the unit name passed to systemctl start yields 'Unit not found' even after daemon-reload succeeds. Verifying the spelling against the unit file in /etc/systemd/system corrects the invocation.
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.