Tutorial journalctl: citeste, filtreaza si limiteaza logurile

E 7 dimineata. Un client iti spune ca site-ul a fost picat peste noapte, iar VPS-ul arata acum perfect normal. Ce s-a intamplat? Raspunsul e aproape sigur deja scris pe server, in jurnalul systemd. Problema e sa ajungi la el: tastezi journalctl fara argumente si te trezesti la inceputul a sute de mii de linii, adunate de cateva saptamani. In acest tutorial journalctl rezolvam exact asta. Invatam sa punem jurnalului intrebari precise (doar serviciul asta, doar ultima ora, doar erorile, doar boot-ul dinaintea caderii) si sa urmarim logurile live in timp ce testam ceva. Apoi ne asiguram ca jurnalul supravietuieste restarturilor si nu creste niciodata atat de mult incat sa umple discul.

Tot ce urmeaza functioneaza la fel pe Debian 13 si pe Ubuntu 24.04, pe un VPS KVM si in cea mai mare parte si intr-un container LXC. Exceptia o semnalam la momentul potrivit. Acolo unde cele doua distributii difera, spunem explicit.

Ce sunt, de fapt, journald si journalctl

Inainte sa scriem comenzi, avem nevoie de cateva definitii. Daca stii vocabularul, ai castigat deja jumatate din lupta.

Un log este o inregistrare cronologica a lucrurilor pe care un program vrea sa ti le spuna: “am pornit”, “ascult pe portul 443”, “nu ma pot conecta la baza de date”, “nu mai am memorie”. Orice program serios de pe un server scrie loguri. Cand ceva merge prost, ele sunt primul loc in care te uiti.

systemd este sistemul de init pe Debian si Ubuntu. E primul program pe care il porneste kernelul (are ID-ul de proces 1) si se ocupa de pornirea, oprirea si supravegherea tuturor celorlalte. systemd organizeaza totul in unitati (units). Cele mai importante pentru tine sunt serviciile: programe care ruleaza permanent, cum ar fi ssh.service (serverul SSH prin care esti conectat), cron.service (joburile programate) sau nginx.service, daca ai instalat un server web.

systemd-journald este un serviciu mic care strange mesajele de log din aproape tot sistemul:

• de la kernel,
• tot ce afiseaza serviciile la iesirea standard si la iesirea de eroare,
• de la programele care folosesc apelul clasic syslog(),
• de la systemd insusi.

Le salveaza in jurnal (journal), un set de fisiere binare, indexate. Cuvantul important e indexate. Fiecare intrare nu e doar o linie de text, ci o inregistrare cu campuri atasate:

• momentul in care a aparut,
• unitatea care a produs-o (_SYSTEMD_UNIT),
• ID-ul procesului (_PID),
• numele programului (_COMM),
• o severitate (PRIORITY),
• boot-ul din care face parte (_BOOT_ID).

De aceea o intrebare de genul “erorile nginx de ieri incoace” primeste raspuns instant. Fara index, ai rula un grep lent prin zeci de fisiere text rotite.

journalctl este utilitarul din linia de comanda care citeste jurnalul. Fiind fisiere binare, nu le deschizi niciodata cu cat sau cu un editor de text. Treci mereu prin journalctl, care le decodeaza, le filtreaza si le formateaza pentru tine. Acesta e singurul compromis al jurnalului: ai nevoie de unealta. In schimb primesti filtrare structurata, rotire automata si limite de dimensiune incorporate, pe care le configuram la final.

Debian vs Ubuntu: ce se intampla cu /var/log/syslog?

Tutorialele mai vechi te trimit sa citesti /var/log/syslog sau /var/log/auth.log. Aceste fisiere text sunt scrise de un program separat, rsyslog, care primeste o copie a fiecarui mesaj.

• Debian 13: pe o instalare noua, rsyslog de obicei nu exista. Debian a renuntat sa-l instaleze implicit incepand cu Debian 12, asa ca fisierele respective pur si simplu lipsesc, iar jurnalul este logul sistemului.
• Ubuntu 24.04: imaginile de server vin de regula tot cu rsyslog, deci ai ambele variante: fisierele text (rotite de logrotate) si jurnalul.

journalctl functioneaza identic pe ambele sisteme. Limitele journald pe care le setam mai tarziu afecteaza doar jurnalul, nu si fisierele rsyslog.

