Linuxové příkazy pro správce serverů: top 40

Správa serveru jsou většinou čtyři otázky položené stále dokola: co běží, co to dělá se strojem, co to zapsalo do logu a kdo se k tomu dostane. Na tyhle otázky odpoví zhruba čtyřicet příkazů, a jakmile je máš v prstech, vydržíš měsíce bez čtyřicátého prvního. Tenhle článek jsou právě ty příkazy, s přepínači, které z nich dělají použitelný nástroj, a s pastmi, které vyjdou draho. Počítá s Debianem nebo Ubuntu, protože na tom běží většina VDS obrazů, ale všechno tady kromě apt funguje stejně na jakékoli moderní distribuci.

Než začneš, vyplatí se dva návyky. Za prvé, man ls a ls --help jsou rychlejší než vyhledávač a popisují verzi, kterou opravdu máš, což nemusí být verze z návodu, na který jsi narazil. Za druhé, stiskni Ctrl-r a začni psát - prohledáš tak historii shellu pozpátku. Většinu toho, co dnes potřebuješ spustit, jsi spouštěl minulý týden.

Denní desítka#

Tyhle příkazy píšeš bez přemýšlení. Nauč se přepínače v pravém sloupci a máš pokrytou většinu pracovního dne.

Vedle nich stojí pár drobností. stat file vypíše oprávnění, vlastníka, velikost a všechny tři časové značky, což rozsoudí spory o tom, jestli byla konfigurace opravdu upravena. file something ti řekne, čím soubor doopravdy je, a ne za co ho vydává přípona - takhle zjistíš, že „zip“, který někdo nahrál, je ve skutečnosti archiv RAR. nproc vypíše počet CPU, které si stroj myslí, že má, a to číslo budeš potřebovat k výkladu load average dál v tomto článku.

Čtení souborů a logů#

Většina práce je čtení. Fígl je nečíst všechno.

$ tail -n 200 /var/log/nginx/error.log      # last 200 lines$ tail -F /var/log/nginx/error.log          # follow, survives rotation$ head -n 40 /etc/nginx/nginx.conf          # first 40 lines$ less +G /var/log/syslog                   # open at the end$ wc -l /var/log/auth.log                   # how many lines is this

tail -f sleduje soubor přes otevřený deskriptor. Když rotace logů soubor pod rukama přejmenuje, -f dál hlídá soubor, do kterého už nikdo nepíše, a ty tam sedíš v domnění, že server zmlkl. tail -F soubor otevře znovu podle jména a rotaci přežije. Používej velké písmeno.

U všeho, co spravuje systemd, tedy na moderním stroji u skoro všeho, log vůbec není soubor:

$ journalctl -u nginx -f                    # follow one unit$ journalctl -u minecraft --since "30 min ago"$ journalctl -b -p err                      # errors since this boot$ journalctl -k                             # kernel messages only$ journalctl --disk-usage$ journalctl --vacuum-size=200M             # when the journal has grown

-u vybere unit, -b omezí výpis na aktuální boot, -p err filtruje podle priority a --since bere běžnou angličtinu jako "yesterday" nebo "2026-09-20 18:00". Kombinace, která vyřeší většinu incidentů, je journalctl -u <name> -b --no-pager | less a pak hledání uvnitř less. Pokud je služba herní server, zajímavých je obvykle posledních třicet řádků před zastavením, ne stack trace úplně na konci. Které z těchhle logů stojí za to posílat někam natrvalo, rozebírá článek Logy, které má smysl uchovávat.

Komprimované archivy jde prohledávat bez rozbalení. zcat, zless a zgrep se na souborech .gz chovají jako jejich obyčejné verze, takže zgrep "Invalid user" /var/log/auth.log.*.gz projde dva týdny rotovaných logů najednou.

Hledání: find, grep a which#

grep hledá uvnitř souborů. find hledá soubory. Lidé sahají po tom špatném pořád.

