несоответствие протокола готовности
Как и предполагал Виланд, Typeуслуги важны. Этот параметр обозначает, какой протокол готовности systemd ожидает, что служба будет говорить. Предполагается, что simpleуслуга немедленно готова. forkingСлужба берется , чтобы быть готовым после его первоначальный процесс разветвляется ребенка , а затем завершает свою работу. dbusСлужба берется , чтобы быть готовым , когда на Desktop Bus появляется сервер. И так далее.
Если вы не получите протокол готовности, объявленный в сервисном модуле, чтобы он соответствовал тому, что делает сервис, тогда все пошло не так. Несоответствия протокола готовности приводят к тому, что службы запускаются некорректно или (чаще) диагностируются (ошибочно) системой systemd как сбой. Когда служба считается не способной запустить systemd, она гарантирует, что каждый потерянный дополнительный процесс службы, который мог остаться запущенным как часть сбоя (с его точки зрения), завершается, чтобы надлежащим образом вернуть службу в неактивное состояние. государство.
Вы делаете именно это.
Прежде всего, простые вещи: sh -cне соответствует Type=simpleили Type=forking.
В simpleпротоколе, начальный процесс берется быть процесс обслуживания. Но на самом деле sh -cоболочка запускает реальную сервисную программу как дочерний процесс . Так что MAINPIDпойдет не так и ExecReloadперестает работать, для начала. При использовании Type=simpleнужно либо использовать, sh -c 'exec …'либо не использовать sh -c в первую очередь. Последнее чаще является правильным курсом, чем думают некоторые.
sh -cне соответствует Type=forkingни. Протокол готовности к forkingуслуге довольно специфичен. Начальный процесс должен разветвить ребенка, а затем выйти. systemd применяет тайм-аут к этому протоколу. Если начальный процесс не разветвляется в течение выделенного времени, это не готовность к готовности. Если начальный процесс не завершается в течение отведенного времени, это тоже сбой.
ненужный ужас, который ossec-control
Что приводит нас к сложным вещам: этот ossec-controlсценарий.
Оказывается , это rcсценарий System 5, который запускает от 4 до 10 процессов, которые, в свою очередь, тоже разветвляются и выходят. Это один из тех rcсценариев System 5, который пытается управлять целым набором серверных процессов в одном сценарии с forциклами, состояниями гонки, произвольными значениями, sleepчтобы попытаться их избежать, режимами сбоев, которые могут задушить систему в начальном состоянии, и все остальные ужасы, которые заставили людей изобретать такие вещи, как AIX System Resource Controller и daemontools два десятилетия назад. И давайте не будем забывать скрытый сценарий оболочки в двоичном каталоге, который он переписывает на лету, для реализации уникальных enableи disableглаголов.
Итак, когда вы, /bin/sh -c '/var/ossec/bin/ossec-control start'что происходит, это:
- systemd разветвляет процесс обслуживания.
- Это оболочка, которая разветвляется
ossec-control.
- Это в свою очередь раздваивает от 4 до 10 внуков.
- Внуки все разветвляются и выходят по очереди.
- Все правнуки разветвляются и выходят параллельно.
ossec-control выходы.- Первая оболочка выходит.
- Процессы обслуживания были большие-пра внуков, а потому , что этот путь рабочих матчей ни
forking ниsimple протокол готовности, Systemd не считает службу в целом, не удалось , и закрывает его обратно вниз.
Ничто из этого ужаса на самом деле не нужно в systemd вообще. Ничего из этого.
системный сервисный шаблон
Вместо этого пишется очень простой шаблонный блок :
[Единица измерения]
Описание = Сервер OSSEC HIDS% i
После того, как = network.target
[Обслуживание]
Тип = простой
ExecStartPre = / usr / bin / env / var / ossec / bin /% p-% i -t
ExecStart = / usr / bin / env / var / ossec / bin /% p-% i -f
[Установить]
WantedBy = multi-user.target
Сохраните это как /etc/systemd/system/ossec@.service.
Различные реальные сервисы являются экземплярами этого шаблона и называются:
ossec@dbd.serviceossec@agentlessd.serviceossec@csyslogd.serviceossec@execd.serviceossec@agentd.serviceossec@logcollector.serviceossec@syscheckd.serviceossec@maild.serviceossec@analysisd.serviceossec@remoted.serviceossec@monitord.service
Затем функция включения и выключения поступает прямо из системы управления службами (с исправленной ошибкой RedHat 752774 ), без необходимости скрытых сценариев оболочки.
systemctl включить ossec @ dbd ossec @ agentlessd ossec @ csyslogd ossec @ maild ossec @ execd ossec @ analysisd ossec @ logcollector ossec @ удаленный ossec @ syscheckd ossec @ monitord
Кроме того, systemd узнает и отслеживает каждую реальную службу напрямую. Он может фильтровать их журналы с journalctl -u. Он может знать, когда произошел сбой отдельной службы. Он знает, какие службы должны быть включены и запущены.
Кстати, Type=simpleи -fвариант здесь, как и во многих других случаях. Очень немногие службы в дикой природе фактически сигнализируют о своей готовности посредством exit, и это тоже не такие случаи. Но это то, что forkingозначает тип. Службы в дикой природе в основном просто разветвляются и выходят из-за ошибочно полученного мудрого представления о том, что именно этим и должны заниматься демоны. На самом деле это не так. Это не было с 1990-х годов. Пришло время наверстать упущенное.
дальнейшее чтение