ALT Linux Bugzilla – Full Text Bug Listing
| Summary: | nagios, nrpe не стартуют после перезагрузки | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Branch p9 | Reporter: | Vera Blagoveschenskaya <vercha> | ||||
| Component: | nagios | Assignee: | manowar <manowar> | ||||
| Status: | CLOSED FIXED | QA Contact: | qa-p9 <qa-p9> | ||||
| Severity: | normal | ||||||
| Priority: | P5 | CC: | manowar, shaba, sotor | ||||
| Version: | не указана | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Linux | ||||||
| Bug Depends on: | 39645 | ||||||
| Bug Blocks: | |||||||
| Attachments: |
|
||||||
Не воспроизводится на других дистрибутивах. Например, на workstation k 9.0, workstation 9.1 после перезагрузки сервис nagios запущен. Могу предположить вот это: фев 01 12:38:13 server-91-x86-64-20210111.localdomain systemd[1]: /run/systemd/generator.late/nagios.service:24: PIDFile= references a path below legacy directory /var/run/, updating /var/run/nagios/nagios.pid → /run/nagios/nagios.pid; please update the unit file accordingly. То есть nagios у нас запускается через обёртку над init-скриптом, но при этом systemd самовольно меняет расположение PID-файла. Попробуйте поправить пусть до PID-файла в /etc/rc.d/init.d/nagios и /etc/nagios/nagios.cfg, чтобы в обоих местах было записано /run/nagios/nagios.pid. Если поможет, то сделаем такой пакет. (Ответ для manowar@altlinux.org на комментарий #2) > То есть nagios у нас запускается через обёртку над init-скриптом, но при > этом systemd самовольно меняет расположение PID-файла. Попробуйте поправить > пусть до PID-файла в /etc/rc.d/init.d/nagios и /etc/nagios/nagios.cfg, чтобы > в обоих местах было записано /run/nagios/nagios.pid. Если поможет, то > сделаем такой пакет. Поправила в двух файлах путь на /run/nagios/nagios.pid Не помогло. Кроме того, обратите внимание, что прблема актуальна только для сервера. На рабочих станциях сервис стартует успешно. Не могу воспроизвести. 1. Скачал образ сервера с getalt.org: https://mirror.yandex.ru/altlinux/p9/images/server/x86_64/alt-server-9.1-x86_64.iso 2. Выполнил установку (qemu), выбрал минимальную конфигурацию. 3. Выполнил dist-upgrade то текущего репозитория. 4. Установил nagios (3.0.6-alt13). 5. systemctl enable nagios 6. reboot 7. systemctl status nagios Резултат active (running), nagios работает. (Ответ для manowar@altlinux.org на комментарий #4) > Не могу воспроизвести. > 2. Выполнил установку (qemu), выбрал минимальную конфигурацию. Я тестирую в офисной конфигурации. (Ответ для Vera Blagoveschenskaya на комментарий #5) > Я тестирую в офисной конфигурации. Понял. Аналогичную ситуацию наблюдал вчера в c8.1. Причём не с nagios, а с nagios-nrpe. Если подождать несколько _минут_, то nagios запустится сам собой. А теперь о том, что и почему не работает. На мой взгляд, проблема заключается в том, что сервисы clamd и clamsmtpd (не знаю точно кто из них) задерживают запуск сервисов в формате SysV-init. В том числе и Nagios. Эти старые сервисы запускаются скриптами из директории /etc/rc.d/init.d. Сами скрипты как правило работают нормально (с этим и связано такое поведение, что "вручную запустить можно"), но автоматический их запуск _при наличии clamd и clamsmtpd_ задерживается. Между прочим, в jorunalctl -e видна ругань на ClamAV. А если дать команду jorunalctl -f и подождать, можно даже увидеть момент запуска "отстающих" сервисов. Происходит это, повторяю, только через несколько _минут_. Что ещё обращает на себя внимание? То, что первая загрузка после установки alt-сервер 9.1 также занимает _минут_ 5, причём в консоли видно, как systemd что-то постоянно postpone (откладывает). Правда последующие загрузки выполняются несколько быстрее, но всё равно до появления приглашения в _текстовой_ консоли (Ctrl+Alt+F2 и т.д.) проходит ощутимое количество времени. То есть графический сеанс уже запущен, а текстовый терминал всё ещё не готов. Пронаблюдав всё это, я просто-напросто отключил ClamAV: systemctl disable clamd systemctl disable clamsmtpd И получил в итоге: а) старт текстовой консоли без задержек; б) старт Nagios без задержек. 99,9% что эта ошибка не Nagios специфичная. Итого: я бы назвал эту ошибку так: сервис ClamAV задерживает запуск systemd-обёрток над сервисами SysV-init. Причём запуск сервисов SysV-init откладывается на минуты. 1) Про clamav могу сказать что он собран очень плохо. В пакете есть и init-скрипты и systemd unit-файлы, но они под разными именами. Поэтому для systemd это разные сервисы - clamd и clamav-daemon. Нужен хотя бы симлинк %_unitdir/clamd.service -> clamav-daemon.service 2) clamsmtp собран еще хуже. В нем нет systemd unit-файлов, а в init-скрипте отсутствует LSB заголовок, что и приводит к задержками загрузки системы, systemd просто не знает когда грузить такой сервис, нет никаких зависимостей. Наверно надо перевесить ошибки на целевые пакеты, но релиз-менеджерам стоит задуматься зачем они такие пакеты(такого низкого качества упаковки) включают в дистрибутивы. Так же при выпуске дистрибутивов, стоит проверить вывод команды chkconfig --list, она покажет сервисы без systemd unit-файлов, и заставит задуматься, так ли нужен этот пакет в дистрибутиве. (Ответ для manowar@altlinux.org на комментарий #2) > Могу предположить вот это: > > фев 01 12:38:13 server-91-x86-64-20210111.localdomain systemd[1]: > /run/systemd/generator.late/nagios.service:24: PIDFile= references a path > below legacy directory /var/run/, updating /var/run/nagios/nagios.pid → > /run/nagios/nagios.pid; please update the unit file accordingly. > > То есть nagios у нас запускается через обёртку над init-скриптом, но при > этом systemd самовольно меняет расположение PID-файла. Попробуйте поправить > пусть до PID-файла в /etc/rc.d/init.d/nagios и /etc/nagios/nagios.cfg, чтобы > в обоих местах было записано /run/nagios/nagios.pid. Если поможет, то > сделаем такой пакет. Нет, systemd ничего не меняет и не придумывает. Просто предупреждает, что используется устаревший путь /var/run, и напоминает что надо бы обновить. Спасибо. А как может быть связан запуск clamd с запуском обёрток над SysV-init? В какой момент они стартуют и как? Можно ли где-то посмотреть юниты, которые для них генерируются или они существуют лишь виртуально? А, до меня наконец дошло. Сам clamd (как и clamsmtpd) тоже не имеет настоящего юнита --- он тоже стартует как обёртка над SysV-init. И дальше, видимо, всё просто: обёртки над SysV-init стартуют _последовательно_, друг за другом. И если clamd стартует несколько минут, то тем самым он задерживает весь "состав" идущий следом. Следовательно, нужно а) починить старт ClamAV (минуты --- это несерьёзно) и б) написать (взять из сети) для него нормальный юнит --- тогда он будет запускаться _параллельно_. Думаю, что нужно завести отдельный баг на ClamAV, а этот поставить в зависимость от него. (Ответ для manowar@altlinux.org на комментарий #10) > Думаю, что нужно завести отдельный баг на ClamAV, а этот поставить в > зависимость от него. https://bugzilla.altlinux.org/show_bug.cgi?id=39645 Для информации: с версией clamav-0.103.1-alt5.x86_64 Проблема старта сервисов не воспроизводится. Значит, закрываем этот баг? https://bugzilla.altlinux.org/show_bug.cgi?id=39645#c9 исправлен, этот тоже можно закрыть |
Created attachment 9168 [details] Лог journalctl -b Тестовый стенд alt server 9.1 x86_64 nagios-3.0.6-alt13.x86_64 1) Выполнить команду # systemctl enable nagios 2) Перезагрузиться 3) После перезагрузки проверить статус: # systemctl status nagios Результат: сервис не запущен. Вручную запустить можно, но после следующей перезагрузки история повторяется.