$ grep -rn "listen" /etc/nginx/            # recursive, with line numbers$ grep -i "error" app.log | tail -n 50     # case-insensitive$ grep -c "404" access.log                 # count instead of printing$ grep -v "healthcheck" access.log         # everything except$ grep -B2 -A5 "Exception" app.log         # with context around each hit

-rn je dvojice, kterou si zapamatuj: rekurzivně a s čísly řádků, takže dostaneš file:line: text a můžeš soubor otevřít rovnou na správném místě. -B a -A vypíšou řádky před shodou a po ní, což je rozdíl mezi tím, že víš o výjimce, a tím, že víš, jaký požadavek ji způsobil.

$ find /home -type f -name "*.db" -size +50M$ find /var/log -type f -name "*.gz" -mtime +14 -delete$ find . -type d -name node_modules -prune -o -type f -name "*.js" -print$ which python3          # which binary will run$ command -v node        # the portable version of the same question

find se čte jako věta: kde hledat, jaký typ, jaké jméno a co s tím udělat. -mtime +14 znamená upraveno před více než čtrnácti dny. -delete je nevratné, takže příkaz nejdřív spusť bez něj a přečti si seznam. To není okázalá opatrnost; find s trochu špatným vzorem v -name zasáhne víc, než jsi čekal, zhruba jednou ročně.

which odpovídá na otázku „co se doopravdy spustí, když tohle napíšu“, což je důležité, když sis nainstaloval druhý Node nebo Python a ten starý je pořád v PATH první. Když tě odpověď překvapí, vypiš si echo $PATH.

Je stroj vytížený: procesy, paměť a CPU#

Čtyři příkazy ti řeknou, jestli je stroj v potížích a jakých.

$ uptime 14:22:01 up 12 days,  3:41,  1 user,  load average: 1.82, 1.44, 0.98$ free -h$ ps aux --sort=-%mem | head -n 12$ top          # or htop, if you installed it

Load average jsou tři čísla: poslední minuta, pět minut a patnáct minut. Porovnej je s nproc. Na stroji se dvěma vCPU znamená zátěž 2.00 plné vytížení, 4.00 znamená, že se práce řadí do fronty, a 0.8 je v pořádku. Směr je stejně důležitý jako hodnota: 0.5 1.4 2.1 je stroj, který se zotavuje, a 2.1 1.4 0.5 je stroj, kterého čeká zlé odpoledne. Load počítá i procesy čekající na disk, nejen na CPU, takže vysoká zátěž při nečinných procesorech obvykle znamená problém s úložištěm, ne s výpočetním výkonem.

free -h vypisuje řádek, který většinou ignoruj, a sloupec, který ignorovat nesmíš. Sloupec free je skoro vždy malý, protože Linux používá volnou paměť jako diskovou cache a na požádání ji vrací. Číslo, které říká, jestli paměť máš, je available. Pokud je available pod pár stovkami megabajtů, jsi jedno špatné přidělení paměti od toho, aby jádro něco zabilo, což je samostatné téma v článku swap a OOM killer.

ps aux --sort=-%mem | head je nejrychlejší odpověď na „co žere RAM“. Vyměň %mem za %cpu a ptáš se na to druhé. top je živá verze; htop je totéž s barvami, posouváním a stromovým zobrazením a těch třicet vteřin na instalaci stojí. Uvnitř top stiskni M pro řazení podle paměti, P podle CPU a 1 pro rozbalení zobrazení po jádrech.

Když je potřeba něco zastavit:

$ kill 4821             # polite: SIGTERM, lets it clean up and save$ kill -9 4821          # SIGKILL: immediate, no save, last resort$ pkill -f "valheim_server"$ pgrep -af java        # find the PID and the full command line first

U herních serverů není rozdíl jen akademický. SIGTERM dává většině z nich šanci zapsat svět na disk; SIGKILL zahodí všechno od posledního autosave. K -9 sáhni, až když se slušné zastavení minutu nedaří.

Místo na disku a co ho zaplnilo#

