Co je systemctl: praktický průvodce systemd v roce 2026

Co je systemctl: praktický průvodce systemd v roce 2026

Systémový administrátor v roce 2026 tráví 90 % svého času interakcí se serverem skrz jediný příkaz: systemctl. Spuštění webového serveru, restart databáze po nepovedeném updatu, diagnostika, proč Nginx ráno nenastartoval, nastavení vlastní služby. To vše se dělá přes jednu utilitu.

Ale systemctl je jen frontend k systemd: inicializačnímu systému a správě služeb, který stojí za vším, co běží na moderním Linuxu. Pochopení toho, jak to vevnitř funguje, odděluje inženýra, který kopíruje příkazy ze StackOverflow, od toho, kdo dokáže za pět minut zdiagnostikovat problém nebo napsat vlastní unit soubor pro svoji aplikaci.

Tento článek je praktický průvodce pro adminy a DevOps. Všechny příklady jsou ověřené na Ubuntu 24.04 LTS / Debian 12, Rocky/AlmaLinux 9 a Arch Linux. Kde se chování mezi distribucemi liší, je to zvlášť vyznačeno.

1. Co je init systém

1.1 Role init v Linuxu

Když Linux startuje, kernel udělá minimum: inicializuje ovladače, připojí root partition, spustí první proces v user-space. Tento první proces má PID 1 a jmenuje se init. Vše ostatní (síť, souborové systémy, služby, grafické prostředí) už spouští on.

Úlohy initu:

• Spustit zbytek systému ve správném pořadí (síť → databáze → webový server).
• Zůstat „rodičem" všech procesů: pokud se proces stane osiřelým, PID 1 ho zdědí.
• Sbírat „děti" (reap zombies): exit kódy procesů musí být přečtené.
• Reagovat na signály (SIGTERM od shutdownu apod.).
• Kontrolovat životní cyklus služeb: restartovat při pádu, zastavit při shutdownu.

1.2 Alternativy k systemd

Před nástupem systemd (2010) byl standardem SysVinit, minimalistický init z roku 1983. Logika: shell skripty v /etc/init.d/, které se spouštějí sekvenčně, bez paralelismu, bez závislostí. V roce 2026 už je to exotika, ale stojí za to to chápat koncepčně.

Kromě systemd a SysVinit zůstává několik živých alternativ pro ty, kdo vědomě volí minimalismus: OpenRC (standard v Gentoo, volba v Alpine a Artixu) a runit (Void Linux, ~5000 řádků kódu). V praxi 95 % serverů v roce 2026 používá systemd. Zbylých 5 % jsou buď historické distribuce (Devuan), nebo vědomá volba ve prospěch minimalismu.

1.3 Kdy není systemd nejlepší volba

Systemd je postaven kolem předpokladu, že máte plnohodnotný Linuxový server s dostatečnými hardwarovými prostředky. To není vždy oprávněné:

• Embedded a IoT. Na Raspberry Pi Zero W nebo OpenWrt routerech se počítá každý megabajt RAM. Systemd celkově „sežere" 30-80 MB rezidentní paměti. V BusyBox systémech se používá busybox init (~50 KB).
• Kontejnery. Docker init vůbec nespouští: tam jako PID 1 běží jeden deklarovaný příkaz. Pro plnohodnotný kontejner se obvykle používá tini nebo dumb-init.
• Minimální image. Pokud nasazujete stovky mikro-VM na jednom hypervizoru, Alpine Linux na musl + OpenRC dá základní image ~5 MB; systemd + glibc se nepodaří stlačit pod 60-80 MB.

2. Přehled systemd

2.1 Proč se systemd stal standardem

Systemd vyvinul Lennart Poettering v Red Hatu v roce 2010. Aktuální maintainer (od roku 2024) je Luca Boccassi z Microsoftu. Proč systemd vyhrál trh navzdory tvrdé kritice:

• Paralelní spouštění. SysV spouštěl služby sekvenčně: Apache čekal na Bind, Bind na NetworkManager. Na moderním železe to přidávalo 20-60 sekund k bootu. Systemd používá paralelní spouštění a boot proces se zkracuje 2-3×.
• Deklarativní unit soubory. Místo 200řádkového bash skriptu teď krátký INI soubor s jasnými sekcemi. Méně prostoru pro bugy.
• Jednotný ekosystém. Logy (journald), síť (networkd), časovače místo cronu, mountování: vše pod jednou střechou.
• Přijaly to majoritní distribuce. Fedora 15 (2011), Arch (2012), Debian 8 a Ubuntu 15.04 (2015), RHEL 7 (2014). Když se přesunuly korporátní distribuce, pro zbytek se vzpírání stalo zbytečným.

2.2 Unity a jejich typy

Základní jednotkou v systemd je unit: deklarativní popis toho, co má systém udělat. Typ určuje přípona souboru.