De ce ai nevoie

• Un VPS cu Debian 13 sau Ubuntu 24.04. Orice dimensiune e suficienta, pentru ca jurnalul consuma foarte putine resurse.
• Un utilizator cu drepturi sudo si o sesiune SSH deschisa catre server.
• Cam 20 de minute. Nimic din ce facem nu cere restart, desi un reboot la final este cea mai buna dovada ca persistenta functioneaza.
• Optional, un serviciu propriu pe care sa exersezi (nginx, o aplicatie Node.js, o baza de date). In exemple folosim ssh si cron, pentru ca exista pe orice server.

Pasul 1: Verifica accesul si unde se salveaza logurile

Mai intai, vedem ce versiune de systemd avem si daca putem citi toate logurile:

journalctl --version
journalctl -n 5

Prima linie de la --version arata systemd 257 pe Debian 13 si systemd 255 pe Ubuntu 24.04. Tot ce scrie in ghid merge pe ambele. -n 5 afiseaza ultimele cinci intrari. E posibil sa vezi in schimb un mesaj ca acesta:

Hint: You are currently not seeing messages from other users and the system.
      Users in groups 'adm', 'systemd-journal' can see all messages.

Inseamna ca utilizatorul tau isi vede doar propriile loguri. Ai doua variante:

• pui sudo in fata fiecarei comenzi, sau
• te adaugi in grupul systemd-journal, care exista doar ca sa ofere acces de citire la jurnal.

sudo usermod -aG systemd-journal "$USER"

Schimbarile de grup se aplica doar sesiunilor noi, asa ca delogheaza-te si conecteaza-te din nou. Dupa asta, journalctl -n 5 arata si mesajele sistemului. Pe Ubuntu, primul utilizator creat la instalare e de multe ori deja in grupul adm, care are acelasi efect.

Acum, unde sta jurnalul? journald il poate tine in doua locuri:

• in RAM: /run/log/journal, golit la fiecare reboot.
• pe disc: /var/log/journal, pastrat intre restarturi.

Verifica ce varianta ai:

ls -ld /var/log/journal /run/log/journal 2>/dev/null
journalctl --disk-usage
journalctl --list-boots | tail -n 5

--disk-usage raspunde cu o linie de genul Archived and active journals take up 56.0M in the file system., iar --list-boots afiseaza cate o linie pentru fiecare boot inregistrat. Cum interpretezi rezultatul:

• Daca exista /var/log/journal si vezi mai multe boot-uri, jurnalul tau e deja persistent.
• Daca apare doar /run/log/journal si un singur boot, logurile dispar la fiecare restart. Rezolvam asta la pasul 7.

Noteaza-ti cifra de la disk usage, pentru ca revenim la ea la pasul 8.

Pasul 2: Citeste si navigheaza prin jurnal

Ruleaza journalctl fara argumente:

journalctl

Se deschide tot jurnalul, de la cea mai veche intrare, intr-un pager. Un pager este un program (aici less) care te lasa sa derulezi o iesire lunga, in loc sa-ti treaca mii de linii prin fata ochilor. Tastele care merita stiute:

Rar vrei sa pornesti de la cea mai veche linie, asa ca optiunile astea le vei folosi tot timpul:

journalctl -e                  # deschide pagerul direct la final
journalctl -n 50               # doar ultimele 50 de intrari
journalctl -r                  # cele mai noi primele (ordine inversa)
journalctl -n 20 --no-pager    # direct in terminal, fara pager

O linie tipica arata asa:

Nov 10 08:17:01 web01 CRON[2210]: (root) CMD (cd / && run-parts --report /etc/cron.hourly)

Citind-o de la stanga la dreapta:

1. momentul, in fusul orar al serverului,
2. numele masinii,
3. identificatorul programului care a scris mesajul, cu ID-ul procesului in paranteze drepte,
4. mesajul propriu-zis.

Doua optiuni de afisare te ajuta mult:

• -o short-iso afiseaza timpul complet in format ISO, cu anul si fusul orar. E util cand lipesti loguri intr-un tichet.
• -x adauga explicatii la unele mesaje venite de la systemd.

