Naplók olvasása a journalctl segítségével

Modul 6: Szolgáltatások és naplók · Olvasási idő: 11 perc

Tanulási cél: A lecke után Ön a journalctl segítségével célzottan tud keresni a szervere naplóiban (szolgáltatás, prioritás és idő szerint), tudja, hol találhatók a többi naplófájl, és meg tudja akadályozni, hogy a naplók megtöltsék a lemezt.

Kulcsfogalmak: journald, journal, journalctl -u, -p, --since/--until, -f, -b, -e, -n, prioritás (err, warning, info), tartós tárolás, /var/log/journal, --disk-usage, --vacuum-size, /var/log, logrotate, rsyslog

A napló mint első tanú

Ha valami nem működik a szerveren, az ok szinte mindig ott van egy naplóban. Egy webhely, amely hibaoldalt ad, egy szolgáltatás, amely nem indul el, egy biztonsági mentés, amely éjjel nem futott le: a szerver mindezt feljegyezte. Egy jó rendszergazda először a naplóba néz, és csak utána kezd el változtatni.

A modern Linux-szervereken a journald (a systemd része) gyűjti össze a kernel, maga a systemd és az összes szolgáltatás üzeneteit egyetlen naplóba: ez a journal. Olvasni a journalctl paranccsal lehet.

Ahhoz, hogy mindent láthasson, a adm vagy a systemd-journal csoport tagjának kell lennie, vagy a sudo parancsot kell használnia. Ezek nélkül a jogosultságok nélkül csak a saját üzeneteit látja.

Hol található? Tartós vagy ideiglenes

A journald két hely egyikén tárolja a journalt:

• a /var/log/journal/ könyvtárban: tartós, a naplók újraindítás után is megmaradnak;
• a /run/log/journal/ könyvtárban: ideiglenes, a memóriában, újraindítás után elvesznek.

Az alapértelmezett beállítás (Storage=auto a /etc/systemd/journald.conf fájlban) a tartós tárolást választja, ha a /var/log/journal/ könyvtár létezik. Debianon a systemd-csomag a Debian 11 óta létrehozza ezt a könyvtárat, és Ubuntun is megvan. Ellenőrizze:

anna@web1:~$ ls -d /var/log/journal
/var/log/journal
anna@web1:~$ journalctl --list-boots | tail -n 3
 -2 3c1f... Sun 2026-11-01 04:30:12 CET Sun 2026-11-08 04:30:01 CET
 -1 9ab7... Sun 2026-11-08 04:30:40 CET Mon 2026-11-09 08:12:05 CET
  0 e41d... Mon 2026-11-09 08:12:30 CET Mon 2026-11-09 11:40:17 CET

Ha csak egyetlen rendszerindítást lát, pedig a szerver már újraindult, akkor a naplói ideiglenesek. Hozza létre a könyvtárat (sudo mkdir -p /var/log/journal és sudo systemd-tmpfiles --create --prefix /var/log/journal), majd indítsa újra a journaldot. Ez fontos: egy összeomlás után éppen azt szeretné tudni, mi történt az újraindítás előtt.

A Debian 12 óta a Debian már nem telepíti alapértelmezetten az rsyslog programot. Ez a program korábban olyan szöveges fájlokat írt, mint a /var/log/syslog és a /var/log/auth.log. Egy új Debian-szerveren ezek tehát nem léteznek; minden a journalban van. Az Ubuntun az rsyslog továbbra is megtalálható. Ha egy útmutató azt írja, hogy "nézze meg a /var/log/auth.log fájlt", Debianon ezt így fordíthatja le: journalctl -u ssh.

Keresés: a ténylegesen használt szűrők

Szűrő nélkül a journalctl mindent megjelenít, a legrégebbitől kezdve. Ritkán van erre szükség. A legfontosabb szűrők, amelyek kombinálhatók:

A prioritások 0-tól (emerg) 7-ig (debug) terjednek: emerg, alert, crit, err, warning, notice, info, debug. A -p err az err szintet és minden súlyosabbat megjelenít. A -p warning a figyelmeztetéseket is mutatja.

Egy jellemző keresési útvonal. A webhelye ma reggel óta 502-es hibát ad:

anna@web1:~$ systemctl status php8.4-fpm
× php8.4-fpm.service - The PHP 8.4 FastCGI Process Manager
     Active: failed (Result: exit-code) since Mon 2026-11-09 07:02:11 CET; 4h ago
...
anna@web1:~$ sudo journalctl -u php8.4-fpm --since today -p warning --no-pager
nov 09 07:02:10 web1 php-fpm8.4[1830]: [09-Nov-2026 07:02:10] ERROR: [/etc/php/8.4/fpm/pool.d/www.conf:42] unknown entry 'pm.max_children '
nov 09 07:02:10 web1 php-fpm8.4[1830]: [09-Nov-2026 07:02:10] ERROR: FPM initialization failed
nov 09 07:02:11 web1 systemd[1]: php8.4-fpm.service: Main process exited, code=exited, status=78/CONFIG
nov 09 07:02:11 web1 systemd[1]: php8.4-fpm.service: Failed with result 'exit-code'.

Az ok szó szerint ott áll: egy elírás egy konfigurációs fájl 42. sorában. A 78-as állapotkód (CONFIG) megerősíti, hogy konfigurációs hibáról van szó. Semmit sem kell találgatnia.

Két tipp az olvasáshoz:

• Fentről lefelé olvasson, és keresse meg az első hibát. Egy hiba gyakran egész sor következményes üzenetet okoz. Általában az első az ok.
• Figyeljen az időpontra. Mi változott abban az időben? Egy automatikus frissítés (4.2. lecke: /var/log/unattended-upgrades/), egy saját módosítás, egy újraindítás?

