6. modulis · 6.2
Žurnālu lasīšana ar journalctl
6. modulis: Pakalpojumi un žurnāli · Lasīšanas laiks: 11 min.
Mācīšanās mērķis: Pēc šīs nodarbības Jūs ar journalctl varēsiet mērķtiecīgi meklēt sava servera žurnālos (pēc pakalpojuma, prioritātes un laika), zināsiet, kur atrodas citi žurnālfaili, un novērsīsiet situāciju, kad žurnāli aizpilda Jūsu disku.
Pamatjēdzieni: journald, journal, journalctl -u, -p, --since/--until, -f, -b, -e, -n, prioritāte (err, warning, info), pastāvīga glabāšana, /var/log/journal, --disk-usage, --vacuum-size, /var/log, logrotate, rsyslog
Žurnāls kā pirmais liecinieks
Ja kaut kas Jūsu serverī nedarbojas, iemesls gandrīz vienmēr ir ierakstīts žurnālā. Vietne, kas rāda kļūdas lapu, pakalpojums, kas nepalaižas, rezerves kopija, kas šonakt netika izveidota: serveris to visu ir pierakstījis. Labs administrators vispirms ieskatās žurnālā un tikai pēc tam sāk kaut ko mainīt.
Mūsdienu Linux serveros journald (systemd daļa) apkopo kodola, paša systemd un visu pakalpojumu ziņojumus vienā žurnālā: journal. To lasa ar journalctl.
Lai varētu izlasīt visu, Jums jābūt grupā adm vai systemd-journal, vai arī jāizmanto sudo. Bez šīm tiesībām Jūs redzat tikai savus ziņojumus.
Kur tas glabājas? Pastāvīgi vai īslaicīgi
journald glabā žurnālu vienā no divām vietām:
- mapē
/var/log/journal/: pastāvīgi, žurnāli saglabājas arī pēc restartēšanas; - mapē
/run/log/journal/: īslaicīgi, atmiņā, pēc restartēšanas tie pazūd.
Noklusējuma iestatījums (Storage=auto failā /etc/systemd/journald.conf) izvēlas pastāvīgu glabāšanu, ja mape /var/log/journal/ eksistē. Debian sistēmā systemd pakotne šo mapi izveido jau kopš Debian 11, un arī Ubuntu tā ir. Pārbaudiet to:
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 CETJa redzat tikai vienu palaišanas reizi, lai gan serveris jau ir restartēts, Jūsu žurnāli ir īslaicīgi. Izveidojiet mapi (sudo mkdir -p /var/log/journal un sudo systemd-tmpfiles --create --prefix /var/log/journal) un restartējiet journald. Tas ir svarīgi: pēc avārijas Jūs gribat zināt tieši to, kas notika pirms restartēšanas.
Kopš Debian 12 Debian pēc noklusējuma vairs neinstalē rsyslog. Šī programma agrāk rakstīja teksta failus, piemēram, /var/log/syslog un /var/log/auth.log. Jaunā Debian serverī tādu failu tātad nav; viss atrodas žurnālā. Ubuntu rsyslog joprojām ir. Pamācības, kurās teikts "skatieties /var/log/auth.log", Debian sistēmā varat pārtulkot uz journalctl -u ssh.
Meklēšana: filtri, kurus tiešām izmantosiet
Bez filtra journalctl parāda visu, sākot ar vecāko ierakstu. Reti kad tas ir tas, kas Jums vajadzīgs. Svarīgākie filtri, kurus var apvienot:
| Filtrs | Piemērs | Ko dara |
|---|---|---|
-u <unit> | journalctl -u nginx | tikai šis pakalpojums |
-p <prioriteit> | journalctl -p err | tikai kļūdas un nopietnāki ziņojumi |
--since, --until | --since "2026-11-09 03:00" --until "04:00" | laika posms; arī today, yesterday, "1 hour ago" |
-b | journalctl -b, journalctl -b -1 | kopš šīs palaišanas vai iepriekšējās |
-f | journalctl -u nginx -f | sekot līdzi reāllaikā (kā tail -f), apturēt ar Ctrl+C |
-e | journalctl -u ssh -e | pāriet uz beigām |
-n | journalctl -u ssh -n 50 | pēdējās 50 rindas |
-k | journalctl -k | tikai kodola ziņojumi |
--no-pager | bez lapošanas, ērti kopā ar grep |
Prioritātes ir no 0 (emerg) līdz 7 (debug): emerg, alert, crit, err, warning, notice, info, debug. Ar -p err Jūs saņemat err un visu, kas ir nopietnāks. -p warning parāda arī brīdinājumus.
Tipisks meklēšanas ceļš. Jūsu vietne kopš šī rīta rāda kļūdu 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'.Cēlonis ir ierakstīts burtiski: drukas kļūda konfigurācijas faila 42. rindā. Statuss 78 (CONFIG) apstiprina, ka tā ir konfigurācijas kļūda. Nekas nav jāmin.
Divi padomi lasīšanai:
- Lasiet no augšas uz leju un meklējiet pirmo kļūdu. Viena kļūda bieži izraisa veselu virkni sekojošu ziņojumu. Pirmā parasti ir cēlonis.
- Pievērsiet uzmanību laikam. Kas mainījās ap šo brīdi? Automātisks atjauninājums (nodarbība 4.2:
/var/log/unattended-upgrades/), Jūsu veiktas izmaiņas, restartēšana?
Citi žurnālfaili
Ne viss atrodas žurnālā. Daudzas programmas raksta arī (vai tikai) savus failus mapē /var/log/:
| Fails vai mape | Kas tajā ir |
|---|---|
/var/log/nginx/access.log un error.log | katrs nginx pieprasījums un katra kļūda |
/var/log/apt/history.log | ko apt instalēja un kad |
/var/log/unattended-upgrades/ | automātiskie atjauninājumi (nodarbība 4.2) |
/var/log/fail2ban.log | bloķēšanas (nodarbība 5.3) |
/var/log/mysql/ vai žurnāls | MariaDB/MySQL, atkarībā no iestatījuma |
Lielus teksta failus lasiet ar less (meklēšana ar /), beigas ar tail -n 50, reāllaikā ar tail -f un filtrējiet ar grep:
anna@web1:~$ sudo grep " 502 " /var/log/nginx/access.log | tail -n 5Docker konteineru žurnāli neatrodas mapē /var/log, bet pie paša Docker: docker compose logs (nodarbība 9.3).
Žurnāli nedrīkst aizpildīt Jūsu disku
Pilns disks ir viens no biežākajiem iemesliem, kāpēc serveris "pēkšņi" vairs nedarbojas: datubāzes apstājas, atjauninājumi neizdodas, dažreiz pat vairs nevar pieteikties. Bieži vainīgi ir žurnāli.
Žurnāls (journal) ierobežo sevi pats. Pēc noklusējuma tas izmanto ne vairāk kā 10% no failu sistēmas, ar maksimumu 4 GB (SystemMaxUse=). Cik daudz tas izmanto pašlaik un kā to iztīrīt:
anna@web1:~$ journalctl --disk-usage
Archived and active journals take up 512.0M in the file system.
anna@web1:~$ sudo journalctl --vacuum-time=30d # vecāki par 30 dienām tiek dzēsti
anna@web1:~$ sudo journalctl --vacuum-size=500M # līdz 500 MBJa vēlaties noteiktu robežu, ierakstiet to drop-in failā /etc/systemd/journald.conf.d/grootte.conf:
[Journal]
SystemMaxUse=1Gun restartējiet journald ar sudo systemctl restart systemd-journald.
Teksta failus mapē /var/log uztur logrotate: katru dienu vai nedēļu fails tiek pārdēvēts (error.log.1), vecākās versijas tiek saspiestas (.gz), un vecākās tiek izdzēstas. Noteikumi katrai programmai atrodas mapē /etc/logrotate.d/. Distribūcijas pakotnes ienes savus noteikumus. Ja Jūsu pašu programma vai skripts raksta savā žurnālfailā, izveidojiet noteikumu paši, citādi fails augs bezgalīgi.
Kā atrast, kas aizņem vietu:
anna@web1:~$ df -h /
anna@web1:~$ sudo du -xh /var/log | sort -h | tail -n 5Žurnāli un privātums
Žurnālos ir IP adreses, lietotājvārdi un dažreiz e-pasta adreses: tie ir personas dati. Neglabājiet tos ilgāk, nekā nepieciešams (mazam serverim ierasts ir no dažām nedēļām līdz dažiem mēnešiem), neatstājiet tos publiski pieejamus (mape /logs Jūsu webroot ir labi zināma kļūda) un nekopējiet tos bez apdoma uz citu pakalpojumu sniedzēju servisiem.
AlmaLinux un Rocky Linux sistēmās
journalctl darbojas tāpat. Tur rsyslog joprojām ir ieslēgts pēc noklusējuma, ar tādiem failiem kā /var/log/messages un /var/log/secure (auth.log analogs). SELinux ziņojumi atrodas /var/log/audit/audit.log; ausearch -m avc -ts recent parāda nesenos atteikumus.
Kopsavilkums
- journald apkopo visus ziņojumus žurnālā; lasiet to ar
journalctl, filtrējot pēc pakalpojuma (-u), prioritātes (-p), laika (--since) un palaišanas reizes (-b). - Pārbaudiet, vai žurnāls ir pastāvīgs (
/var/log/journaleksistē), citādi pēc restartēšanas Jūsu žurnāli pazudīs. - Debian 12 un jaunākām versijām pēc noklusējuma nav rsyslog, un tātad nav arī
/var/log/auth.logun/var/log/syslog; viss atrodas žurnālā. - Meklējiet pirmo kļūdu un skatieties, kas mainījās ap šo brīdi.
- Sekojiet apjomam: žurnāls ierobežo sevi pats (
--disk-usage,--vacuum-*), teksta failus pārvalda logrotate.
Tests (quiz)
Uzdevums
Uzdevums Z6.2: Avarējoša pakalpojuma analīze. Piemēra failā journal-crash-1.txt ir systemctl status un journalctl izvade no pakalpojuma, kas atkārtoti palaižas un tad padodas. Atbildiet: kā sauc pakalpojumu, cik reizes systemd mēģināja to palaist, ar kādu izejas kodu tas apstājās, kāds ir cēlonis saskaņā ar pirmo kļūdas ziņojumu, un cikos systemd padevās? Programma salīdzina Jūsu atbildes ar fiksētu atslēgu. Pēc tam pārbaudiet savā serverī, vai journalctl -p err -b rāda kļūdas un vai Jūsu žurnāls ir pastāvīgs.
Vairāk lasīt
- Rokasgrāmata
journalctl(1): https://manpages.debian.org/trixie/systemd/journalctl.1.en.html - Rokasgrāmata
journald.conf(5)(Storage=, SystemMaxUse=): https://manpages.debian.org/trixie/systemd/journald.conf.5.en.html - Debian 12 laidiena piezīmes, 5.1.7 (rsyslog vairs nav pēc noklusējuma): https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.en.html
- Pakalpojumu pārvaldība ar systemctl Jūsu VPS
- VPS: no pirmās pieteikšanās līdz drošam serverim 8.4: Žurnālu lasīšana ar journalctl un docker logs