Implicit, liniile lungi sunt taiate la marginea ecranului. Poti derula lateral cu sagetile. Alternativ, poti face pagerul sa le imparta pe mai multe randuri, scotand flagul S din optiunile less folosite de journalctl:

echo 'export SYSTEMD_LESS=FRXMK' >> ~/.bashrc
source ~/.bashrc

In fine, cand iesirea journalctl merge intr-un pipe, pagerul se dezactiveaza automat. Asa ca uneltele clasice functioneaza in continuare, de exemplu journalctl -b | grep -i error | tail.

Pasul 3: Filtreaza dupa serviciu

Acesta e filtrul pe care il vei folosi cel mai des. -u (de la unit) arata doar mesajele unui serviciu. Mai intai afla numele exact al serviciului:

systemctl list-units --type=service --state=running

Apoi cere-i logurile:

journalctl -u ssh -n 30
journalctl -u cron --since today

Sufixul .service e optional. Atentie insa la nume: unitatea serverului OpenSSH se numeste ssh atat pe Debian, cat si pe Ubuntu, nu sshd. De aceea journalctl -u sshd intoarce de obicei -- No entries --. Pe Ubuntu 24.04, SSH porneste la cerere prin ssh.socket, dar mesajele lui apartin tot de ssh.service. Asadar -u ssh e filtrul corect pe ambele sisteme.

Poti repeta -u ca sa vezi mai multe servicii intercalate in ordine cronologica, ideal cand depanezi un stack web. Poti folosi si wildcard-uri ca in shell. Pune-le intre ghilimele simple, ca shell-ul sa nu le expandeze inainte sa ajunga la journalctl:

journalctl -u nginx -u 'php*-fpm' --since "1 hour ago"

Nu stii ce unitati au scris ceva in jurnal? -F listeaza toate valorile distincte ale unui camp gasite in jurnal:

journalctl -F _SYSTEMD_UNIT

Pe langa unitati, poti filtra dupa orice camp din jurnal:

• -t potriveste identificatorul din fiecare linie. De exemplu, journalctl -t CRON arata fiecare job cron rulat.
• Campurile se pot da si direct, ca in journalctl _PID=1234 sau journalctl _COMM=nginx.

Cand combini filtre, campurile diferite se leaga cu SI, iar acelasi camp repetat se leaga cu SAU.

Pasul 4: Filtreaza dupa timp si boot

Filtrele de timp folosesc --since si --until (forme scurte -S si -U). Accepta atat valori exacte, cat si formulari “omenesti”:

journalctl --since "2026-11-09 23:00" --until "2026-11-10 01:00"
journalctl --since "30 min ago"
journalctl --since yesterday --until today
journalctl -u ssh --since today

Orele sunt interpretate in fusul orar al serverului. Daca timpii par decalati cu cateva ore fata de ceasul tau, ruleaza timedatectl ca sa vezi fusul configurat (multe imagini de VPS vin pe UTC). Apoi fie il schimbi cu sudo timedatectl set-timezone Europe/Bucharest, fie adaugi --utc la journalctl si citesti totul in UTC.

A doua modalitate de a imparti jurnalul este pe boot-uri. La fiecare pornire a serverului, journald eticheteaza intrarile noi cu un nou boot ID, iar journalctl te lasa sa sari intre ele:

journalctl --list-boots

IDX BOOT ID                          FIRST ENTRY                 LAST ENTRY
 -1 5c2f0e8d6a8b4f2c9e1a7b3d4c5e6f70 Sun 2026-11-08 09:12:03 EET Mon 2026-11-09 22:40:11 EET
  0 a1b2c3d4e5f60718293a4b5c6d7e8f90 Mon 2026-11-09 22:41:02 EET Tue 2026-11-10 08:05:17 EET

0 e boot-ul curent, -1 cel dinaintea lui si asa mai departe:

journalctl -b            # doar boot-ul curent
journalctl -b -1 -e      # boot-ul anterior, deschis la ultimele linii
journalctl -b -1 -p err  # doar erorile din boot-ul anterior

journalctl -b -1 -e este cea mai utila comanda dupa un restart neasteptat. Ultimele linii ale boot-ului anterior arata deseori exact ce s-a intamplat: un proces omorat din lipsa de memorie, un mesaj de kernel panic sau o oprire curata ceruta de cineva.

