Deploy, configure, and maintain systems →easyMultiple Choice

EX200 Deploy, configure, and maintain systems Practice Question

Exhibit

# systemctl status sshd
● sshd.service - OpenSSH server daemon
   Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2023-03-20 10:15:00 EDT; 2 weeks 3 days ago
     Docs: man:sshd(8)
           man:sshd_config(5)
 Main PID: 1234 (sshd)
    Tasks: 1 (limit: 23456)
   Memory: 4.2M
   CGroup: /system.slice/sshd.service
           └─1234 /usr/sbin/sshd -D

Refer to the exhibit. The SSH service has been running for 2 weeks. An administrator wants to restart the service without interrupting existing SSH connections. Which command should they use?

⚠ Common exam trap

A common mix-up: candidates confuse `reload` with `restart`, assuming both achieve the same result, but `restart` terminates all active connections while `reload` preserves them, and Red Hat often tests this distinction to catch those who overlook the 'without interrupting' requirement.

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 reload sshd

`systemctl reload sshd` sends a SIGHUP signal to the SSH daemon, instructing it to reload its configuration file without terminating existing connections. This is the standard method for applying configuration changes to services that support graceful reloads, such as sshd, which maintains persistent sessions by only re-reading its configuration and not restarting the process.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✓
systemctl reload sshd
Why this is correct
Correct. systemctl reload sshd sends a SIGHUP to the sshd main process via the service unit's ExecReload directive. sshd then reparses /etc/ssh/sshd_config and applies changes (like new ciphers or Port settings) to future connections. Existing sessions are not interrupted because their already-established state and options are preserved, making this the safe way to apply most configuration changes without dropping users.
✗
systemctl stop sshd; systemctl start sshd
Why it's wrong here
Incorrect. This two-step sequence performs a full stop of the sshd service, which under systemd's default KillMode=control-group sends SIGTERM to the main sshd process and then kills any remaining processes in the service cgroup, including per-connection session processes. As a result, all active SSH sessions are forcibly terminated. Starting the service afterward brings up a fresh daemon, but the disruption is equivalent to a full restart and is never appropriate when the goal is a non-disruptive configuration reload.
✗
kill -HUP 1234
Why it's wrong here
Incorrect. Sending SIGHUP to the sshd process (PID 1234 is used only as an example; you would need the actual pid from egrep /var/run/sshd.pid or pgrep sshd) does cause sshd to reload its configuration, and existing connections remain intact. However, this approach bypasses systemd's service management layer: it requires manually locating the correct master PID, does not update systemd's notion of the service state, and may fail if sshd is not running as expected. systemctl reload sshd is the supported, deterministic method in RHEL, so this manual kill is not the best answer.
✗
systemctl restart sshd
Why it's wrong here
Incorrect. systemctl restart sshd performs a full service stop and start: systemd sends SIGTERM to the main sshd process, which, along with the cgroup cleanup, kills all active SSH sessions and any processes spawned from them (like shell commands or port forwards). Then a new sshd daemon is started from scratch. While a restart does pick up configuration changes, it force-disconnects all users, so it is not a zero-disruption operation and is the wrong choice when trying to avoid dropping existing connections.

Go deeper

EX200 Deploy, configure, and maintain systems Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question