10.3 Start, Stop, and Check Status of Network Services

10.3 Start, Stop, and Check Status of Network Services

Quick Answer: Control network services with systemctl start|stop|restart|reload|status UNIT. Confirm with is-active and is-enabled. On RHEL 10, master sshd, NetworkManager, and firewalld as the usual network-related units. Read failures via systemctl status and journalctl -u. Do not stop remote access services without a recovery plan.

Scope of this objective

Under Operate running systems, you must start, stop, and check the status of network services. Related skills appear again under deploy/maintain systems (enable at boot) and networking (addresses, hostname, firewall rules). Here the core is runtime control and status of services that provide or affect network access.

You will repeatedly use:

systemctl status UNIT
systemctl start UNIT
systemctl stop UNIT
systemctl restart UNIT
systemctl reload UNIT
systemctl is-active UNIT
systemctl is-enabled UNIT
systemctl --failed

systemctl verbs that matter

sudo systemctl start sshd
sudo systemctl stop httpd
sudo systemctl restart firewalld
sudo systemctl reload sshd          # if unit supports reload
systemctl status NetworkManager
systemctl is-active NetworkManager
systemctl is-enabled NetworkManager

Active means running now. Enabled means started as part of the configured boot target. A service can be active but disabled (started manually) or enabled but failed (should start at boot but is not running).

The big three network-related services

1) sshd — remote login

Unit name: sshd.service (often referenced as sshd).

systemctl status sshd
sudo systemctl start sshd
sudo systemctl reload sshd    # common after sshd_config changes when supported
sudo systemctl restart sshd

After config edits to /etc/ssh/sshd_config or drop-ins under /etc/ssh/sshd_config.d/:

sudo sshd -t                  # syntax test BEFORE restart
sudo systemctl reload sshd || sudo systemctl restart sshd
systemctl is-active sshd

Remote exam danger: Restarting sshd with a broken config can lock you out. Always sshd -t first. Prefer reload when valid. Keep a console session if available.

2) NetworkManager — connectivity

Unit: NetworkManager.service.

systemctl status NetworkManager
systemctl is-active NetworkManager
nmcli general status
nmcli device status
nmcli connection show

Stopping NetworkManager can drop interfaces and kill your SSH session on a DHCP-only remote host. On EX200, start/stop/status tasks are common; do not casually systemctl stop NetworkManager on the only link you use unless the task requires it and you understand the impact.

Bring connections up/down with nmcli (networking chapter depth) while NetworkManager remains running:

nmcli connection up "System eth0"
nmcli device connect eth0

3) firewalld — host firewall

Unit: firewalld.service.

systemctl status firewalld
sudo systemctl start firewalld
sudo systemctl reload firewalld
firewall-cmd --state
firewall-cmd --get-default-zone
firewall-cmd --list-all

Runtime vs permanent firewall rules are a security/networking objective. Here, ensure you can start/stop/status the service. If firewall-cmd says the firewall is not running, start the unit:

sudo systemctl start firewalld
firewall-cmd --state

Checking status like an examiner

systemctl status sshd -l --no-pager

Read:

1. Loaded line — unit file path; enabled/disabled/static/masked.
2. Active line — active (running), inactive (dead), failed, activating.
3. Main PID and tasks.
4. Recent journal lines attached to the status.

Script-friendly:

systemctl is-active sshd; echo $?
systemctl is-enabled sshd; echo $?

List all failed:

systemctl --failed
systemctl list-units --type=service --state=failed

restart vs reload vs stop/start

systemctl show -p CanReload sshd

If reload fails with “Job type reload is not applicable,” use restart.

Safe workflows on a network host

Ensure sshd is running (without locking yourself out)

sudo sshd -t && sudo systemctl reload sshd
systemctl is-active sshd
ss -tlnp | grep ':22'    # or the configured port

Recover a stopped firewalld when a task needs it active

systemctl is-active firewalld
sudo systemctl start firewalld
firewall-cmd --state

Inspect NetworkManager after boot

systemctl is-enabled NetworkManager
systemctl is-active NetworkManager
nmcli -g GENERAL.STATE device show
journalctl -u NetworkManager -b -p err --no-pager

Enablement vs this section

Tasks often mix:

• “Start the service now” → systemctl start / --now
• “Start and enable” → systemctl enable --now UNIT

sudo systemctl enable --now firewalld
systemctl is-enabled firewalld
systemctl is-active firewalld

Enablement depth continues in deploy chapters; still, you must read is-enabled when checking status of network services on the exam.

Diagnosing failed network services

sudo systemctl start sshd
systemctl is-active sshd || sudo systemctl status sshd -l --no-pager
sudo journalctl -u sshd -b -p err --no-pager

Common failure classes:

Socket-activated services exist on systemd systems; if a task mentions a socket unit, check both .socket and .service. For classic sshd on RHEL exam images, managing sshd.service is the usual path.

systemctl cat sshd
systemctl list-sockets | grep -i ssh

Other network-adjacent units you may meet

Depending on the lab image:

Apply the same systemctl discipline to any named unit the task gives you.

Exam scenarios

Scenario A — “Start and confirm firewalld”

sudo systemctl start firewalld
systemctl is-active firewalld
firewall-cmd --state

Scenario B — “sshd is not running; fix it”

systemctl status sshd -l --no-pager
sudo journalctl -u sshd -b -n 30 --no-pager
sudo sshd -t
# fix config errors found
sudo systemctl start sshd
systemctl is-active sshd

Scenario C — “Restart NetworkManager and verify devices”

sudo systemctl restart NetworkManager
systemctl is-active NetworkManager
nmcli device status

If SSH drops, reconnect after NM settles—wait a few seconds before assuming failure.

Scenario D — “Show status of all failed services”

systemctl --failed --no-pager

Common traps

1. Stopping sshd on a remote-only system with a bad config—no way back without console.
2. Confusing inactive with disabled — start ≠ enable.
3. Using kill on sshd instead of systemctl—orphans and inconsistent unit state.
4. Assuming status green means ports open — still verify with ss/firewall-cmd when connectivity is the real issue.
5. masking a service by accident — systemctl unmask UNIT to recover.
6. Restarting firewalld mid-rule edit without understanding runtime vs permanent (rule chapters)—still verify --state afterward.
7. Ignoring systemctl --failed after reboot when a network unit did not come up.

Persistence reminder

start alone does not guarantee the service returns after reboot. If the exam wants both running now and after reboot, use enable --now and verify with a reboot when required. This section still requires you to check enablement status accurately.

Section checkpoint

You should start, stop, restart, and reload network-related units with systemctl; interpret status/active/enabled/failed; operate safely around sshd, NetworkManager, and firewalld; diagnose failures with status plus journals; and verify the runtime end state the task names. That is the EX200 bar for controlling network services.