Comanda merge doar cu jurnal persistent, inca un motiv pentru pasul 7. Intr-un container LXC, un “boot” inseamna o pornire a containerului, nu a serverului fizic.

Pasul 5: Filtreaza dupa prioritate si cuvinte cheie

Fiecare intrare din jurnal are o prioritate. Aceasta este un nivel de severitate mostenit din vechiul standard syslog, de la 0 (urgenta) la 7 (debug). -p arata nivelul ales plus tot ce e mai grav decat el:

journalctl -p err -b              # erori si mai grave, boot-ul curent
journalctl -p warning --since today
journalctl -p err..warning        # doar nivelurile 3 si 4
journalctl -p 3                   # merg si cifrele (3 = err)

journalctl -p err -b e o prima comanda excelenta pe un server pe care nu-l cunosti. Reduce miile de linii ale unui boot la cele cateva care conteaza. Totusi, nu te speria de fiecare linie afisata. Unele mesaje inofensive sunt logate ca erori, asa ca uita-te dupa tipare si repetitii.

Pentru mesajele kernelului (aceleasi pe care le arata dmesg), foloseste -k, care limiteaza automat afisarea la boot-ul curent. Aici gasesti procesele omorate din lipsa de memorie si erorile de disc sau de placa de retea:

journalctl -k -p warning
journalctl -k -g "oom|killed process"

-g (sau --grep) filtreaza mesajele dupa o expresie regulata. Literele mari si mici sunt tratate asa:

• Daca tiparul e scris doar cu litere mici, cautarea ignora diferenta dintre ele.
• Daca tiparul contine macar o litera mare, cautarea devine sensibila la ele.
• Poti forta oricare comportament cu --case-sensitive=yes sau --case-sensitive=no.

-g se combina cu orice alt filtru. De exemplu, ca sa vezi logarile SSH esuate de azi:

journalctl -u ssh --since today -g "failed password|invalid user"

Pe Debian 13 (OpenSSH 10), liniile acestea sunt scrise de un proces ajutator numit sshd-session, nu de sshd. Filtrul pe unitatea ssh le prinde pe ambele.

Intr-un container LXC neprivilegiat, -k nu intoarce nimic. Kernelul apartine gazdei, asa ca mesajele lui ajung in jurnalul gazdei, nu in al tau.

Pasul 6: Urmareste logurile live

-f (follow) afiseaza ultimele linii si apoi tine terminalul deschis, aratand intrarile noi in clipa in care sunt scrise. E un fel de tail -f pentru jurnal:

journalctl -f
journalctl -u ssh -f
journalctl -u nginx -f -n 0     # doar linii noi, fara istoric
journalctl -f -p warning        # live, dar doar avertismente si mai grave

Apasa Ctrl+C ca sa opresti. Un exercitiu bun:

1. Ruleaza journalctl -u ssh -f in sesiunea curenta.
2. Dintr-un alt terminal, deschide o a doua conexiune SSH catre server.
3. Urmareste cum logarea apare in timp real in prima fereastra.

Acelasi truc il folosim zilnic cand depanam servicii. Urmaresti logurile intr-o fereastra, repornesti sau testezi serviciul in alta (sudo systemctl restart nginx) si citesti reactia pe loc, in loc sa ghicesti.

Pasul 7: Fa jurnalul persistent

Setarea Storage= controleaza unde isi tine journald logurile:

• volatile: logurile stau doar in RAM (/run/log/journal).
• persistent: logurile stau pe disc (/var/log/journal), iar directorul se creeaza daca lipseste.
• auto: valoarea implicita obisnuita pe Debian 13 si Ubuntu 24.04. Foloseste discul daca exista /var/log/journal, altfel RAM-ul.
• none: arunca tot. Nu folosi asa ceva pe un server.

Cu auto, faptul ca pastrezi logurile intre restarturi depinde de existenta unui director. Asta difera de la o imagine la alta, iar directorul poate fi sters din greseala. Noi preferam sa setam valoarea explicit.

In loc sa editam fisierul principal de configurare, cream un drop-in. Un drop-in este un fisier mic in /etc/systemd/journald.conf.d/ ale carui setari le suprascriu pe cele implicite. Upgrade-urile de pachete nu il ating, iar mai tarziu e clar ce ai schimbat. In functie de versiune, fisierul implicit cu comentarii sta in /etc/systemd/journald.conf sau sub /usr/lib/systemd/. Drop-in-urile functioneaza in ambele cazuri.

