Исправляем ошибку 'rsyslog service failed' в Linux

Что означает ошибка "rsyslog service failed"

Ошибка rsyslog service failed (или Active: failed (result: exit-code) в выводе systemctl status rsyslog) означает, что системный демон rsyslog — основная служба сбора, обработки и записи логов в Linux — не смогла корректно запуститься. В результате система перестаёт централизованно записывать сообщения от ядра, системных сервисов и большинства приложений в файлы в /var/log/ (например, syslog, auth.log, messages). Это критичная проблема, так как без логов диагностировать другие сбои становится крайне сложно.

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

• При попытке запуска: sudo systemctl start rsyslog завершается с ошибкой.
• При проверке статуса: systemctl status rsyslog показывает Active: failed.
• В журнале systemd (journalctl -u rsyslog) присутствуют записи об ошибке инициализации.

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

Причины, по которым rsyslog не может стартовать, обычно находятся в конфигурации, правах доступа или конфликтах портов.

1. Синтаксическая ошибка в конфигурационных файлах. Самая частая причина. Неправильный синтаксис в /etc/rsyslog.conf или любом файле внутри /etc/rsyslog.d/ (например, лишний символ, незакрытый блок, опечатка в модуле) приводит к немедленному завершении работы демона.
2. Повреждение или некорректное изменение конфигурации. Ручное редактирование, сбой при записи или использование несовместимых параметров из-за обновления пакета rsyslog.
3. Конфликт порта. Демон rsyslog по умолчанию слушает порты 514/TCP и 514/UDP. Если эти порты уже заняты другим процессом (например, старый syslogd, другой агент логов или кастомный сервис), rsyslog не сможет привязаться и завершится с ошибкой.
4. Недостаточные права на файлы и директории. У пользователя syslog (от которого обычно работает демон) нет прав на чтение конфигурационных файлов или запись в целевые директории логов (/var/log/ и её поддиректории). Это часто случается после ручного изменения прав (chmod/chown) или при erroneous развёртывании.
5. Проблемы с модулями (модульные ошибки). В конфигурации могут быть подключены сторонние или встроенные модули (module(load="...")), которые отсутствуют в системе, повреждены или несовместимы с текущей версией rsyslog.
6. Недостаток ресурсов или повреждение бинарных файлов. Редко, но возможно повреждение самого пакета rsyslog или исчерпание лимитов системы (например, слишком много открытых файлов в конфиге).

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

Решайте проблемы последовательно, начиная с самых простых и распространённых.

Способ 1: Диагностика через статус и логи systemd

Первым делом необходимо получить точную информацию о том, почему служба упала.

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

   systemctl status rsyslog
   

   
   В выводе ищите строки Active: failed (result: exit-code) и, что важнее, Main PID и CGroup. Часто прямо в этом выводе есть краткое сообщение об ошибке (например, Cannot open /etc/rsyslog.conf: Permission denied).
2. Просмотрите подробный журнал systemd для этой службы. Это самый важный шаг:

   journalctl -u rsyslog --since "5 min ago" -p err -b
   

   • -u rsyslog — фильтр по юниту.
   • --since "5 min ago" — показать логи за последние 5 минут (измените при необходимости).
   • -p err — показать только сообщения уровня error и выше.
   • -b — показать логи с текущей загрузки системы.
   
   На что смотреть: Ищите конкретные тексты ошибок: permission denied, file not found, syntax error, address already in use, module loading failed.

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

Если в логах есть намёк на проблему с конфигом или вы недавно его редактировали, проведите строгую проверку.

1. Выполните команду проверки синтаксиса. Rsyslog умеет проверять конфиг без запуска:

   sudo rsyslogd -N1
   

   • -N1 — проверить синтаксис всей конфигурации (включая файлы из /etc/rsyslog.d/).
   • Выход 0 — синтаксис корректен.
   • Ненулевой выход и сообщение об ошибке — проблема найдена. Вывод покажет приблизительное место ошибки (файл и номер строки).