V praxi 90 % času administrátor pracuje s .service a .timer. Zbytek se buď generuje automaticky, nebo je nikový.

2.3 Targets — náhrada runlevelů

V SysV existoval pojem runlevel — režim chodu systému (3 = multi-user, 5 = graphical). V systemd je místo nich targets, které jsou flexibilnější a mají jména místo čísel.

Zkontrolovat aktuální výchozí target:

# Aktuální výchozí target
systemctl get-default
# multi-user.target

3. Unit soubory

3.1 Struktura souboru: [Unit], [Service], [Install]

Unit soubor má INI formát se třemi hlavními sekcemi. Podívejme se na zjednodušený příklad pro Nginx:

# /usr/lib/systemd/system/nginx.service
[Unit]
Description=A high performance web server and a reverse proxy server
After=network-online.target remote-fs.target nss-lookup.target
Wants=network-online.target

[Service]
Type=forking
PIDFile=/run/nginx.pid
ExecStartPre=/usr/sbin/nginx -t
ExecStart=/usr/sbin/nginx
ExecReload=/bin/kill -s HUP $MAINPID
ExecStop=/bin/kill -s QUIT $MAINPID
TimeoutStopSec=5

[Install]
WantedBy=multi-user.target

Sekce [Unit]: metadata a závislosti

• Description — lidský popis, který zobrazí systemctl status.
• After / Before: pořadí spouštění.
• Wants — měkká závislost: „zkus to spustit společně se mnou".
• Requires — tvrdá závislost: „bez toho nestartuju".

Sekce [Service]: jak spouštět

• Type: jak systemd očekává, že se služba „spustila": simple (výchozí), forking, oneshot, notify.
• ExecStart: hlavní spouštěcí příkaz, plná cesta.
• ExecReload / ExecStop: příkazy reload a zastavení.
• Restart: politika restartu: no, on-failure, always.
• User / Group: pod jakým účtem spouštět (důležité pro bezpečnost).

Sekce [Install]: jak povolit při bootu

• WantedBy: na který target se naváže při systemctl enable (obvykle multi-user.target).

3.2 Kde jsou unit soubory a jak funguje override

Na starších Debian/Ubuntu jste mohli vidět cestu /lib/systemd/system/. V moderních distribucích (Debian 12, Ubuntu 22.04+, všechny RHEL-kompatibilní, Arch) po dokončení procesu UsrMerge se /lib stal symlinkem na /usr/lib, takže fakticky unity leží na jedné kanonické cestě.

Pokud na obou místech leží nginx.service, systemd vezme ten z /etc/systemd/system/. To umožňuje override balíčkových unitů bez úprav souborů, které by se přepsaly při aktualizaci balíčku.

Override přes drop-in adresáře

Místo kopírování celého unit souboru použijte drop-in:

sudo systemctl edit nginx.service

Příkaz vytvoří /etc/systemd/system/nginx.service.d/override.conf, kam můžete přidat jen to, co je třeba přepsat:

[Service]
LimitNOFILE=65536
Environment="NGINX_WORKER_PROCESSES=auto"

Původní unit soubor zůstává netknutý, override přežije aktualizaci balíčku a hned je vidět „co přesně se změnilo".

3.3 Vytvoření vlastního unit souboru

Reálný příklad: Go aplikace /usr/local/bin/myapi, která poslouchá na portu 8080. Je potřeba ji spustit jako službu s autostartem, limity zdrojů, restartem při pádu.

Vytváříme /etc/systemd/system/myapi.service:

[Unit]
Description=My API server (Go application)
After=network-online.target postgresql.service
Wants=network-online.target
Requires=postgresql.service

[Service]
Type=simple
User=myapi
Group=myapi
WorkingDirectory=/opt/myapi
Environment="LOG_LEVEL=info"
EnvironmentFile=/etc/myapi/env
ExecStart=/usr/local/bin/myapi --config /etc/myapi/config.yaml
Restart=on-failure
RestartSec=5s
StartLimitBurst=3
StartLimitIntervalSec=60

# Bezpečnostní hardening volby
NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=strict
ProtectHome=true
ReadWritePaths=/var/log/myapi /var/lib/myapi

# Limity zdrojů přes cgroups v2
LimitNOFILE=65536
MemoryMax=512M
CPUQuota=200%

[Install]
WantedBy=multi-user.target

Rozebereme po blocích:

