Loading...

VONDS ©

Lab 36: Managing Services with systemctl

Lab Index

Inspect systemd targets and services, then validate operational control by restarting a critical service safely. Disable and hard-block a non-approved service, then apply configuration changes correctly using daemon reload and re-exec.

services core troubleshooting

Scenario

You are on a production server that runs multiple services. Your team lead asks you to confirm the system’s default target, review loaded services, validate SSH health, and remove a non-approved web service from startup. You also need to apply systemd configuration changes correctly after unit edits.

Operator context

This is the baseline service-control workflow you use before you escalate to “the service is broken” or assume the system “is not using systemd.”

Objective

  • Confirm the system’s default boot target.
  • List loaded services and identify key daemons.
  • Inspect and restart the SSH service safely.
  • Disable a service from starting at boot.
  • Mask a service to prevent manual starts.
  • Apply systemd changes via daemon-reload and daemon-reexec.

What You’ll Practice

  • systemd target awareness and default run mode validation.
  • Service inventory and quick triage using systemctl list-units.
  • Service health inspection and controlled restarts.
  • Startup control with enable/disable semantics.
  • Hard prevention using systemctl mask.
  • Applying unit changes correctly ( daemon-reload vs daemon-reexec ).

Walkthrough

Step 1 : Check the current runlevel target (default boot target).
Command 
systemctl get-default

The default target tells you what the system is designed to boot into. It’s the systemd equivalent of asking “is this a server-style boot” vs “graphical workstation.” 

multi-user.target
Step 2 : View all loaded services.
Command 
systemctl list-units --type=service

This provides a runtime view of currently loaded services and their states. It is a fast way to confirm what is active and what is failing. 

UNIT                           LOAD   ACTIVE SUB     DESCRIPTION
ssh.service                    loaded active running OpenBSD Secure Shell server
cron.service                   loaded active running Regular background program processing daemon
systemd-journald.service       loaded active running Journal Service
... (truncated)
Step 3 : Check the status of the SSH service.
Command 
systemctl status ssh

Status output is your “single pane of glass” for service state, recent log lines, and the unit file path. It’s the quickest way to confirm whether the daemon is healthy. 

● ssh.service - OpenBSD Secure Shell server
   Loaded: loaded (/lib/systemd/system/ssh.service; enabled)
   Active: active (running) since Fri 2025-07-18 10:22:13 UTC; 3h 22min ago
   Docs: man:sshd(8)
         man:sshd_config(5)
Step 4 : Restart the SSH service.
Command 
sudo systemctl restart ssh

Restarting SSH is a common operational task, but it must be done deliberately because it can impact remote access. In a real change window, you validate a fallback session or console access first. 

Service 'ssh' restarted successfully.
Step 5 : Disable a service from starting on boot.
Command 
sudo systemctl disable apache2

Disabling a unit removes it from the target’s wants and prevents it from starting automatically at boot. It does not prevent manual starts. 

Removed /etc/systemd/system/multi-user.target.wants/apache2.service.
Step 6 : Mask the service so it cannot be started manually.
Command 
sudo systemctl mask apache2

Masking is a stronger control than disabling. It blocks the unit from being started, even manually, by linking it to /dev/null. 

Created symlink /etc/systemd/system/apache2.service → /dev/null.
Step 7 : Reload systemd configuration after editing unit files.
Command 
sudo systemctl daemon-reload

daemon-reload makes systemd re-read unit files. Use this after you edit unit definitions or drop-ins so the manager picks up the new configuration. 

Systemd manager configuration reloaded.
Step 8 : Re-execute systemd to reflect deeper manager changes.
Command 
sudo systemctl daemon-reexec

daemon-reexec re-executes the systemd manager process itself. This is used for deeper internal manager changes, such as updated systemd binaries or manager-level behavior changes. 

Systemd manager re-executed successfully.

Reference

  • systemctl get-default : Prints the default boot target (the intended boot mode).
  • systemctl list-units --type=service : Lists loaded service units and their runtime state.
  • systemctl status <service> : Shows service health, recent log lines, and unit file location.
  • systemctl restart <service> : Restarts a service immediately (may briefly disrupt connections).
  • systemctl disable <service> : Prevents a service from starting at boot by removing its wants link from the target.
  • systemctl mask <service> : Hard-blocks a service from starting (even manually) by linking it to /dev/null.
  • systemctl daemon-reload : Reloads unit files after changes to unit definitions or drop-ins.
  • systemctl daemon-reexec : Re-executes the systemd manager process to reflect deeper manager-level changes.
"