Egyéb naplófájlok

Nem minden kerül a journalba. Sok program saját fájlokat is (vagy csak azokat) ír a /var/log/ könyvtárba:

A nagy szöveges fájlokat a less paranccsal olvashatja (keresés: /), a végüket a tail -n 50, élőben a tail -f paranccsal követheti, szűrni pedig a grep segítségével tud:

anna@web1:~$ sudo grep " 502 " /var/log/nginx/access.log | tail -n 5

A Docker-konténerek naplói nem a /var/log könyvtárban, hanem magánál a Dockernél találhatók: docker compose logs (9.3. lecke).

A naplók nem tölthetik meg a lemezt

A megtelt lemez az egyik leggyakoribb oka annak, hogy egy szerver "hirtelen" leáll: az adatbázisok megállnak, a frissítések meghiúsulnak, és néha be sem lehet jelentkezni. Gyakran a naplók a bűnösök.

A journal saját magát korlátozza. Alapértelmezetten legfeljebb a fájlrendszer 10%-át használja, legfeljebb 4 GB-ot (SystemMaxUse=). Így nézheti meg, mennyit foglal most, és így takaríthat:

anna@web1:~$ journalctl --disk-usage
Archived and active journals take up 512.0M in the file system.
anna@web1:~$ sudo journalctl --vacuum-time=30d     # a 30 napnál régebbiek törlése
anna@web1:~$ sudo journalctl --vacuum-size=500M    # legfeljebb 500 MB

Ha rögzített korlátot szeretne, írja egy drop-in fájlba (/etc/systemd/journald.conf.d/grootte.conf):

[Journal]
SystemMaxUse=1G

majd indítsa újra a journaldot a sudo systemctl restart systemd-journald paranccsal.

A /var/log könyvtárban lévő szöveges fájlokat a logrotate kezeli: naponta vagy hetente átnevez egy fájlt (error.log.1), a régebbi változatokat tömöríti (.gz), a legrégebbieket pedig törli. Az egyes programokra vonatkozó szabályok a /etc/logrotate.d/ könyvtárban vannak. A disztribúció csomagjai magukkal hozzák a saját szabályukat. Ha egy saját program vagy szkript saját naplófájlba ír, készítsen hozzá szabályt, különben a fájl a végtelenségig nő.

Annak felderítése, mi foglalja a helyet:

anna@web1:~$ df -h /
anna@web1:~$ sudo du -xh /var/log | sort -h | tail -n 5

Naplók és adatvédelem

A naplók IP-címeket, felhasználóneveket és néha e-mail-címeket tartalmaznak: ezek személyes adatok. Ne őrizze meg őket tovább a szükségesnél (egy kis szervernél néhány héttől néhány hónapig terjedő időszak a szokásos), ne tegye őket nyilvánosan elérhetővé (egy /logs könyvtár a webrootban ismert hiba), és ne másolja át őket csak úgy mások szolgáltatásaiba.

AlmaLinux és Rocky Linux esetén

A journalctl ugyanígy működik. Ott az rsyslog továbbra is alapértelmezetten be van kapcsolva, olyan fájlokkal, mint a /var/log/messages és a /var/log/secure (ez a auth.log megfelelője). A SELinux üzenetei a /var/log/audit/audit.log fájlban vannak; a ausearch -m avc -ts recent a legutóbbi elutasításokat mutatja.

Összefoglalás

• A journald minden üzenetet a journalba gyűjt; ezt a journalctl paranccsal olvashatja, szolgáltatás (-u), prioritás (-p), idő (--since) és rendszerindítás (-b) szerint szűrve.
• Ellenőrizze, hogy a journal tartós-e (létezik a /var/log/journal), különben egy újraindítás után elvesznek a naplói.
• A Debian 12 és az újabb változatok alapértelmezetten nem tartalmazzák az rsyslogot, így nincs /var/log/auth.log és /var/log/syslog sem; minden a journalban van.
• Keresse meg az első hibát, és nézze meg, mi változott abban az időben.
• Figyelje a méretet: a journal saját magát korlátozza (--disk-usage, --vacuum-*), a szöveges fájlokat a logrotate kezeli.

Kvíz

Feladat

Z6.2. feladat: Egy összeomló szolgáltatás elemzése. A journal-crash-1.txt példafájl egy olyan szolgáltatás systemctl status és journalctl kimenetét tartalmazza, amely újra és újra elindul, majd feladja. Válaszoljon a kérdésekre: mi a szolgáltatás neve, hányszor próbálta a systemd elindítani, milyen kilépési kóddal állt le, mi az ok az első hibaüzenet szerint, és hány órakor adta fel a systemd? A program a rögzített megoldókulccsal veti össze a válaszait. Ezután nézze meg a saját szerverén, hogy a journalctl -p err -b mutat-e hibákat, és hogy a journalja tartós-e.

További olvasnivaló

• A journalctl(1) kézikönyve: https://manpages.debian.org/trixie/systemd/journalctl.1.en.html
• A journald.conf(5) kézikönyve (Storage=, SystemMaxUse=): https://manpages.debian.org/trixie/systemd/journald.conf.5.en.html
• Debian 12, kiadási megjegyzések, 5.1.7 (az rsyslog már nem alapértelmezett): https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.en.html
• Szolgáltatások kezelése a systemctl segítségével a VPS-én
• VPS: az első bejelentkezéstől a biztonságos szerverig 8.4: Naplók olvasása a journalctl és a docker logs segítségével