• Závislosti. Spouštíme po síti a PostgreSQL. Requires=postgresql.service znamená, že pokud se PostgreSQL nespustí, naše služba se taky nespustí.
• User/Group. Spouštíme NE jako root (důležité pro bezpečnost). Předem vytvoříme uživatele: sudo useradd -r -s /usr/sbin/nologin myapi.
• Restart=on-failure s limity: 3 pokusy za 60 sekund, jinak zastavení (bez nekonečné smyčky).
• Hardening. NoNewPrivileges, PrivateTmp, ProtectSystem=strict, ProtectHome minimalizují oprávnění. ReadWritePaths explicitně dovoluje zapisovat jen do uvedených adresářů.
• Limity zdrojů. Přes cgroups v2 omezujeme paměť a CPU. CPUQuota=200% = 2 plnohodnotná jádra.

Aplikování změn

sudo systemctl daemon-reload
sudo systemctl enable --now myapi.service

--now současně zapne službu (enable) a spustí ji (start).

4. systemctl — správa služeb

Všechno předchozí bylo o unit souborech, tedy deklarativním popisu služby. systemctl je nástroj, kterým tyto služby spravujete. Připadá na něj ~90 % každodenní práce admina se systemd.

4.1 Základní příkazy

4.2 Prohlížení stavu a seznamy

Pracovní kůň pro diagnostiku:

systemctl status nginx.service

Ukáže: zda je služba aktivní, od kdy, PID hlavního procesu, cgroup tree se všemi podprocesy, posledních 10 řádků logu přes journald. Je to nejužitečnější „one-shot" diagnostický report.

Užitečné seznamy:

# Všechny aktivní unity
systemctl list-units

# Pouze aktivní služby
systemctl list-units --type=service --state=active

# Služby, které spadly
systemctl --failed

# Všechny unit soubory (enable/disable stav)
systemctl list-unit-files --type=service

Rozdíl: list-units ukazuje to, co je teď načtené v paměti (skutečný stav); list-unit-files ukazuje to, co leží na disku jako soubory (deklarativní stav).

5. journalctl — práce s logy

systemd-journald je centralizovaný logger. Každá služba spuštěná přes systemd automaticky zapisuje svůj stdout/stderr do žurnálu. To znamená, že i když vaše aplikace sama žádné logy nepíše, to, co vypisuje do konzole, končí v journald.

5.1 Základní syntaxe

# Všechny logy za celou dobu
journalctl

# V opačném pořadí (čerstvé navrchu)
journalctl -r

# Posledních N řádků
journalctl -n 100

# Streamování (jako tail -f)
journalctl -f

# Jen konkrétní unit
journalctl -u nginx.service

# Více unitů najednou
journalctl -u nginx.service -u php8.4-fpm.service

5.2 Filtrování

# Podle času
journalctl --since "14:00"
journalctl --since "1 hour ago"
journalctl --since "2026-06-15 09:00" --until "2026-06-15 10:00"
journalctl --since today
journalctl --since yesterday

# Podle priority (syslog úrovně)
# Ukazuje tuto úroveň a vyšší
journalctl -p err          # err, crit, alert, emerg
journalctl -p warning      # warning a vyšší

# Pouze kernel zprávy (jako dmesg)
journalctl -k

# Vše, co se stalo v aktuálním bootu
journalctl -b

# Vše z předchozího bootu (-1 = předchozí)
journalctl -b -1

# Seznam všech bootů
journalctl --list-boots

5.3 Správa žurnálu

Na moderních distribucích (Ubuntu 18.04+, Debian 12+, RHEL 8+) jsou logy perzistentní: leží v /var/log/journal/ a přežívají reboot. Na starších mohou být volatilní (v RAM, čistí se při rebootu).

Zkontrolovat aktuální velikost logu:

journalctl --disk-usage
# Archived and active journals take up 384.0M in the file system.

Vyčistit staré logy:

sudo journalctl --vacuum-time=7d   # smazat starší než 7 dní
sudo journalctl --vacuum-size=500M # nechat max. 500 MB

6. systemd-analyze — diagnostika bootu

systemd-analyze umožňuje vidět, co přesně a jak dlouho zabíralo během spouštění. Bez něj je optimalizace bootu věštění z kávové sedliny: můžete zrychlit službu, která start ani neblokovala, a skutečného viníka nechat bez povšimnutí.

6.1 Celkový čas spuštění

systemd-analyze time

Příklad výstupu:

Startup finished in 4.231s (kernel) + 12.456s (userspace) = 16.687s
multi-user.target reached after 12.234s in userspace.

• kernel: čas od BIOSu po spuštění PID 1.
• userspace: čas od PID 1 po dosažení výchozího targetu. To je to, co můžeme optimalizovat.

6.2 blame: kdo zpomaluje boot

systemd-analyze blame

Vypíše seznam unitů seřazený podle času jejich startu:

     8.234s plymouth-quit-wait.service
     3.456s NetworkManager-wait-online.service
     2.123s docker.service
     1.892s snapd.service
      876ms postgresql@16-main.service

To není čas, kterým služba ovlivňovala boot, ale absolutní čas jejího startu. Některé služby startují paralelně a boot neblokují. Pro přesnější obraz je critical-chain.