sudo mkdir -p /etc/systemd/journald.conf.d
sudo tee /etc/systemd/journald.conf.d/10-persistent.conf > /dev/null <<'EOF'
[Journal]
Storage=persistent
EOF
sudo systemctl restart systemd-journald
sudo journalctl --flush

Ce face fiecare comanda:

1. mkdir -p creeaza directorul pentru drop-in-uri.
2. tee scrie un fisier cu sectiunea [Journal]. Antetul e obligatoriu si sensibil la majuscule.
3. systemctl restart il face pe journald sa citeasca noua setare.
4. journalctl --flush muta pe disc tot ce mai statea in RAM.

Repornirea journald e sigura: serviciile merg mai departe si continua sa scrie loguri. Daca pe sistemul tau exista deja un fisier in journald.conf.d (unele imagini vin cu unul), deschide-l si adauga setarea acolo. Nu crea un al doilea fisier care sa-l contrazica.

Ca sa verifici rezultatul, ruleaza aceste doua comenzi:

systemd-analyze cat-config systemd/journald.conf
ls /var/log/journal/

Prima afiseaza configuratia efectiva, inclusiv toate drop-in-urile, in ordinea in care se aplica. A doua ar trebui sa arate un director cu numele ID-ului masinii, care contine system.journal. Dupa urmatorul reboot, journalctl --list-boots va afisa cel putin doua intrari.

Pasul 8: Limiteaza spatiul pe disc si fa curatenie

Acum partea care impiedica logurile sa-ti umple vreodata VPS-ul. Implicit, journald aplica doua limite pe sistemul de fisiere pe care sta jurnalul:

• SystemMaxUse=: jurnalul poate folosi pana la 10% din sistemul de fisiere, dar nu mai mult de 4 GB.
• SystemKeepFree=: journald incearca sa lase liber cel putin 15% din sistemul de fisiere, tot cu plafon de 4 GB.

Cand se atinge o limita, fisierele vechi se sterg automat. E sigur, dar pe un VPS mic 2-4 GB de loguri inseamna mult mai mult decat ii trebuie oricui, iar spatiul acela e mai util pentru datele tale:

Pentru un VPS mic sau mediu folosim valorile de mai jos, intr-un al doilea drop-in:

sudo tee /etc/systemd/journald.conf.d/20-limits.conf > /dev/null <<'EOF'
[Journal]
SystemMaxUse=500M
SystemKeepFree=1G
SystemMaxFileSize=50M
MaxRetentionSec=1month
RuntimeMaxUse=50M
EOF
sudo systemctl restart systemd-journald

Ce inseamna fiecare linie:

• SystemMaxUse=500M: jurnalul de pe disc nu depaseste niciodata 500 MB in total. Pe un server cu un singur rol, asta inseamna de obicei cateva saptamani de istoric. Serverele aglomerate pot merge pana la 1G sau 2G.
• SystemKeepFree=1G: orice s-ar intampla, lasa cel putin 1 GB liber pe disc. Daca spatiul se strange din cauza altor fisiere, journald sterge loguri vechi inainte ca baza ta de date sa ramana fara loc.
• SystemMaxFileSize=50M: fisierele individuale ale jurnalului se rotesc la 50 MB, asa ca logurile vechi se sterg in bucati mici, nu in salturi mari.
• MaxRetentionSec=1month: sterge intrarile mai vechi de o luna, chiar daca mai e loc. Te ajuta cand nu vrei sa pastrezi date personale (cum sunt adresele IP) mai mult decat e nevoie. Limita atinsa prima castiga.
• RuntimeMaxUse=50M: aceeasi limita pentru jurnalul din RAM, folosit la inceputul boot-ului sau daca persistenta e oprita vreodata.

Limitele se aplica pe masura ce se scriu date noi. Ca sa eliberezi spatiu chiar acum, foloseste vacuum. Vacuum sterge doar fisiere arhivate, asa ca il combinam cu --rotate, care inchide mai intai fisierele active si le transforma in arhive:

