Вопрос или проблема
У меня есть хост, на котором работает rsyslog, использующий imuxsock для принятия сообщений от journald. Однако, во время загрузки, после запуска rsyslog, он снова перезапускается (останавливается и запускается) systemd. Мне нужно выяснить, почему systemd это сделал.
Как можно понять, что заставило systemd перезапустить службу? (в данном случае это было вскоре после начального запуска)
Я сталкиваюсь с проблемой, когда в течение минуты или около того между стартом journald и стартом rsyslog я вижу в rsyslog только сообщения ядра (и никаких сообщений из пользовательского пространства). Однако, после времени старта rsyslog, сообщения из пользовательского пространства также видны. Думаю, неожиданный перезапуск может быть как-то с этим связан.
У меня установлено “Restart=on-failure” в файле службы.
Вот логи с моего хоста, которые не дают подсказки о причине перезапуска.
host_1:/home/admin# journalctl -u rsyslog --no-pager
-- Logs begin at Thu 2019-10-24 15:01:58 UTC, end at Thu 2019-10-24 17:20:37 UTC. --
Oct 24 15:03:25 host_1 rsyslogd[5332]: environment variable TZ is not set, auto correcting this to TZ=/etc/localtime [v8.36.0 try http://www.rsyslog.com/e/2442 ]
Oct 24 15:03:25 host_1 rsyslogd[5332]: imuxsock: Acquired UNIX socket '/run/systemd/journal/syslog' (fd 3) from systemd. [v8.36.0]
Oct 24 15:03:25 host_1 rsyslogd[5332]: [origin software="rsyslogd" swVersion="8.36.0" x-pid="5332" x-info="http://www.rsyslog.com"] start
Oct 24 15:03:25 host_1 systemd[1]: Starting System Logging Service...
Oct 24 15:03:25 host_1 systemd[1]: Started System Logging Service.
Oct 24 15:03:26 host_1 systemd[1]: Stopping System Logging Service...
Oct 24 15:03:26 host_1 rsyslogd[5332]: [origin software="rsyslogd" swVersion="8.36.0" x-pid="5332" x-info="http://www.rsyslog.com"] exiting on signal 15.
Oct 24 15:03:26 host_1 systemd[1]: Stopped System Logging Service.
Oct 24 15:03:26 host_1 systemd[1]: Starting System Logging Service...
Oct 24 15:03:26 host_1 rsyslogd[6201]: environment variable TZ is not set, auto correcting this to TZ=/etc/localtime [v8.36.0 try http://www.rsyslog.com/e/2442 ]
Oct 24 15:03:26 host_1 systemd[1]: Started System Logging Service.
Oct 24 15:03:26 host_1 rsyslogd[6201]: imuxsock: Acquired UNIX socket '/run/systemd/journal/syslog' (fd 3) from systemd. [v8.36.0]
Oct 24 15:03:26 host_1 rsyslogd[6201]: [origin software="rsyslogd" swVersion="8.36.0" x-pid="6201" x-info="http://www.rsyslog.com"] start
Похожая загадка с моей стороны. У меня есть служба (Java-приложение в виде Systemd-юнита), которая работает нормально несколько дней. Вдруг сегодня она была перезапущена. В journaldctl я вижу только эти логи в момент перезапуска:
Stopping foobar.service - foobar service...
Stopped foobar.service - foobar service.
foobar.service: Consumed 6min 25.495s CPU time, 184.7M memory peak, 0B memory swap peak.
Starting foobar.service - foobar service...
Started foobar.service - foobar service.
Это произошло на Ubuntu 24.04.1 LTS.
ОБНОВЛЕНИЕ: после дальнейшего расследования я обнаружил, что этот перезапуск был частью большего числа перезапусков, выполненных Systemd, и все началось с этого:
systemd[1]: Starting apt-daily-upgrade.service - Daily apt upgrade and clean activities...
По-видимому, это какой-то процесс обновления.
Основной причиной являются таймеры: apt-daily.timer и apt-daily-upgrade.timer, которые по умолчанию настроены в Ubuntu.
Эти таймеры можно отключить и остановить:
sudo systemctl disable apt-daily.timer
sudo systemctl disable apt-daily-upgrade.timer
sudo systemctl stop apt-daily.timer
sudo systemctl stop apt-daily-upgrade.timer
Заключительная мысль: чтобы выяснить причину перезапуска службы, необходимо посмотреть логи всех служб за некоторое время до того, как ваша служба была перезапущена. Пример команды для поиска таких логов на основе дат:
journalctl --since "2025-02-06 06:35" --until "2025-02-06 06:45"
Ответ или решение
Для выявления причины перезапуска сервиса systemd, такого как rsyslog, необходимо применить внимательный подход к анализу журнала событий, а также учесть возможные зависимости и взаимодействия между сервисами и их настройками. В данной ситуации, когда происходит неожиданный перезапуск rsyslog сразу после его запуска, потребуется пошаговый анализ событий, которые могут повлиять на поведение systemd. Давайте рассмотрим возможные действия и сценарии в деталях.
Теория
Systemd — это мощная система инициализации и управления сервисами в операционных системах на базе Linux. Она отвечает за управление состоянием системы и сервисов, включая запуск, остановку и мониторинг процессов. При этом systemd может автоматически перезапустить сервис, если установлено соответствующее правило, например, Restart=on-failure в файле настроек сервиса.
Основные причины, по которым systemd может перезапустить сервис, включают:
-
Неудачный запуск или ошибка в работе: Если сервис завершился нештатно, для предотвращения сбоев он может быть перезапущен.
-
Обновление системы или сервисов: В случаях, когда выполняется обновление пакетов (например, через apt на Ubuntu), systemd может перезапустить связанные сервисы, чтобы применить изменения.
-
Изменения в конфигурации: Если при загрузке изменились конфигурационные файлы, systemd может перезапустить сервисы, чтобы интегрировать эти изменения.
-
Зависимости и порядок загрузки: Неправильная настройка зависимостей между сервисами может привести к тому, что один сервис будет перезапущен вслед за другим.
Пример
В предоставленном журнале видно, что rsyslog был перезапущен буквально через секунду после старта. Это указывает на то, что либо сервис завершился нештатно, либо на него оказало влияние внешнее событие, например, работа другого системного процесса или обновления.
В примере другому пользователю удалось найти связь между перезапусками и работой apt-daily-upgrade.service. Этот сервис был инициирован таймерами apt-daily.timer и apt-daily-upgrade.timer, которые по умолчанию активны на некоторых системах Ubuntu. Данный процесс мог привести к перезапуску группы сервисов, среди которых оказался и искомый сервис.
Применение
Чтобы точно определить, почему сервис был перезапущен, выполните несколько последовательных шагов:
-
Анализ логов: Используйте
journalctlдля анализа журналов событий. Например:journalctl -u rsyslog --no-pager --since "2023-10-24 15:03:00" --until "2023-10-24 15:05:00"Эти команды позволяют сосредоточиться на периоде до и после перезапуска, чтобы выявить потенциальные причины и увидеть, что еще происходило на системе.
-
Исследование соседних событий: Работайте не только с логами rsyslog, но и с записями об других системных событиях в тот же период. Это поможет выявить, не было ли внешних воздействий, которые могли привести к перезапуску.
-
Проверка конфигураций и зависимостей: Исследуйте конфигурационные файлы
/etc/systemd/system/и/lib/systemd/system/для выяснения возможных зависимостей и настроек, которые могут влиять на порядок запуска сервисов. Проверьте, установлены ли корректно временные зависимости (After=,Before=,Requires=,Wants=) в файле юнита rsyslog. -
Обновления и таймеры: Проверьте наличие и активность любых автоматических обновлений и таймеров на системе, которые могут повлиять на работу сервисов:
systemctl list-timers --allЕсли обнаружите, что перезапуски связаны с обновлениями, рассмотрите возможность отключения или изменения расписания для конкретных таймеров.
-
Установка переменных окружения: Как правило, проблема с переменными окружения (например,
TZ) может быть устранена добавлением соответствующих значений в конфигурационный файл или скрипт.
Применяя данные методы, вы сможете выявить причину перезапуска rsyslog и предпринять соответствующие меры для предотвращения будущих непредвиденных перезапусков. Всегда проверяйте системные журналы в расширенном временном диапазоне, чтобы получить максимально полную картину того, что происходит в вашей системе.