6.3 critical-chain: skutečné brzdění

systemd-analyze critical-chain

Ukáže kritický řetězec závislostí: ten řetězec služeb, který reálně určuje, kdy boot skončí:

multi-user.target @12.234s
└─docker.service @9.876s +2.123s
  └─network-online.target @9.834s
    └─NetworkManager-wait-online.service @6.378s +3.456s
      └─NetworkManager.service @5.234s

Tady je vidět: docker čeká na network-online, který čeká na NetworkManager-wait-online (3,4 vteřiny!). Pokud chceme boot zrychlit, začínáme od NetworkManager-wait-online.

6.4 verify: kontrola unit souborů

systemd-analyze verify /etc/systemd/system/myapi.service

Rychlý linter pro unit soubory. Ukáže chyby syntaxe, chybějící závislosti, zastaralé volby. Užitečné před systemctl daemon-reload. Pokud je všechno v pořádku, příkaz nic nevypíše.

6.5 dot: vizualizace závislostí

Příkaz systemd-analyze dot generuje popis grafu závislostí ve formátu Graphviz DOT, který lze následně převést na SVG přes utilitu dot (balíček graphviz). Užitečné, když je potřeba názorně vidět, co na čem závisí:

systemd-analyze dot nginx.service | dot -Tsvg > nginx-deps.svg

Instalace graphviz: sudo apt install graphviz na Debian/Ubuntu, sudo dnf install graphviz na Rocky/Alma. Výsledek — orientovaný graf, kde jsou vidět vazby Requires, After, Wants mezi službami. Hlavně pomáhá, když zdědíte neznámou instalaci a potřebujete pochopit, jak přesně se propletly vlastní služby.

7. Další utility ekosystému systemd

systemd není jen systemctl. Do sady patří samostatné utility, které nahrazují staré jednotlivé programy. Nejužitečnější v každodenní práci:

hostnamectl

hostnamectl                                  # aktuální stav
sudo hostnamectl set-hostname web01.example.com

Nahrazuje úpravu /etc/hostname, ale dělá to správně, s aktualizací všech míst, kde se jméno ukládá.

timedatectl

timedatectl                                  # aktuální stav
sudo timedatectl set-timezone Europe/Prague
sudo timedatectl set-ntp true                # zapnout NTP synchronizaci

Řídí čas a časové pásmo systému a nastavení NTP. Jemné parametry synchronizace (NTP servery, intervaly) se nastavují v /etc/systemd/timesyncd.conf.

loginctl

loginctl                                     # seznam aktivních sezení
loginctl session-status 5                    # detaily sezení
sudo loginctl kill-user 1000                 # ukončit sezení uživatele

Zbytek utilit (localectl, networkctl, resolvectl, machinectl) je v man systemd. Pokud jsou pro váš konkrétní scénář potřeba, dozvíte se o nich z kontextu.

8. Shrnutí

Systemctl, journalctl a systemd-analyze — to je ten minimální set, který pokrývá drtivou většinu každodenních úloh systémového administrátora v roce 2026. Na těchto třech utilitách stojí vše: od spouštění a restartů služeb po diagnostiku, proč něco nefunguje, a optimalizaci boot procesu.

Co si z tohoto článku odnést do každodenní praxe:

• Drop-in adresáře místo kopírování unit souborů. systemctl edit nginx přežije aktualizaci balíčku; kopie unit souboru v /etc/systemd/system/ ne.
• Správný Type napoprvé. Když znáte rozdíl mezi simple, forking a notify, napíšete funkční unit soubor za pět minut místo tří hodin hádání, proč se služba restartuje.
• journalctl s filtry. -u, -p, --since, -f: čtyři přepínače, které pokryjí většinu diagnostických scénářů. Zvlášť v kombinaci s konkrétním unitem.
• systemd-analyze blame a critical-chain. Než si koupíte rychlejší SSD „protože server dlouho startuje", podívejte se, co ho přesně brzdí. Často je to NetworkManager-wait-online nebo něco podobného, co lze vypnout.
• Hardening ve vlastních unit souborech. NoNewPrivileges, PrivateTmp, ProtectSystem, User= bez rootu: základní hygiena, která stojí pět minut a zabrání většině scénářů kompromitace.
• Limity zdrojů přes cgroups v2. MemoryMax, CPUQuota, TasksMax v unit souboru: jediný proces nesežere veškerou RAM serveru, i kdyby měl únik paměti.

Zbytek jemností (user-level systemd, socket activation, systemd-nspawn, systemd-homed) jsou samostatná velká témata, která se stanou aktuálními, až zvládnete základ. Vracet se k nim stojí za to právě tehdy, když se objeví konkrétní úloha, ne „pro každý případ" — jinak ztratíte čas studiem toho, co v práci nikdy nevyužijete.

Časté dotazy