Plný disk rozbíjí věci nepříjemným způsobem: databáze odmítá zápisy, log přestane růst a služba padá s chybou, která s tím zdánlivě nesouvisí. Než začneš ladit cokoli podivného, zkontroluj místo.

$ df -h                        # space per filesystem$ df -i                        # inodes, when df -h says there is room$ du -sh /var/* 2>/dev/null | sort -h$ du -sh * | sort -h           # then descend into the biggest one$ ncdu /var                    # interactive, if you install it$ lsof +L1                     # deleted files still held open

du -sh * | sort -h a pak cd do největšího výsledku je celá technika. Tři čtyři opakování tě dovedou k adresáři, na kterém záleží. sort -h řadí čitelné velikosti správně, takže 2G je před 900M, a ne za ním jako při abecedním řazení.

Dva druhy selhání vypadají jako kouzlo, dokud je člověk nezažije. Prvním je vyčerpání inodů: df -h ukazuje 40 % využito, zápisy přesto selhávají a df -i ukáže, že inody jsou pryč na 100 %, obvykle kvůli adresáři se sessions nebo cache, kde leží miliony drobných souborů. Druhým je smazaný soubor, který má některý proces pořád otevřený. Místo se nevrátí, dokud se deskriptor nezavře, takže du a df si protiřečí. lsof +L1 vypíše přesně tyhle soubory; restart procesu, který je drží, místo okamžitě uvolní. Skoro vždy jde o logovací soubor, který někdo smazal místo vyprázdnění. Správný způsob, jak vyprázdnit používaný log, je truncate -s 0 /path/to/file, ne rm.

Služby a systemd#

Všechno, co má přežít restart, patří systemd. Práci zvládne pět podpříkazů.

$ systemctl status nginx$ systemctl restart nginx$ systemctl enable --now fail2ban      # start it and start it at boot$ systemctl disable --now something    # stop it and stop it at boot$ systemctl daemon-reload              # after editing any unit file$ systemctl list-units --type=service --state=running$ systemctl list-timers$ systemd-analyze blame                # what made this boot slow

enable a start jsou dvě různé věci a jejich záměna je nejčastější chyba se systemd. start spustí službu teď. enable zařídí, že poběží při startu systému. Služba, kterou jsi spustil, ale nikdy neenabloval, zmizí při prvním restartu stroje, obvykle za několik měsíců, a nikdo ty dvě události nespojí. --now udělá obojí.

systemctl status vypíše pod stavem posledních deset řádků logu, což často stačí, aby bylo vidět, proč se start nepovedl. Když ne, zbytek ukáže journalctl -u <name> -n 100 --no-pager. Po úpravě unit souboru musíš před restart spustit daemon-reload, jinak systemd dál používá verzi, kterou načetl při bootu, a ty ladíš změnu, která se nikdy neprojevila. Psaní samotných unit souborů je delší téma, rozebrané v článku systemd služby pro tvoje aplikace.

Uživatelé, oprávnění a vlastnictví#

Chyby s oprávněními mají velký podíl na hlášce „u mě to funguje“. Oprava je skoro vždy ve vlastníkovi, ne v módu.

$ id                                   # who am I, and in what groups$ adduser deploy                       # interactive, creates the home dir$ usermod -aG sudo deploy              # note the -a; without it you replace groups$ sudo -u minecraft -i                 # become a service user for one session$ chown -R minecraft:minecraft /srv/minecraft$ chmod 700 ~/.ssh$ chmod 600 ~/.ssh/authorized_keys$ chmod +x start.sh

-a v usermod -aG znamená append, tedy přidat. Pokud ho vynecháš, všechny skupiny uživatele se nahradí tou jednou, kterou jsi uvedl, a právě takhle si lidé odeberou vlastní přístup k sudo. Piš to pomalu.

