Четене на логове с journalctl

Модул 6: Услуги и логове · Време за четене: 11 минути

Цел на урока: След този урок ще можете с journalctl да търсите целенасочено в логовете на Вашия сървър (по услуга, приоритет и време), ще знаете къде се намират другите лог файлове и ще можете да предотвратите запълването на диска с логове.

Основни понятия: journald, journal, journalctl -u, -p, --since/--until, -f, -b, -e, -n, приоритет (err, warning, info), постоянно съхранение, /var/log/journal, --disk-usage, --vacuum-size, /var/log, logrotate, rsyslog

Логът като първи свидетел

Когато нещо на Вашия сървър не работи, причината почти винаги е записана в някой лог. Сайт, който показва страница с грешка, услуга, която не стартира, резервно копие, което не се е изпълнило през нощта: сървърът го е записал. Добрият администратор първо поглежда в лога и едва след това започва да променя неща.

На съвременните Linux сървъри journald (част от systemd) събира съобщенията от ядрото, от самия systemd и от всички услуги в един общ лог: journal. Четете го с journalctl.

За да можете да четете всичко, трябва да сте в групата adm или systemd-journal, или да използвате sudo. Без тези права виждате само собствените си съобщения.

Къде се съхранява? Постоянно или временно

journald пази journal на едно от двете места:

• в /var/log/journal/: постоянно, логовете се запазват след рестарт;
• в /run/log/journal/: временно, в паметта, изчезват след рестарт.

Настройката по подразбиране (Storage=auto в /etc/systemd/journald.conf) избира постоянно съхранение, ако папката /var/log/journal/ съществува. В Debian пакетът systemd създава тази папка още от Debian 11, а в Ubuntu тя също съществува. Проверете:

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

Ако виждате само едно стартиране, въпреки че сървърът вече е бил рестартиран, Вашите логове са временни. Създайте папката (sudo mkdir -p /var/log/journal и sudo systemd-tmpfiles --create --prefix /var/log/journal) и рестартирайте journald. Това е важно: след срив искате да знаете именно какво се е случило преди рестарта.

От Debian 12 Debian вече не инсталира rsyslog по подразбиране. Тази програма някога записваше текстови файлове като /var/log/syslog и /var/log/auth.log. Затова на нов Debian сървър те не съществуват; всичко е в journal. В Ubuntu rsyslog все още е наличен. Ръководства, които казват „погледнете в /var/log/auth.log“, в Debian можете да преведете като journalctl -u ssh.

Търсене: филтрите, които наистина използвате

Без филтър journalctl показва всичко, започвайки от най-старото. Рядко това е, което искате. Най-важните филтри, които можете да комбинирате:

Приоритетите са от 0 (emerg) до 7 (debug): emerg, alert, crit, err, warning, notice, info, debug. С -p err получавате err и всичко по-сериозно. -p warning показва и предупрежденията.

Типичен път на търсене. От тази сутрин Вашият сайт връща грешка 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'.

Причината е изписана буквално: печатна грешка на ред 42 в конфигурационен файл. Статус 78 (CONFIG) потвърждава, че става дума за грешка в конфигурацията. Не е нужно да гадаете.

Два съвета при четене:

• Четете отгоре надолу и търсете първата грешка. Една грешка често предизвиква цяла поредица от последващи съобщения. Първата обикновено е причината.
• Обърнете внимание на времето. Какво се е променило около този момент? Автоматично обновяване (урок 4.2: /var/log/unattended-upgrades/), промяна, направена от Вас, рестарт?

Други лог файлове

Не всичко е в journal. Много програми записват също (или само) собствени файлове в /var/log/:

Големи текстови файлове четете с less (търсене с /), края с tail -n 50, на живо с tail -f, а филтрирате с grep:

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

Логовете на Docker контейнерите не са в /var/log, а при самия Docker: docker compose logs (урок 9.3).

Логовете не бива да запълват диска

Пълният диск е една от най-честите причини сървър „изведнъж“ да спре да работи: базите данни спират, обновяванията се провалят, понякога дори не можете да влезете. Често виновници са логовете.

Journal сам си поставя граница. По подразбиране използва най-много 10% от файловата система, с максимум 4 GB (SystemMaxUse=). Колко използва в момента и как да почистите:

anna@web1:~$ journalctl --disk-usage
Archived and active journals take up 512.0M in the file system.
anna@web1:~$ sudo journalctl --vacuum-time=30d     # изтриване на по-старите от 30 дни
anna@web1:~$ sudo journalctl --vacuum-size=500M    # до 500 MB

Ако искате фиксирана граница, задайте в drop-in /etc/systemd/journald.conf.d/grootte.conf:

[Journal]
SystemMaxUse=1G

и рестартирайте journald с sudo systemctl restart systemd-journald.

Текстовите файлове в /var/log се поддържат от logrotate: всеки ден или седмица файлът се преименува (error.log.1), по-старите версии се архивират (.gz), а най-старите се изтриват. Правилата за всяка програма са в /etc/logrotate.d/. Пакетите от дистрибуцията носят собствено правило. Ако Ваша собствена програма или скрипт пише в собствен лог файл, създайте сами правило, иначе файлът ще расте безкрайно.

Търсене на това, което заема място:

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

Логове и поверителност

Логовете съдържат IP адреси, потребителски имена и понякога имейл адреси: това са лични данни. Не ги пазете по-дълго от необходимото (от няколко седмици до няколко месеца е обичайно за малък сървър), не ги оставяйте публично достъпни (папка /logs в webroot е известна грешка) и не ги копирайте просто така в услуги на трети страни.

В AlmaLinux и Rocky Linux

journalctl работи по същия начин. Там rsyslog все още е включен по подразбиране, с файлове като /var/log/messages и /var/log/secure (аналогът на auth.log). Съобщенията на SELinux са в /var/log/audit/audit.log; ausearch -m avc -ts recent показва последните откази.

Обобщение

• journald събира всички съобщения в journal; четете го с journalctl, филтриран по услуга (-u), приоритет (-p), време (--since) и стартиране (-b).
• Проверете дали journal е постоянен (/var/log/journal съществува), иначе губите логовете си след рестарт.
• Debian 12 и по-новите версии нямат rsyslog по подразбиране, следователно нямат /var/log/auth.log и /var/log/syslog; всичко е в journal.
• Търсете първата грешка и вижте какво се е променило около този момент.
• Следете размера: journal сам си поставя граница (--disk-usage, --vacuum-*), а текстовите файлове се управляват от logrotate.

Тест (quiz)

Задача

Задача Z6.2: Анализ на услуга, която се срива. В примерния файл journal-crash-1.txt е изходът от systemctl status и journalctl на услуга, която многократно се рестартира и после се отказва. Отговорете: как се казва услугата, колко пъти systemd се е опитал да я стартира, с какъв код на изход е спряла, каква е причината според първото съобщение за грешка и в колко часа systemd се е отказал? Програмата сравнява отговорите с фиксиран ключ. След това проверете на собствения си сървър дали journalctl -p err -b показва грешки и дали Вашият journal е постоянен.

Още за четене

• Ръководство journalctl(1): https://manpages.debian.org/trixie/systemd/journalctl.1.en.html
• Ръководство journald.conf(5) (Storage=, SystemMaxUse=): https://manpages.debian.org/trixie/systemd/journald.conf.5.en.html
• Debian 12, бележки към изданието 5.1.7 (rsyslog вече не е по подразбиране): https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.en.html