2. Если проверка выявила ошибку, откройте указанный файл и исправьте синтаксис. Распространённые проблемы:
   • Отсутствие точки с запятой (;) после директив.
   • Неправильное использование кавычек или скобок.
   • Опечатки в именах модулей или действий (action()).

Способ 3: Восстановление конфигурации и прав

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

1. Временно восстановите стандартный конфиг. Это поможет исключить проблему в ваших правках.
   • Для Ubuntu/Debian: конфиг можно взять из пакета (/usr/share/doc/rsyslog/examples/) или переустановить пакет, сохранив старый:

   sudo cp /etc/rsyslog.conf /etc/rsyslog.conf.bak
   sudo apt-get install --reinstall rsyslog  # Для Debian/Ubuntu
   

   
   Перед переустановкой убедитесь, что у вас есть бэкап!
   • Для RHEL/CentOS/Fedora:

   sudo cp /etc/rsyslog.conf /etc/rsyslog.conf.bak
   sudo yum reinstall rsyslog
   

2. После восстановления конфига проверьте права на ключевые файлы и директории:

   ls -ld /etc/rsyslog* /etc/rsyslog.d/
   ls -ld /var/log/
   

   
   Правильные владельцы и права обычно:
   • /etc/rsyslog.conf — root:root, права 644.
   • /etc/rsyslog.d/ — root:root, права 755.
   • /var/log/ — root:root, права 755 (или 775 если группа adm).
   • Файлы логов внутри /var/log/ могут принадлежать syslog:adm или root:root.
   
   Исправьте права при необходимости:

   sudo chown root:root /etc/rsyslog.conf
   sudo chmod 644 /etc/rsyslog.conf
   sudo chown -R root:root /etc/rsyslog.d/
   sudo chmod -R 755 /etc/rsyslog.d/
   sudo chown -R syslog:adm /var/log/  # Будьте осторожны, это массовая операция
   

Способ 4: Проверка конфликта портов и запуск вручную

Если предыдущие шаги не помогли, возможно, порт 514 занят.

1. Проверьте, какой процесс слушает порты 514:

   sudo ss -tulpn | grep ':514'
   

   
   Или:

   sudo netstat -tulpn | grep ':514'
   

2. Если в выводе вы видите процесс не rsyslogd (например, syslogd, nginx, кастомный скрипт), это и есть конфликт. Остановите или перенастройте этот другой сервис, чтобы освободить порт.
3. Попробуйте запустить rsyslog вручную в foreground с отладкой. Это даст максимально подробный вывод прямо в консоль:

   sudo rsyslogd -n -f /etc/rsyslog.conf -d
   

   • -n — не демонизировать (оставаться в foreground).
   • -f — явно указать конфиг (по умолчанию используется).
   • -d — включить режим отладки (debug).
   
   Запустите команду и посмотрите, на каком именно этапе процесс завершается или падает с ошибкой. Сообщения будут выводиться прямо в терминал. Для выхода нажмите Ctrl+C.

Способ 5: Анализ через strace (для продвинутых)

Если ничего не помогает, можно использовать strace для отслеживания системных вызовов демона при запуске. Это покажет, на какой именно операции (открытие файла, доступ к сокету) происходит сбой.

sudo strace -f -e trace=file,network -o /tmp/rsyslog.strace rsyslogd -N1

После выполнения откройте файл /tmp/rsyslog.strace и найдите в конце строки с EACCES (доступ запрещён) или ENOENT (файл не найден).

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

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

1. Всегда проверяйте синтаксис конфигурации перед перезагрузкой или применением изменений, используя sudo rsyslogd -N1.
2. Делайте резервные копии (/etc/rsyslog.conf, /etc/rsyslog.d/) перед любыми значительными изменениями.
3. Избегайте ручного редактирования прав на системные директории (/var/log/, /etc/). Используйте стандартные утилиты (chown, chmod) с пониманием их действия.
4. При установке сторонних ПО, которое шлёт логи, проверяйте, не добавляет ли оно конфликтующие правила в /etc/rsyslog.d/.
5. Регулярно обновляйте систему, но после обновления пакета rsyslog проверьте статус службы, если вы использовали кастомную конфигурацию.