Citirea jurnalelor cu journalctl

Modulul 6: Servicii și jurnale · Timp de citire: 11 minute

Obiectivul lecției: După această lecție veți putea căuta țintit cu journalctl în jurnalele serverului dumneavoastră (după serviciu, prioritate și timp), veți ști unde se află alte fișiere log și veți preveni umplerea discului cu jurnale.

Noțiuni cheie: journald, journal, journalctl -u, -p, --since/--until, -f, -b, -e, -n, prioritate (err, warning, info), stocare persistentă, /var/log/journal, --disk-usage, --vacuum-size, /var/log, logrotate, rsyslog

Jurnalul, primul martor

Când ceva nu funcționează pe serverul dumneavoastră, motivul se află aproape întotdeauna într-un jurnal. Un site care afișează o pagină de eroare, un serviciu care nu pornește, un backup care nu a rulat azi-noapte: serverul a notat totul. Un administrator bun se uită mai întâi în jurnal și abia apoi începe să modifice lucruri.

Pe serverele Linux moderne, journald (parte din systemd) adună mesajele kernelului, ale systemd însuși și ale tuturor serviciilor într-un singur jurnal: journal. Îl citiți cu journalctl.

Pentru a putea citi totul trebuie să faceți parte din grupul adm sau systemd-journal, ori să folosiți sudo. Fără aceste drepturi vedeți doar propriile mesaje.

Unde se află? Persistent sau volatil

journald păstrează jurnalul într-unul din două locuri:

• în /var/log/journal/: persistent, jurnalele se păstrează după o repornire;
• în /run/log/journal/: volatil, în memorie, dispar după o repornire.

Setarea implicită (Storage=auto în /etc/systemd/journald.conf) alege varianta persistentă dacă directorul /var/log/journal/ există. Pe Debian, pachetul systemd creează acest director încă din Debian 11, iar pe Ubuntu există și el. Verificați:

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

Dacă vedeți un singur moment de pornire deși serverul a fost deja repornit, jurnalele dumneavoastră sunt volatile. Creați directorul (sudo mkdir -p /var/log/journal și sudo systemd-tmpfiles --create --prefix /var/log/journal) și reporniți journald. Acest lucru este important: după o cădere vreți tocmai să aflați ce s-a întâmplat înainte de repornire.

Începând cu Debian 12, Debian nu mai instalează implicit rsyslog. Acest program scria odinioară fișiere text precum /var/log/syslog și /var/log/auth.log. Pe un server Debian nou acestea nu există deci; totul se află în journal. Ubuntu are încă rsyslog. Ghidurile care spun „uitați-vă în /var/log/auth.log” le puteți traduce pe Debian în journalctl -u ssh.

Căutarea: filtrele pe care le folosiți cu adevărat

Fără filtru, journalctl afișează totul, începând cu cele mai vechi intrări. Rareori este ceea ce doriți. Cele mai importante filtre, pe care le puteți combina:

Prioritățile merg de la 0 (emerg) la 7 (debug): emerg, alert, crit, err, warning, notice, info, debug. Cu -p err obțineți err și tot ce este mai grav. -p warning afișează și avertismentele.

Un traseu de căutare tipic. Site-ul dumneavoastră afișează din această dimineață o eroare 502:

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'.

Cauza este scrisă literal: o greșeală de tastare pe rândul 42 al unui fișier de configurare. Statusul 78 (CONFIG) confirmă că este vorba de o eroare de configurare. Nu trebuie să ghiciți nimic.

Două sfaturi pentru citire:

• Citiți de sus în jos și căutați prima eroare. O eroare provoacă adesea un întreg șir de mesaje ulterioare. Prima este de obicei cauza.
• Fiți atenți la oră. Ce s-a schimbat în jurul acelui moment? O actualizare automată (lecția 4.2: /var/log/unattended-upgrades/), o modificare făcută de dumneavoastră, o repornire?

Alte fișiere log

Nu totul se află în journal. Multe programe scriu și (sau doar) fișiere proprii în /var/log/:

Fișierele text mari le citiți cu less (căutare cu /), sfârșitul cu tail -n 50, în timp real cu tail -f și le filtrați cu grep:

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

