4. Procesy, správa procesů a systémové prostředky (ps, top, kill, systemd základy)

Úvod a kontext

Server, na kterém běží webová aplikace, databáze a monitoring, v každém
okamžiku vykonává desítky až stovky souběžných programů — procesů.
DevOps inženýr potřebuje umět zjistit, co na serveru běží, kolik spotřebovává
paměti a procesoru, jak proces bezpečně ukončit a jak zajistit, aby se
důležité služby (webserver, databáze) samy spouštěly po startu systému a
restartovaly po pádu. Právě to je náplní této lekce — procesy a jejich
správa přes klasické nástroje (ps, top, kill) i přes moderní init
systém systemd, který dnes používá naprostá většina linuxových
distribucí.

Teorie

Co je proces

Proces je instance běžícího programu — má vlastní přidělenou paměť,
unikátní identifikátor PID (Process ID) a je ve správě jádra, které mu
přiděluje čas procesoru. Každý proces má svého rodiče (PPID — Parent
PID); první proces po startu systému má PID 1 (u systemd distribucí je to
proces systemd) a je předkem všech ostatních procesů.

Proces může být v různých stavech: běžící (running), spící
(sleeping, čeká na událost jako vstup ze sítě), zombie (proces skončil,
ale rodič si ještě nevyzvedl jeho návratový kód) nebo zastavený
(stopped).

Sledování procesů: ps a top

Příkaz ps (process status) vypíše jednorázový snímek běžících procesů:

ps aux

• a — procesy všech uživatelů,
• u — formát s uživatelským jménem, využitím CPU a paměti,
• x — i procesy bez řídicího terminálu (démoni na pozadí).

Sloupce výpisu obsahují mimo jiné USER (vlastník), PID, %CPU,
%MEM, STAT (stav) a COMMAND (příkaz, kterým byl proces spuštěn).

Pro živé, průběžně se aktualizující sledování slouží top (nebo modernější
htop, pokud je nainstalovaný) — zobrazuje procesy seřazené podle
spotřeby CPU, celkové zatížení systému (load average) a využití paměti,
a aktualizuje se v reálném čase (typicky každou 1–3 sekundy).

Signály a ukončování procesů: kill

Ukončení procesu v Linuxu neprobíhá "vymazáním" procesu, ale odesláním
signálu. Proces může na signál reagovat vlastní obslužnou rutinou (např.
uložit rozdělanou práci), nebo je signál vynucen jádrem bez možnosti
reakce. Nejdůležitější signály:

Signál	Číslo	Význam
SIGTERM	15	zdvořilá žádost o ukončení (výchozí u kill), proces může uklidit
SIGKILL	9	okamžité, nekompromisní ukončení jádrem — proces nemá šanci reagovat
SIGHUP	1	historicky "terminál se odpojil", dnes se často používá jako signál pro znovunačtení konfigurace
SIGINT	2	přerušení, odpovídá stisku Ctrl+C v terminálu

kill 4821            # pošle SIGTERM procesu s PID 4821 — slušná žádost
kill -9 4821          # pošle SIGKILL — vynucené ukončení, poslední možnost
kill -HUP 4821        # požádá proces o znovunačtení konfigurace (u řady démonů)
pkill -f "python app.py"   # najde proces podle jména/příkazu a pošle mu SIGTERM
killall nginx         # ukončí všechny procesy pojmenované "nginx"

Doporučený postup: vždy nejprve zkusit SIGTERM (výchozí chování
kill), aby proces stihl uklidit otevřené soubory a spojení. SIGKILL
(-9) použít až jako poslední možnost, když proces na SIGTERM
nereaguje — nedává mu šanci uklidit stav, což může u databází vést k
poškození dat.

Systémové prostředky

Kromě procesů je důležité sledovat celkové zatížení systému:

• free -h — využití operační paměti a swapu (v lidsky čitelném formátu).
• df -h — obsazenost připojených disků/oddílů.
• uptime — jak dlouho systém běží a průměrné zatížení (load average)
  za poslední 1, 5 a 15 minut.