sudo journalctl --rotate --vacuum-size=500M
# sau, dupa vechime:
sudo journalctl --rotate --vacuum-time=2weeks
journalctl --disk-usage

Vei vedea linii de genul Deleted archived journal ... (48.0M)., urmate de Vacuuming done, freed .... --disk-usage ar trebui sa raporteze acum o valoare egala sau mai mica decat limita ta.

Vacuum-ul e definitiv. Daca esti in mijlocul investigarii unui incident, exporta mai intai ce ai nevoie (vezi FAQ). La final, verifica sanatatea fisierelor ramase:

sudo journalctl --verify

Fiecare fisier ar trebui sa raporteze PASS. Daca esti pe Ubuntu cu rsyslog, tine minte ca /var/log/syslog si celelalte fisiere text sunt o copie separata, gestionata de logrotate. Limitele journald nu le micsoreaza.

Fituica journalctl

Depanare si greseli frecvente

“No journal files were found” sau mesajul “not seeing messages from other users”. Utilizatorul tau nu poate citi jurnalul sistemului. Foloseste sudo sau intra in grupul systemd-journal, ca la pasul 1, si deschide o sesiune SSH noua.

“Specifying boot ID or boot offset has no effect, no persistent journal was found.” Ai cerut -b -1, dar jurnalul sta doar in RAM. Fa pasul 7. Boot-urile anterioare vor fi disponibile doar din acel moment; logurile de dinainte s-au pierdut.

-u ceva afiseaza “– No entries –”. Exista trei cauze frecvente:

• Numele unitatii e gresit. sshd in loc de ssh e greseala clasica.
• Serviciul nu a scris nimic in intervalul cerut.
• Serviciul scrie in fisierele lui proprii. De exemplu, nginx scrie implicit logurile de acces si de erori in /var/log/nginx/, iar in jurnal ajung doar mesajele de pornire.

Ruleaza journalctl -F _SYSTEMD_UNIT ca sa vezi ce nume de unitati exista de fapt.

Orele sunt decalate cu cateva ore. Fusul orar al serverului nu e cel pe care il crezi. Verifica-l cu timedatectl, apoi schimba-l sau foloseste --utc.

Spatiul ocupat nu a scazut dupa vacuum. Vacuum sare peste fisierele active, asa ca adauga --rotate. Daca discul e tot plin, s-ar putea ca vinovatul sa nu fie jurnalul. Ruleaza sudo du -xh /var --max-depth=2 | sort -h | tail -n 15 si verifica trei locuri: fisierele text din /var/log, /var/lib/docker (unde stau implicit logurile containerelor) si backup-urile.

“Suppressed N messages from some.service”. journald limiteaza serviciile prea vorbarete, ca sa protejeze discul. Implicit, limita e de 10000 de mesaje la 30 de secunde pentru fiecare serviciu. De obicei asta inseamna ca serviciul are o problema care merita rezolvata. Daca doar cresti RateLimitBurst=, problema ramane, doar ca nu o mai vezi.

Mesaje despre un fisier de jurnal corupt sau inchis necurat. Dupa un reset fortat, journald redenumeste fisierul afectat (numele lui se termina acum in .journal~) si porneste unul nou. Nu e grav. journalctl citeste in continuare ce se poate din fisierul vechi, iar rotirea normala il sterge mai tarziu. sudo journalctl --verify iti spune ce fisiere sunt afectate.

Modificarea de configurare nu are efect. Verifica trei lucruri:

1. Antetul sectiunii este exact [Journal].
2. Ai repornit systemd-journald dupa modificare.
3. Niciun alt fisier nu-l suprascrie pe al tau. Verifici cu systemd-analyze cat-config systemd/journald.conf. Drop-in-urile se aplica in ordine alfabetica, iar ultimul fisier castiga.

journalctl -k e gol. Esti intr-un container LXC. Mesajele kernelului se vad doar pe gazda.

Note de securitate

