Где можно посмотреть логи System D Unit?

Просмотр логов служб Systemd (Unit)

Логи Systemd Unit-ов, то есть системных служб, задач и сокетов, управляемых системным инициализатором systemd, централизованно собираются и управляются с помощью journald — компонента systemd для ведения журналов. Основной инструмент для их просмотра — утилита journalctl. Вот основные способы и места, где можно найти эти логи.

Основной метод: Использование journalctl

Журнал (journal) по умолчанию хранится в двоичном виде, обычно в /run/log/journal/ (для текущей сессии) и /var/log/journal/ (для постоянного хранения, если оно включено). Прямой просмотр этих файлов не рекомендуется; используйте journalctl для фильтрации и анализа.

1. Просмотр всех логов конкретного юнита

Самый частый запрос. Используйте флаг -u (или --unit).

journalctl -u nginx.service

Это покажет все записи, связанные со службой nginx.service.

2. Просмотр логов в реальном времени (follow)

Аналог tail -f для журнала systemd.

journalctl -u sshd.service -f

3. Просмотр логов за определенное время

journalctl -u docker.service --since "2024-01-15 09:00:00" --until "1 hour ago"

Можно использовать относительные значения: --since "yesterday", --since "-30min".

4. Просмотр последних записей и управление выводом

# Показать последние 50 записей
journalctl -u postgresql.service -n 50
# Показать с подробными метаданными (verbose)
journalctl -u ssh.service -o verbose
# Вывести в формате JSON для последующего парсинга
journalctl -u cron.service -o json
# Показать только сообщения определенного уровня серьезности (priority)
journalctl -u apache2.service -p err

Уровни: emerg (0), alert (1), crit (2), err (3), warning (4), notice (5), info (6), debug (7).

Дополнительные методы и расположения логов

Системный журнал (syslog) и традиционные файлы /var/log/

Если настроена интеграция с rsyslog или syslog-ng, сообщения из journald могут дублироваться в традиционные текстовые файлы. Конфигурация rsyslog (часто /etc/rsyslog.conf или файлы в /etc/rsyslog.d/) определяет, куда пишутся логи. Например, логи авторизации часто попадают в:

/var/log/auth.log    # На Debian/Ubuntu
/var/log/secure      # На RHEL/CentOS

Но это зависит от правил фильтрации в конфигурации syslog.

Просмотр логов через systemctl status

Команда systemctl status показывает краткую сводку состояния юнита и последние несколько строк его журнала.

systemctl status nginx.service

Это быстрый способ увидеть, запущена ли служба и ее последние сообщения об ошибках.

Просмотр логов для пользовательских сессий и transient-юнитов

# Показать логи текущего пользовательского сеанса
journalctl --user-unit my-app.service
# Показать все логи, включая временные (transient) юниты
journalctl _SYSTEMD_UNIT=some-scope.service

Ключевые параметры journalctl для работы с юнитами

• -b / --boot — Показать логи только с текущей или определенной загрузки (-b -1 для предыдущей).
• -k / --dmesg — Показать только сообщения ядра (аналогично dmesg).
• --utc — Выводить время в UTC.
• --no-pager — Вывести весь вывод сразу, без использования постраничного просмотра (пейджера).
• --disk-usage — Показать объем, занимаемый журналом на диске.
• --vacuum-size= — Очистить журнал, уменьшив его до указанного размера (например, --vacuum-size=500M).

Пример рабочего процесса для диагностики

Допустим, служба myapp.service не запускается.

1. Смотрим последние ошибки:

   journalctl -u myapp.service -n 20 -p err
   

2. Смотрим полный вывод с момента последней перезагрузки в реальном времени, если служба перезапускается:

   journalctl -u myapp.service -b -f
   

3. Если логи пустые, проверяем, активен ли сам юнит и нет ли проблем с конфигурацией:

   systemctl status myapp.service
   systemctl cat myapp.service  # Показать файлы юнита
   

Важно: Для доступа к полному системному журналу обычно требуются права суперпользователя (sudo). Логи пользовательских сеансов (--user) могут быть доступны без sudo, но в ограниченном объеме.

Таким образом, journalctl с флагом -u является основным и наиболее мощным инструментом для просмотра логов Systemd Unit. Традиционные файлы в /var/log/ могут служить дополнительным источником, если настроено перенаправление через syslog. Для оперативной проверки статуса удобно использовать systemctl status <unit>.