Ошибка syslog службы в Linux: как исправить сбой логирования

Что означает ошибка syslog службы

Ошибка syslog службы в Linux указывает на то, что демон системного логирования (обычно rsyslog или syslog-ng) не может запуститься или аварийно завершает работу. Это критическая проблема, так как без работающего syslog система перестаёт записывать важные события в файлы логов (/var/log/syslog, /var/log/messages и др.), что затрудняет диагностику других сбоев.

Типичные симптомы:

• Команда systemctl status rsyslog показывает статус failed или inactive.
• В выводе journalctl -u rsyslog видны ошибки запуска.
• Файлы логов в /var/log/ не обновляются.
• При попытке запуска вручную (sudo systemctl start rsyslog) служба сразу останавливается.

Причины возникновения

Ошибка может быть вызвана несколькими распространёнными проблемами:

1. Повреждённая или некорректная конфигурация — синтаксическая ошибка в /etc/rsyslog.conf или файлах в /etc/rsyslog.d/ после ручного редактирования или обновления пакета.
2. Конфликт портов — другой процесс уже слушает UDP/TCP порт 514 (стандартный порт syslog), что мешает запуску демона.
3. Недостаточно дискового пространства — раздел, на котором находится /var/log, заполнен на 100%.
4. Неправильные права доступа — у службы нет прав на запись в каталог /var/log или на чтение конфигурационных файлов.
5. Проблемы с SELinux/AppArmor — политики безопасности блокируют доступ демона к нужным файлам или сокетам.
6. Устаревшая или повреждённая версия пакета — после частичного обновления пакет rsyslog может быть несовместим с текущей конфигурацией.

Способы решения

Способ 1: Проверка статуса и перезапуск службы

Начните с диагностики текущего состояния службы.

1. Проверьте статус службы:

   systemctl status rsyslog
   

   
   Обратите внимание на строку Active: и последние строки лога (если есть ошибки).
2. Просмотрите логи самой службы через journald:

   journalctl -u rsyslog --no-pager -n 50
   

   
   Это покажет последние 50 строк логов, где могут быть clues.
3. Если служба остановлена или в ошибке, попробуйте перезапустить:

   sudo systemctl restart rsyslog
   

4. Проверьте статус снова. Если служба запустилась, проверьте, идут ли логи:

   tail -f /var/log/syslog
   

   
   (или /var/log/messages на CentOS/RHEL).

Способ 2: Проверка и исправление конфигурации

Синтаксическая ошибка в конфигурационном файле — частая причина сбоя.

1. Проверьте синтаксис основного конфига без запуска службы:

   sudo rsyslogd -N1
   

   
   Если вывод содержит rsyslogd: error, значит, есть ошибка. Команда покажет номер строки и описание.
2. Проверьте конфиги в /etc/rsyslog.d/:

   sudo rsyslogd -N1 -f /etc/rsyslog.d/your-config.conf
   

   
   Замените your-config.conf на имя подозрительного файла.
3. Если нашли ошибку, отредактируйте файл (sudo nano /etc/rsyslog.conf или через vim). Частые проблемы:
   • Неправильный синтаксис директив (например, пропущен пробел после селектора).
   • Использование устаревших модулей.
   • Некорректные пути к файлам логов.
4. После исправления снова проверьте синтаксис и перезапустите службу:

   sudo rsyslogd -N1 && sudo systemctl restart rsyslog
   

Способ 3: Проверка дискового пространства и прав доступа

1. Проверьте свободное место на разделе с /var/log:

   df -h /var/log
   

   
   Если использование близко к 100%, очистите старые логи (например, сжатые файлы *.gz в /var/log/) или увеличьте раздел.
2. Проверьте права на каталог /var/log:

   ls -ld /var/log
   

   
   Владельцем должен быть root, права — drwxr-xr-x (0755). Если права другие, исправьте:

   sudo chown root:root /var/log
   sudo chmod 755 /var/log
   

3. Проверьте права на конкретные файлы логов, если они уже существуют:

   ls -l /var/log/syslog*
   

   
   Владельцем обычно root или syslog (в зависимости от дистрибутива). При необходимости:

   sudo chown syslog:adm /var/log/syslog   # для Ubuntu/Debian
   sudo chown root:root /var/log/messages  # для CentOS/RHEL
   

Способ 4: Разрешение конфликта портов

По умолчанию rsyslog слушает порт 514 (UDP и TCP). Если другой процесс уже его использует, служба не запустится.

1. Найдите процесс, слушающий порт 514:

   sudo netstat -tulpn | grep :514
   

   
   Или с ss:

   sudo ss -tulpn | grep :514
   

2. Если порт занят, определите, можно ли остановить конфликтующий процесс (например, старый экземпляр syslog или кастомный сервис). Или измените порт rsyslog:
   • Отредактируйте /etc/rsyslog.conf и закомментируйте строки, содержащие *.* @ или *.* @@ (для UDP/TCP удалённого логирования), если они не нужны.
   • Или измените порт в модуле imudp/imtcp:

     module(load="imudp" port="5140")
     module(load="imtcp" port="5140")
     

   • Перезагрузите конфиг: sudo systemctl restart rsyslog.

Способ 5: Обновление или переустановка пакета rsyslog

Если проблема появилась после обновления системы, возможно, пакет повреждён или есть баг.

1. Для Ubuntu/Debian:

   sudo apt update
   sudo apt install --reinstall rsyslog
   

2. Для CentOS/RHEL/Fedora:

   sudo yum reinstall rsyslog
   

   
   или на Fedora с dnf:

   sudo dnf reinstall rsyslog
   

3. После переустановки проверьте конфигурацию (Способ 2) и перезапустите службу.

Способ 6: Временное отключение SELinux/AppArmor (для диагностики)

Если у вас включён SELinux (CentOS/RHEL/Fedora) или AppArmor (Ubuntu/Debian), они могут блокировать rsyslog.

1. Для SELinux проверьте логи:

   sudo ausearch -m avc -ts recent
   

   
   Если есть записи, связанные с rsyslog, это probable cause.
   Временно переведите SELinux в permissive mode (не рекомендуется для продакшена):

   sudo setenforce 0
   sudo systemctl restart rsyslog
   

   
   Если служба запустилась, нужно настроить политики SELinux. Верните enforcing: sudo setenforce 1.
2. Для AppArmor проверьте статус профиля:

   sudo apparmor_status | grep rsyslog
   

   
   Если профиль в режиме enforce, попробуйте перевести в complain:

   sudo aa-complain /etc/apparmor.d/usr.sbin.rsyslogd
   sudo systemctl restart rsyslog
   

Профилактика

Чтобы избежать повторного сбоя syslog службы:

• Регулярно обновляйте систему — новые версии rsyslog содержат исправления критических уязвимостей и багов.
• Не редактируйте конфигурационные файлы без резервной копии — перед изменением создайте копию: sudo cp /etc/rsyslog.conf /etc/rsyslog.conf.bak.
• Мониторьте свободное место на диске — настройте уведомления о заполнении раздела /var выше 80%.
• Тестируйте конфигурацию перед перезапуском — всегда используйте rsyslogd -N1 после правок.
• Избегайте ручной установки пакетов из ненадёжных источников — используйте только официальные репозитории дистрибутива.