Číselné módy mají tři číslice pro vlastníka, skupinu a všechny ostatní, kde čtení je 4, zápis 2 a spuštění 1. Takže 644 je čtení a zápis pro vlastníka a čtení pro ostatní; 755 přidává spuštění pro adresáře a skripty; 600 je jen pro vlastníka. SSH odmítne použít soukromý klíč nebo soubor authorized_keys, který může číst kdokoli jiný, a mlčky se vrátí k dotazu na heslo - a to je zdaleka nejčastější důvod, proč klíč „nefunguje“. Zbytek té historky najdeš v článku SSH klíče a zabezpečení.

Služby spouštěj pod vlastním neprivilegovaným uživatelem, jednoho na službu, se soubory, které tomu uživateli patří. Při nastavení to stojí minutu a je to rozdíl mezi jedním napadeným herním serverem a napadeným strojem. Když potřebuješ jednat jako tento uživatel, sudo -u minecraft -i ti dá přihlašovací shell pod ním, aniž by ses musel odhlašovat.

Síť: co poslouchá a kdo se k tomu dostane#

netstat je zastaralý a na minimalistických obrazech chybí. Nahradil ho ss, který je rychlejší.

$ ss -tulpen                  # every TCP and UDP listener, with the process$ ss -tn state established    # current connections$ ip -brief addr              # the machine's addresses, one line each$ ip route                    # where traffic goes by default$ ufw status numbered         # what the firewall allows

ss -tulpen je nejcennější jednotlivý příkaz v tomto článku. Spusť ho v den, kdy dokončíš nastavení serveru, a pak znovu jednou za měsíc, a výstup nech krátký. Každý řádek jsou dveře. Databáze navázaná na 0.0.0.0 místo na 127.0.0.1 je druhý nejčastější způsob, jak se malé servery dostanou do cizích rukou, a tímhle příkazem to najdeš za pět vteřin. Co dělat s dveřmi, které najdeš, patří do průvodce firewallem ufw a do článku pravidla firewallu, na kterých záleží.

Testování zvenku:

$ curl -I https://example.com                 # response headers only$ curl -sS -o /dev/null -w "%{http_code} %{time_total}s\n" https://example.com$ dig +short A example.com @1.1.1.1           # ask a specific resolver$ ping -c 4 203.0.113.10$ mtr -rwc 50 203.0.113.10                    # 50 packets, report mode$ nc -zv 203.0.113.10 25565                   # is this TCP port open

dig pouštěj proti veřejnému resolveru pomocí @1.1.1.1, když jsi právě změnil záznam, protože tvůj vlastní resolver si nejspíš drží starou odpověď, dokud nevyprší její TTL. nc -zv testuje TCP; herní UDP port smysluplně otestovat nedokáže, protože tam není nic, co by vrátilo odmítnutí. Správně číst report z mtr je samostatná dovednost a článek latence, jitter a ztráta paketů vysvětluje, který sloupec je opravdu důležitý.

Přenosy, archivy a zůstat připojený#

Dostat soubory na stroj a ze stroje a udržet věci v chodu, i když zavřeš terminál.

$ scp world.zip deploy@203.0.113.10:/srv/       # one file, quick$ rsync -avh --progress /srv/world/ backup:/srv/world/$ rsync -avh --delete src/ dest/                # make dest match src exactly$ tar -czf world-2026-09-21.tar.gz worlds_local/$ tar -xzf archive.tar.gz -C /srv/target/$ unzip plugins.zip -d plugins/

rsync je lepší než scp pro cokoli opakovaného, protože kopíruje jen to, co se změnilo, a umí navázat. Pravidlo o lomítku na konci je to, na čem se chytí každý: rsync -a src/ dest/ zkopíruje obsah src do dest, kdežto rsync -a src dest/ vytvoří dest/src. Poprvé si to vyzkoušej s --dry-run, zvlášť s --delete, které smaže všechno v cíli, co není ve zdroji.

$ tmux new -s valheim         # new named session  Ctrl-b then d               # detach, leaving it running$ tmux attach -t valheim      # come back later$ tmux ls                     # what sessions exist$ watch -n 5 'ss -tn state established | wc -l'

