Короче говоря - каким-то образом мне удалось облажаться со службой rsyslogd на сервере Centos 7. Теперь единственное, что появляется в / var / log / messages:
14 декабря 22:13:27 {myhostname} rsyslogd: [origin software = "rsyslogd" swVersion = "7.4.7" x-pid = "1286" x-info = "http://www.rsyslog.com"] выход по сигналу 15.
14 декабря 22:13:27 {myhostname} rsyslogd: [origin software = "rsyslogd" swVersion = "7.4.7" x-pid = "1477" x-info = "http://www.rsyslog.com"] start
Остальные журналы (secure, cron и т. Д.) Тоже пусты. Перезапуск службы и сервера не помог. Сообщения, отправленные регистратором, не попадают в файл / var / log / messages. Служба rsyslogd запущена. Файл конфигурации кажется правильным. Я могу видеть все события в журналах journalctl. Я уже просмотрел несколько сообщений, похожих на мою проблему, но ни один из них не нашел решения.
Хотя самым быстрым решением может быть переустановка сервера, я хотел бы выяснить, что вызвало эту проблему и как ее решить, если это произойдет в будущем. На сервере работает простой стек LEMP, и последним серьезным изменением в системе было изменение имени хоста.
Это было решение, но не постоянное:
rm -f /var/lib/rsyslog/imjournal.state
перезапуск службы rsyslog
Источник: https://bugzilla.redhat.com/show_bug.cgi?id=1088021
Это было мое решение - не очень хорошее, конечно, вы теряете весь прошлый журнал:
rm -rf /var/log/journal/*
reboot
Я до сих пор не понимаю, почему все это началось, потому что все, что я сделал, это перезагрузка примерно через 6 месяцев безотказной работы.
Вы можете попробовать отладить rsyslog чтобы выяснить причину неисправности.
Получение отладочной информации из запущенного экземпляра
Можно получить отладочную информацию из запущенного экземпляра, но это требует некоторой настройки. Мы предполагаем, что экземпляр работает в фоновом режиме, поэтому вывод отладки в стандартный вывод нежелателен. Таким образом, вся отладочная информация должна записываться в файл журнала.
Чтобы создать эту настройку, вам нужно указать
RSYSLOG_DEBUGLOGпеременную среды в файл, который доступен во время выполнения (мы настоятельно рекомендуем файл в локальной файловой системе!)RSYSLOG_DEBUGпо крайней мереDebugOnDeman NoStdOutубедитесь, что эти переменные среды установлены в правильном (специфичном для дистрибутива) сценарии запуска, если вы не запускаете rsyslogd в интерактивном режимеЭти настройки позволяют реагировать на SIGUSR1. При получении сигнала будет переключаться статус отладки. Поэтому отправьте его, чтобы включить вход отладки, и отправьте его снова, чтобы снова отключить выход отладки. Третий раз снова включится ... и так далее.
В типичной системе вы можете сигнализировать rsyslogd следующим образом:
kill -USR1 `cat /var/run/rsyslogd.pid`Важно: есть обратные кавычки вокруг «кота» -команды. Если вы используете обычную цитату, это не сработает. Журнал отладки покажет, включено ли ведение журнала отладки. Другой индикации статуса нет.
Пошаговая инструкция здесь: Как использовать отладку по запросу?
Мой rsyslogd.service отказывается показывать
Failed to start System Logging Service.
Unit rsyslog.service entered failed state.
rsyslog.service failed.
rsyslog.service holdoff time over, scheduling restart.
start request repeated too quickly for rsyslog.service
Failed to start System Logging Service.
Unit rsyslog.service entered failed state.
rsyslog.service failed.
Я убил сервис, чтобы убедиться, что он не работает
killall rsyslogd
затем удалил файл pid
rm /var/run/syslogd.pid
и снова запустил сервис
systemctl start rsyslog.service
теперь статус в порядке
# systemctl status rsyslog.service
● rsyslog.service - System Logging Service
Loaded: loaded (/usr/lib/systemd/system/rsyslog.service; enabled; vendor preset: enabled)
Active: active (running) since Tue 2018-02-06 11:32:33 CET; 2s ago
и файлы журналов / var / log / * снова растут.
В моей ситуации это произошло из-за того, что были установлены и rsyslog, и syslog-ng, которые конкурировали за контроль ведения журнала в системе. Удаление syslog-ng (с yum remove syslog-ng) и перезагрузка устранила проблему.