• du -sh <adresář> — velikost obsahu adresáře.

Load average je průměrný počet procesů čekajících na CPU nebo I/O.
Hodnota kolem počtu jader procesoru značí plné, ale zvládnuté vytížení;
hodnota výrazně vyšší signalizuje přetížení serveru.

Init systém a systemd

Po startu jádra je potřeba spustit všechny systémové služby (SSH démon,
webserver, databázi...) ve správném pořadí a se správnými závislostmi. O
to se stará init systém — proces s PID 1. Naprostá většina moderních
distribucí (Ubuntu, Debian, RHEL/CentOS, Fedora) dnes používá systemd.

Systemd pracuje s jednotkami (units), nejčastěji typu service.
Základní příkazy nástroje systemctl:

sudo systemctl status nginx     # aktuální stav služby nginx
sudo systemctl start nginx      # spustí službu
sudo systemctl stop nginx       # zastaví službu
sudo systemctl restart nginx    # restartuje (stop + start)
sudo systemctl reload nginx     # znovu načte konfiguraci bez přerušení běhu
sudo systemctl enable nginx     # zajistí automatické spuštění při startu systému
sudo systemctl disable nginx    # zruší automatické spuštění při startu

Logy služby spravované systemd se prohlížejí přes journalctl:

journalctl -u nginx              # všechny zaznamenané logy služby nginx
journalctl -u nginx -f           # sledování logů v reálném čase (jako "tail -f")
journalctl -u nginx --since today

Praktický příklad

Scénář: webová aplikace na serveru přestala reagovat a chceme zjistit,
který proces problém způsobuje, a poté restartovat správně nakonfigurovanou
systemd službu.

# Najdeme procesy Pythonu podle jména příkazu
$ ps aux | grep python
petr      3344  87.2  4.1 412300 168200 ?    R    10:02  12:41 python3 app.py
petr      3401   0.0  0.0  6172   736 pts/0  S+   10:15   0:00 grep python

# Vidíme proces se 87 % CPU — podíváme se živě v top
$ top
# (interaktivní výpis, proces 3344 nahoře podle %CPU)

# Zkusíme nejprve slušné ukončení
$ kill 3344

# Za pár sekund ověříme, jestli proces skutečně skončil
$ ps -p 3344
  PID TTY          TIME CMD
(žádný výstup = proces už neběží)

# Pokud by proces na SIGTERM nereagoval, jako poslední možnost:
# kill -9 3344

# Aplikace je nakonfigurovaná jako systemd služba – spustíme ji tak,
# aby při pádu i restartu serveru naskočila sama
$ sudo systemctl enable --now appka.service
$ sudo systemctl status appka.service
● appka.service - Moje webová aplikace
     Loaded: loaded (/etc/systemd/system/appka.service; enabled)
     Active: active (running) since ...

# Sledujeme logy služby v reálném čase
$ journalctl -u appka.service -f

Shrnutí

Každý běžící program je v Linuxu proces s unikátním PID a stavem, který lze
sledovat pomocí ps (snímek) nebo top (živě). Procesy se ukončují
posíláním signálů příkazem kill — nejprve zdvořilým SIGTERM, teprve
při problémech násilným SIGKILL. Celkové zatížení systému se sleduje přes
free, df a uptime. Moderní distribuce spravují dlouhotrvající služby
pomocí systemd a příkazu systemctl (start/stop/restart/enable), jehož
logy se prohlížejí přes journalctl.

Kontrolní otázky

1. Jaký je rozdíl mezi signály SIGTERM a SIGKILL a proč je vhodné
   zkoušet je v tomto pořadí?
2. Jaký příkaz použijete pro zajištění, aby se služba nginx sama
   spustila po každém restartu serveru?
3. Co znamená hodnota load average a co vám řekne o zatížení serveru?
4. Jakým příkazem zobrazíte logy systemd služby appka.service v reálném
   čase?