System Services and Process Management

Objective. Students will manage Linux services with systemctl, monitor and control processes with ps, top, kill, and nice, and configure a simple custom systemd unit file.

What Is a Linux Service?

A service (also called a daemon) is a background program that starts automatically and waits to respond to requests — a web server, a database engine, or a logging agent, for example. On modern Linux distributions, the systemd init system manages these services. It is the first process launched by the kernel (PID 1) and is responsible for bringing the rest of the system up in the correct order.

Managing Services with systemctl

`systemctl` is the command-line tool that communicates with systemd. The most common operations are:

| Action | Command |

|---|---|

| Start a service right now | `sudo systemctl start apache2` |

| Stop a running service | `sudo systemctl stop apache2` |

| Restart a service | `sudo systemctl restart apache2` |

| Check current status | `sudo systemctl status apache2` |

| Enable at boot | `sudo systemctl enable apache2` |

| Disable at boot | `sudo systemctl disable apache2` |

Start vs. Enable — a critical distinction. `start` affects the current session only; the service stops when the machine reboots. `enable` creates a symbolic link so systemd starts the service automatically on every future boot, but it does not start the service right now. In practice you often run both: `sudo systemctl enable --now apache2` starts the service and enables it in a single step.

Monitoring Processes

Every running program is a process with a unique PID (Process ID). Two essential tools for watching processes are:

`ps aux` — prints a static snapshot of all running processes. Columns include USER, PID, %CPU, %MEM, and COMMAND. Use `ps aux | grep apache2` to find a specific process.
`top` — displays a live, updating view. Processes are sorted by CPU usage by default. Inside `top`, press `k` to kill a process by PID, `r` to renice it, and `q` to quit.

Controlling Priority with nice and renice

Linux schedules CPU time partly based on a process's nice value, which ranges from -20 (highest priority, least nice to other processes) to +19 (lowest priority, most yielding). The default nice value is 0.

Launch a process at a specific nice value: `nice -n 10 ./my_script.sh`
Change the nice value of a running process: `sudo renice -n 15 -p 3472` (where 3472 is the PID)

Only the root user (or a user with appropriate privileges via `sudo`) can lower a nice value (increase priority). Any user can raise their own process's nice value.

Stopping Processes with kill

`kill` sends a signal to a process. Common signals:

SIGTERM (15) — politely asks the process to shut down and clean up. Always try this first.
SIGKILL (9) — forces immediate termination; the process cannot ignore or handle it. Use only when SIGTERM fails.

Syntax: `kill -15 <PID>` or `kill -SIGTERM <PID>`. After sending SIGTERM, wait a few seconds, then run `ps aux | grep <PID>` to confirm the process is gone before escalating to SIGKILL.

Writing a Custom systemd Unit File

A unit file is a plain-text configuration file that tells systemd how to manage a service. Unit files for custom services live in `/etc/systemd/system/`. A minimal service unit file has three sections:

```ini

[Unit]

Description=Deploy Check Service

After=network.target

[Service]

Type=oneshot

ExecStart=/usr/local/bin/deploy_check.sh

RemainAfterExit=yes

[Install]

WantedBy=multi-user.target

```

`[Unit]` — human-readable description and ordering dependencies.
`[Service]` — how to run the service. `Type=oneshot` means the script runs once and exits. `RemainAfterExit=yes` lets systemd consider the unit active after the script finishes.
`[Install]` — defines which target (runlevel equivalent) enables this service. `multi-user.target` is the standard multi-user, non-graphical boot target.

After placing the file (e.g., `/etc/systemd/system/deploy-check.service`), always run `sudo systemctl daemon-reload` to make systemd read the new file before enabling or starting it.

Safety and Best Practices

Never send SIGKILL to a database or file-system process without trying SIGTERM first. Abrupt termination can corrupt data or leave locks in place.
Check unit file syntax with `systemd-analyze verify /etc/systemd/system/deploy-check.service` before enabling.
Do not edit unit files in `/usr/lib/systemd/system/` — those are owned by packages and can be overwritten by updates. Custom or overriding files belong in `/etc/systemd/system/`.
On a shared lab VM, avoid running `kill -9 1` or targeting PID 1 (systemd itself); this will crash the system for all users.
Scripts run by systemd as root should have restrictive permissions (`chmod 750`) and be owned by root to prevent privilege escalation.

Key terms10

systemdThe init system used by most modern Linux distributions; it is the first user-space process (PID 1) and manages all other services and their startup order.

systemctlThe command-line utility used to interact with systemd — starting, stopping, enabling, disabling, and inspecting services and units.

unit fileA plain-text INI-style configuration file that describes a systemd-managed resource (service, socket, timer, etc.) and how it should be started and ordered.

daemon-reloadThe systemctl subcommand (`systemctl daemon-reload`) that instructs systemd to re-read all unit files from disk after a new or changed file is placed in the unit directories.

nice valueA number from -20 (highest CPU scheduling priority) to +19 (lowest) that influences how much CPU time the scheduler grants a process relative to others.

SIGTERMSignal number 15; a graceful termination request that allows a process to clean up resources before exiting. It is the preferred first signal to send when stopping a process.

SIGKILLSignal number 9; an immediate, forced termination that cannot be caught or ignored by the process. Used only when SIGTERM fails to stop a process.

PIDProcess ID — a unique integer the kernel assigns to every running process, used to target processes with commands such as kill and renice.

enable (systemctl)A systemctl action that creates a symbolic link so a service starts automatically on future boots; it does not start the service in the current session.

multi-user.targetThe systemd target that represents a fully operational multi-user, non-graphical system state; the standard boot target for servers and most headless Linux systems.

In class: Lab exercise: students start, stop, enable, disable, and check the status of Apache2 using systemctl; they record the difference between 'start' and 'enable' in their lab logs with a concrete example. · Process control drill: instructor launches a CPU-intensive background process with a low nice value; students identify it using top, renice it to a higher value, and finally kill it gracefully with SIGTERM then confirm it is gone. · Custom unit file: students create a systemd service unit file that runs their deploy_check.sh script on boot, place it in /etc/systemd/system/, reload the daemon, enable the service, and verify it appears in 'systemctl list-units'.
Materials: Student VMs, systemd man pages (systemctl, systemd.service), lab instruction sheet
Check: Instructor verifies that the custom unit file loads without errors (systemctl status shows 'loaded'), the service is enabled, and the process control drill steps are documented correctly in the lab log — pass requires all three items confirmed.

Practice check8

Answer each question, then check it. Nothing is recorded; this is your own practice.