Jurnalele containerelor Docker nu se află în /var/log, ci la Docker însuși: docker compose logs (lecția 9.3).

Jurnalele nu trebuie să vă umple discul

Un disc plin este una dintre cele mai frecvente cauze pentru care un server „brusc” nu mai funcționează: bazele de date se opresc, actualizările eșuează, uneori nici nu vă mai puteți autentifica. Jurnalele sunt adesea vinovatele.

Journal se limitează singur. Implicit folosește cel mult 10% din sistemul de fișiere, cu un maxim de 4 GB (SystemMaxUse=). Cât folosește acum și cum faceți curățenie:

anna@web1:~$ journalctl --disk-usage
Archived and active journals take up 512.0M in the file system.
anna@web1:~$ sudo journalctl --vacuum-time=30d     # mai vechi de 30 de zile sunt șterse
anna@web1:~$ sudo journalctl --vacuum-size=500M    # până la 500 MB

Dacă doriți o limită fixă, puneți într-un drop-in /etc/systemd/journald.conf.d/grootte.conf:

[Journal]
SystemMaxUse=1G

și reporniți journald cu sudo systemctl restart systemd-journald.

Fișierele text din /var/log sunt gestionate de logrotate: în fiecare zi sau săptămână un fișier este redenumit (error.log.1), versiunile mai vechi sunt arhivate (.gz), iar cele mai vechi sunt șterse. Regulile pentru fiecare program se află în /etc/logrotate.d/. Pachetele din distribuție își aduc propria regulă. Dacă un program sau script propriu scrie într-un fișier log propriu, creați singuri o regulă, altfel fișierul crește la nesfârșit.

Căutarea a ceea ce ocupă spațiu:

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

Jurnalele și confidențialitatea

Jurnalele conțin adrese IP, nume de utilizator și uneori adrese de e-mail: acestea sunt date cu caracter personal. Nu le păstrați mai mult decât este necesar (de la câteva săptămâni la câteva luni este uzual pentru un server mic), nu le lăsați accesibile public (un director /logs în webroot este o greșeală cunoscută) și nu le copiați pur și simplu în serviciile altora.

Pe AlmaLinux și Rocky Linux

journalctl funcționează la fel. Acolo rsyslog este încă activ implicit, cu fișiere precum /var/log/messages și /var/log/secure (echivalentul lui auth.log). Mesajele SELinux se află în /var/log/audit/audit.log; ausearch -m avc -ts recent afișează refuzurile recente.

Rezumat

• journald adună toate mesajele în journal; le citiți cu journalctl, filtrate după serviciu (-u), prioritate (-p), timp (--since) și pornire (-b).
• Verificați că journal este persistent (/var/log/journal există), altfel vă pierdeți jurnalele după o repornire.
• Debian 12 și versiunile ulterioare nu au implicit rsyslog, deci nici /var/log/auth.log și /var/log/syslog; totul se află în journal.
• Căutați prima eroare și uitați-vă la ce s-a schimbat în jurul acelui moment.
• Urmăriți dimensiunea: journal se limitează singur (--disk-usage, --vacuum-*), iar fișierele text sunt gestionate de logrotate.

Test (quiz)

Exercițiu

Exercițiul Z6.2: Analiza unui serviciu care se blochează. În fișierul de exemplu journal-crash-1.txt se află ieșirea comenzilor systemctl status și journalctl pentru un serviciu care repornește în mod repetat și apoi renunță. Răspundeți: cum se numește serviciul, de câte ori a încercat systemd să îl pornească, cu ce cod de ieșire s-a oprit, care este cauza conform primului mesaj de eroare și la ce oră a renunțat systemd? Programul compară răspunsurile cu cheia fixă. Apoi verificați pe propriul server dacă journalctl -p err -b afișează erori și dacă journal este persistent.

Lecturi suplimentare

• Manualul journalctl(1): https://manpages.debian.org/trixie/systemd/journalctl.1.en.html
• Manualul journald.conf(5) (Storage=, SystemMaxUse=): https://manpages.debian.org/trixie/systemd/journald.conf.5.en.html
• Debian 12, note de lansare 5.1.7 (rsyslog nu mai este implicit): https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.en.html