LPIC-1 systemctl Practice Question
An administrator needs to restart the SSH service after a configuration change. Which TWO commands can accomplish this on a systemd-based system?
⚠ Common exam trap
Candidates may incorrectly assume that only `systemctl` works on systemd, but the `service` command is also valid as a compatibility wrapper. Conversely, commands like `initctl` (Upstart) or `/etc/init.d/` script (SysV) are not correct for systemd.
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
✓
systemctl restart sshd
Option C, systemctl restart sshd, is correct because systemctl is the native control utility for systemd, and 'restart' stops and starts the sshd unit in one operation, applying the new configuration. Option D, service sshd restart, is also correct because the service wrapper script on systemd-based distributions translates the request into the appropriate systemctl restart sshd call, so it works on such systems. Option A, initctl restart sshd, belongs to Upstart and is not the systemd interface. Option B, rc.d restart sshd, is not a valid command form for the BSD-style rc.d mechanism. Option E, /etc/init.d/sshd restart, invokes a legacy SysV init script directly, which may exist for compatibility but is not the systemd method and is not guaranteed to be present or functional.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
initctl restart sshd
Why it's wrong here
initctl is the Upstart control command, so it cannot manage units on a systemd-based system and typically reports no such job. It is tempting because it restarted services on older Ubuntu releases, and would be correct on an Upstart host, but systemd uses systemctl restart sshd instead.
- ✗
rc.d restart sshd
Why it's wrong here
rc.d is the SysV init wrapper; on a systemd host it delegates inconsistently or fails outright, since sshd is managed as an sshd.service unit. It tempts because rc.d scripts remain valid on legacy SysV systems, where restarting services through init scripts is the standard mechanism.
- ✓
systemctl restart sshd
Why this is correct
`systemctl restart sshd` stops and starts the SSH daemon in one operation, applying the edited configuration immediately. It satisfies the systemd-based constraint by communicating directly with the service manager, which tracks the unit and its dependencies. Unlike `systemctl reload`, it fully terminates existing sessions, guaranteeing the new configuration is read.
- ✓
service sshd restart
Why this is correct
The `service` wrapper delegates to systemd's SysV compatibility layer, translating the request into a restart job for the sshd unit. It satisfies the systemd-based constraint because systemd intercepts the legacy init script call, so the daemon restarts correctly despite the older command syntax.
- ✗
/etc/init.d/sshd restart
Why it's wrong here
On a systemd-based system, /etc/init.d/sshd restart invokes the legacy SysV wrapper, which may be absent or bypass systemd's unit state tracking. It is tempting because it worked on SysV init systems, and would be correct there, but systemd requires systemctl restart sshd or sshd.service.
Go deeper
Related to this question
About these practice questions
This LPIC-1 question is part of Courseiva's 402-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This LPIC-1 practice question is part of Courseiva's free LPI 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 LPIC-1 exam.