• Logurile sunt date sensibile. Contin adrese IP, nume de utilizatori, uneori URL-uri cu tokenuri sau adrese de e-mail. Apartenenta la systemd-journal sau adm inseamna “poate citi tot ce s-a intamplat pe server”. Ofera acest drept doar oamenilor in care ai incredere, iar inainte sa lipesti loguri pe forumuri publice, curata-le de date sensibile.
• Nu loga secrete. Daca iti scrii propriile servicii, nu afisa niciodata parole sau chei API. Tot ce ajunge la stdout intra in jurnal si ramane acolo pana il sterge rotirea.
• Root poate rescrie istoria. Un atacator care obtine root poate sterge sau goli jurnalul. Pentru serverele importante, trimite logurile si in afara masinii. journald le poate redirectiona catre un server central de loguri cu systemd-journal-upload, sau le poti trimite intr-un stack de loguri.
• Sigilarea face modificarile vizibile. journald suporta Forward Secure Sealing (journalctl --setup-keys plus Seal=yes). Aceasta face modificarile detectabile cu --verify, cu conditia sa tii cheia de verificare in alta parte decat pe server.
• Limitele sunt si ele o masura de securitate. Un serviciu defect sau atacat poate genera gigabytes de loguri. SystemMaxUse= si SystemKeepFree= fac ca rezultatul sa fie niste loguri vechi pierdute, nu un disc plin si o baza de date cazuta.
• Retentia e o decizie de confidentialitate. Daca gazduiesti servicii pentru utilizatori din UE, MaxRetentionSec= te ajuta sa pastrezi adresele IP doar cat timp ai un motiv real.

Deci, ce urmeaza?

Acum poti pune jurnalului intrebari precise, in loc sa derulezi la nesfarsit:

• ce serviciu (-u),
• cand (--since, -b),
• cat de grav (-p),
• ce contine (-g),
• si toate acestea live, cu -f.

Jurnalul tau supravietuieste restarturilor, deci povestea urmatoarei caderi va fi tot acolo. In plus, e plafonat, asa ca nu se mai bate cu datele tale pe spatiul de pe disc. Data viitoare cand ceva nu merge, incepe cu journalctl -p err -b si journalctl -b -1 -e. De noua ori din zece, raspunsul e chiar acolo.

Daca vrei un server pe care sa exersezi, un VPS din data center-ul nostru din Romania e gata in cateva minute, cu Debian 13 sau Ubuntu 24.04 preinstalat. Iar daca preferi ca altcineva sa urmareasca logurile, sa configureze retentia si alertele si sa intervina cand ceva se strica, echipa noastra de administrare servere face exact asta, in fiecare zi.

Intrebari frecvente

Unde sunt salvate logurile systemd pe Debian si Ubuntu?

Stau in /var/log/journal/<machine-id>/ cand jurnalul e persistent, sau in /run/log/journal/ cand e volatil. Fisierele sunt binare, asa ca le citesti cu journalctl, nu cu un editor de text. Pe Ubuntu cu rsyslog ai si copii text in /var/log/syslog si /var/log/auth.log.

E sigur sa sterg manual fisiere din /var/log/journal?

Functioneaza, dar foloseste mai bine sudo journalctl --rotate --vacuum-size=... sau --vacuum-time=.... Vacuum sterge curat cele mai vechi fisiere arhivate si nu atinge niciodata fisierul in care journald scrie in acel moment.

Cum salvez logurile intr-un fisier text ca sa le trimit cuiva?

Redirectioneaza iesirea: journalctl -u nginx --since today --no-pager > nginx-azi.txt. Chiar daca pui sudo in fata lui journalctl, fisierul e creat de shell-ul tau, deci apartine utilizatorului tau si il poti copia imediat cu scp. Adauga -o short-iso pentru ore fara ambiguitati si scoate datele sensibile inainte sa-l trimiti.

Arata journalctl si logurile containerelor Docker?

Nu, implicit. Docker pastreaza iesirea containerelor in fisierele lui JSON, iar tu o citesti cu docker logs. Daca vrei logurile containerelor in jurnal, seteaza driverul de logging pentru un serviciu in fisierul compose (logging: cu driver: journald). Apoi le citesti cu journalctl CONTAINER_NAME=web, iar docker logs merge in continuare.

Cat spatiu sa aloc jurnalului?

Pentru un VPS mic, 200M-500M sunt suficienti. Serverele aglomerate, cu multe servicii, pot avea nevoie de 1G-2G. Dupa o saptamana, verifica journalctl --disk-usage, apoi uita-te la cea mai veche intrare cu journalctl -o short-iso | head -n 1, ca sa vezi cate zile de istoric incap in limita ta.