несоответствие протокола готовности

Как подразумевал Виланд, важен Тип службы. Этот параметр указывает, какой протокол готовности systemd ожидает от службы. Предполагается, что простой сервис будет готов немедленно. Служба forking считается готовой после того, как ее начальный процесс вызовет дочерний, а затем выйдет из него. Служба dbus считается готовой, когда сервер появляется на шине Desktop Bus. И так далее.

Если протокол готовности, объявленный в единице службы, не соответствует тому, что делает служба, то все пойдет не так. Несоответствие протокола готовности приводит к тому, что службы не запускаются правильно или (чаще всего) неправильно диагностируются systemd как неработающие. Когда считается, что служба не запускается, systemd гарантирует, что каждый осиротевший дополнительный процесс службы, который мог остаться запущенным как часть сбоя (с его точки зрения), будет убит, чтобы вернуть службу в неактивное состояние.

Вы делаете именно это.

Прежде всего, простые вещи: sh -c не соответствует Type=simple или Type=forking.

В протоколе simple начальный процесс принимается за be процесс обслуживания. Но на самом деле обертка sh -c запускает фактическую служебную программу как дочерний процесс. Поэтому MAINPID идет неправильно, а ExecReload перестает работать, для начала. При использовании Type=simple нужно либо использовать sh -c 'exec ...', либо не использовать sh -c вообще. Последний вариант чаще всего оказывается правильным, чем некоторые думают.

sh -c также не соответствует Type=forking. Протокол готовности для forking сервиса довольно специфичен. Начальный процесс должен форкнуть дочерний, а затем выйти. systemd применяет таймаут к этому протоколу. Если начальный процесс не выполнит форкинг в течение отведенного времени, это будет означать, что он не готов. Если начальный процесс не завершается в течение отведенного времени, это тоже считается неудачей.

ненужный ужас, который представляет собой ossec-control

Что приводит нас к сложным вещам: этому ossec-control скрипту.

Оказывается, это скрипт System 5 rc, который форкает от 4 до 10 процессов, которые в свою очередь тоже форкаются и выходят. Это один из тех скриптов System 5 rc, который пытается управлять целым набором серверных процессов в одном скрипте, с for циклами, условиями гонки, произвольными sleeps, чтобы попытаться избежать их, режимами отказа, которые могут задушить систему в полузапущенном состоянии, и всеми другими ужасами, которые заставили людей изобрести такие вещи, как AIX System Resource Controller и daemontools два десятилетия назад. И давайте не будем забывать о скрытом сценарии оболочки в двоичном каталоге, который он переписывает на лету, чтобы реализовать идиосинкразические включить и отключить глаголы.

Поэтому, когда вы /bin/sh -c '/var/ossec/bin/ossec-control start', происходит следующее:

1. systemd форкает то, что, как он ожидает, будет служебным процессом.
2. Это shell, который форкает ossec-control.
3. Это, в свою очередь, вызывает от 4 до 10 внуков.
4. Все внуки по очереди форкают и выходят.
5. Все правнуки развиваются и выходят параллельно.
6. ossec-control exits.
7. Первый shell выходит.
8. Процессы сервиса были пра-пра-внуками, но поскольку этот способ работы не соответствует ни форкингу, ни форкингу , ни протоколу простой готовности, systemd считает, что сервис в целом потерпел неудачу, и отключает его обратно.

Ничего из этого ужаса на самом деле не нужно в systemd вообще. Ничего из этого.

шаблонный блок службы systemd

Вместо этого можно написать очень простой шаблонный блок:

[Unit]
Description=The OSSEC HIDS %i server
After=network.target 

[Service]
Type=simple
ExecStartPre=/usr/bin/env /var/ossec/bin/%p-%i -t
ExecStart=/usr/bin/env /var/ossec/bin/%p-%i -f

[Install]
WantedBy=multi-user.target

Сохраните это как /etc/systemd/system/ossec@.service.

Различные реальные службы являются инстанциями этого шаблона и называются:

• ossec@dbd.service
• ossec@agentlessd.service
• ossec@csyslogd.service
• ossec@execd.service
• ossec@agentd.service
• ossec@logcollector.service
• ossec@syscheckd.service
• ossec@maild.service
• ossec@analysisd.service
• ossec@remoted.service
• ossec@monitord.service

Затем функция включения и отключения исходит прямо из системы управления сервисами (с исправленной ошибкой RedHat 752774), без необходимости использования скрытых сценариев оболочки.

 systemctl enable ossec@dbd ossec@agentlessd ossec@csyslogd ossec@maild ossec@execd ossec@analysisd ossec@logcollector ossec@remoted ossec@syscheckd ossec@monitord

Более того, systemd получает информацию о каждой реальной службе и отслеживает ее непосредственно. Она может фильтровать их журналы с помощью journalctl -u. Он может знать, когда отдельная служба потерпела неудачу. Он знает, какие службы должны быть включены и запущены.

Кстати: Type=simple и опция -f здесь так же уместны, как и во многих других случаях. Очень немногие сервисы в природе действительно сигнализируют о своей готовности посредством выхода, и эти случаи тоже не являются таковыми. Но именно это и означает тип forking. Сервисы в природе в основном просто форкают и выходят из-за какого-то ошибочного представления о том, что именно так должны поступать деймоны. На самом деле, это не так. Это не так с 1990-х годов. Пришло время наверстать упущенное.

Дальнейшее чтение

• Джонатан де Бойн Поллард (2015). Проблемы протокола готовности с деймонами Unix. Часто задаваемые ответы.