Processes and systemd

After this lesson, you will be able to: Inspect and manage Linux processes: ps, top, htop, kill, background jobs, and the systemd basics every admin uses.

Every running command is a process. Knowing how to see, find, and stop them is the difference between fixing a stuck server in 30 seconds and rebooting it.

Prerequisites:File Permissions

Inspecting processes

Use ps for snapshots, top/htop for live views.

tsx

ps                          # processes in your current shell
ps aux                      # ALL processes, full info
ps aux | grep nginx         # filter by name
ps -ef --forest             # tree view (parent → child)

top                         # live process view (q to quit)
htop                        # nicer; install with apt or brew

# Show the top 5 CPU eaters
ps -eo pid,user,%cpu,%mem,cmd --sort=-%cpu | head -n 6

Killing processes safely

Kill sends signals; the default (SIGTERM) is polite, SIGKILL is brutal.

tsx

kill 12345                 # SIGTERM (graceful)
kill -TERM 12345           # same as above
kill -KILL 12345           # SIGKILL (force, no cleanup)
kill -9 12345              # same (9 = SIGKILL)
kill -HUP 12345            # SIGHUP (re-read config, used by nginx etc)

pkill nginx                # kill all processes named nginx
killall -9 chromium        # killall by name with SIGKILL

# Always try SIGTERM first; SIGKILL leaves files / locks in bad state

Background jobs and job control

Run things in the background; bring them forward when needed.

tsx

long-command &              # run in background
jobs                        # list background jobs
fg %1                       # bring job 1 to foreground
bg %1                       # resume job 1 in background
Ctrl-Z                      # suspend current foreground job
Ctrl-C                      # send SIGINT (stop running)

nohup long-command &        # run detached from your shell
# Even better:
screen / tmux               # persistent shell sessions that survive disconnect

systemd: the modern Linux service manager

Almost every Linux distro since 2015 uses systemd to manage services (background processes). A 'unit file' (e.g. `/etc/systemd/system/myapp.service`) describes how to start, stop, restart, and depend on your service. systemctl is the CLI: `systemctl start nginx`, `systemctl status nginx`, `systemctl enable nginx` (start on boot). journalctl reads systemd logs: `journalctl -u nginx -f` follows nginx logs.

A real systemd unit file

Drop this in /etc/systemd/system/myapp.service to manage a Node.js app.

tsx

[Unit]
Description=My Node.js app
After=network.target

[Service]
Type=simple
User=myapp
WorkingDirectory=/srv/myapp
ExecStart=/usr/bin/node server.js
Restart=on-failure
RestartSec=5
Environment=NODE_ENV=production
EnvironmentFile=/etc/myapp/env

[Install]
WantedBy=multi-user.target

# After saving:
# sudo systemctl daemon-reload
# sudo systemctl enable myapp
# sudo systemctl start myapp
# sudo systemctl status myapp
# sudo journalctl -u myapp -f

Common mistakes only experienced engineers avoid

Killing with -9 by default. Always try SIGTERM first; SIGKILL leaves locks and temp files behind. Running long jobs in foreground shells. Lose SSH = lose job. Use tmux or systemd. Skipping `systemctl daemon-reload` after editing unit files; systemd uses the cached old version. Forgetting `Restart=on-failure` in services. Systemd is your free auto-restart; use it. Not setting a non-root `User=` in services. Run apps as a dedicated user, not root.

Quick Check

Your nginx is using 100% CPU and not responding. You need to restart it without rebooting the box. Walk through.

Pick the safe, professional sequence.

←File Permissions

Back to Linux and the Command Line

Networking from the CLI→