tmux udrží proces naživu i po přerušení SSH relace a dovolí ti připojit se ke stejnému terminálu odkudkoli. Je to správný nástroj na dlouhou kompilaci nebo migraci, kterou hlídáš. Je to špatný nástroj pro trvalý provoz herního serveru: proces v tmux se nespustí při startu systému, nerestartuje se po pádu a je neviditelný pro jakýkoli monitoring, který nastavíš později. Na všechno, co má běžet pořád, použij systemd unit a tmux si nech na práci, kterou sleduješ.

Nakonec udržování samotného systému v aktuálním stavu:

$ apt update && apt full-upgrade -y$ apt list --upgradable$ apt autoremove --purge$ needrestart                  # which services are running old libraries

apt update obnoví seznamy balíčků a nic neaktualizuje, což zaskočí lidi, kteří přicházejí z jiných správců balíčků. full-upgrade je upgrade plus právo odstranit balíček, když to aktualizace vyžaduje, což je na serveru, který chceš udržovat opatchovaný, přesně to, co chceš. Po aktualizaci knihovny běžící procesy drží starou kopii v paměti, dokud se nerestartují; needrestart ti řekne které. Celá rutina prvního dne, popořadě, je v článku první hodina na novém VDS.

Na spravovaném tarifu RE:NODE se nic z toho netýká, protože na hostiteli shell nedostaneš. Dostaneš místo toho nefiltrovanou konzoli s historií příkazů a doplňováním tabulátorem, což je vstup a výstup samotného herního nebo aplikačního procesu, a ne linuxový prompt, plus správce souborů v prohlížeči a přihlašovací údaje SFTP pro každý server. To pokryje konfiguraci, nahrávání a čtení logů bez jediného příkazu z tohoto článku. VDS je opačný obchod: plný přístup root a každý příkaz na téhle stránce se stává tvou odpovědností. Číselné srovnání, co se ti víc vyplatí, najdeš v článku VDS, nebo herní panel.

FAQ#

Jaký je rozdíl mezi apt a apt-get?

apt je novější rozhraní určené lidem u terminálu, s ukazatelem průběhu a o něco přívětivějším výstupem. apt-get má stabilní rozhraní určené pro skripty. Při interaktivním použití dělají totéž; používej apt a už nad tím nepřemýšlej.

Proč free -h říká, že mám skoro žádnou volnou paměť?

Protože Linux používá jinak nevyužitou paměť jako diskovou cache, a to je dobře. Paměť v cache se vrátí ve chvíli, kdy ji program požádá. Čti sloupec available, ne free, a znepokoj se, až když available zmenšuje.

Jak udržím program v chodu po odhlášení?

Na cokoli trvalého systemd unit s Restart=on-failure. Na jednorázový úkol, který hlídáš, tmux nebo nohup command &. Rozdíl je v tom, že systemd program po pádu restartuje a po restartu stroje spustí znovu, kdežto tmux neudělá ani jedno.

Jak zjistím, který proces používá port?

ss -tulpen vypíše všechny posluchače se jménem procesu a PID v posledním sloupci. Pokud je port obsazený, ale nic se nezobrazí, nejspíš nejsi root - spusť příkaz přes sudo, protože sloupec s procesem je u cizích procesů skrytý.

Musím se učit vim?

Ne. nano je nainstalovaný na skoro každé distribuci, zobrazuje zkratky dole na obrazovce a konfigurační soubor upraví naprosto dobře. Nauč se z vim tolik, abys z něj uměl odejít - Esc a pak :q! - protože bývá občas výchozím editorem, a zbytek si nech, až ho budeš chtít.

Co zkontrolovat jako první, když je server pomalý?

V tomto pořadí: uptime pro zátěž proti nproc, free -h pro sloupec available, df -h pro plný disk a pak ps aux --sort=-%cpu | head. Dohromady to zabere dvacet vteřin a většinou to příčinu odhalí.