Небольшая заметка на тему Zabbix Server на основе своего опыта. Иногда бывает ситуация, особенно после системных обновлений, когда ты перезагружаешь сервер, а он зависает. Тебя отрубает от SSH, виртуалка висит в неопределённом состоянии, приходится принудительно завершать работу. Проблема актуальна, когда мониторинг и СУБД живут на одной машине.

Смысл проблемы в том, что процесс с СУБД завершает свою работу раньше, чем Zabbix Server. И он пытается достучаться до базы, которая уже выключилась. А серверу надо туда свои кэши или буферы скинуть перед остановкой. И он не может. Пытается, но не может. В итоге все службы завершают работу, в том числе SSH, а Zabbix Server всё ещё висит и держит всю систему.

Сколько времени он может пробыть в таком состоянии - не знаю, не проверял. Обычно минут 10 повисит и я принудительно завершаю работу виртуалки. Так как СУБД завершает свою работу штатно, к проблемам это ни разу не приводило.

Так что перезагружая виртуалку с Zabbix Server, я сначала вручную завершаю работу мониторинга:

# systemctl stop zabbix-server

А потом уже набираю

# reboot

По этой проблеме был заведён баг на официальном трекере мониторинга. Проблему решили перечислением зависимостей в systemd юните zabbix-server.service. Добавили параметр After и перечислили службы СУБД, от которых зависит служба Zabbix Server. Если я правильно понял, то этот параметр указывает на то, что служба мониторинга запускается после службы СУБД и эта же настройка управляет завершением работы, но в обратном порядке. То есть сначала завершается служба мониторинга, а потом уже СУБД.

Если у вас используется версия СУБД, которая не перечислена в системном юните, то вы по-прежнему можете получить эту ошибку. Выглядит это примерно так:

After=mysql.service
After=mysqld.service
After=mariadb.service

Если у вас используется PostgreSQL, то задача усложняется. Там службы СУБД указаны с номерами версий. Для юнита Zabbix это выглядит так:

After=postgresql-9.4.service
After=postgresql-9.5.service
After=postgresql-9.6.service
After=postgresql-10.service
After=postgresql-11.service
After=postgresql-12.service
After=postgresql-13.service
After=postgresql-14.service
After=postgresql-15.service
After=postgresql-16.service

Соответственно, если у вас имя службы СУБД выглядит как-то иначе, получите описанную проблему, если не обновите юнит сами.

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

Соблюдаю это правило для всех систем, где есть зависимость от службы СУБД. Например, на серверах с 1С + PostgreSQL всегда сначала вручную останавливаю службу 1С, а потом уже выполняю какие-то другие действия - обновление, перезагрузка и т.д. Баг с заббиксом приучил так действовать просто на всякий случай.

#zabbix #ошибка