Почему при проверке программа возвращает код выхода 0

Монит здесь, чтобы поймать проблемы на наблюдаемом объекте.

Итак - построчно - ваша конфигурация сообщает Monit:

check program lo-check-8101 with path "/bin/bash /opt/libreoffice/chkloproc.sh TestLOPort8101 8101" with timeout 10 seconds

Выполнить двоичный файл. Сохраните код выхода и некоторую дополнительную информацию.

        if status != 0 then exec "/bin/bash /opt/libreoffice/loproc_is_down.sh"

Проблема возникает, если статус не равен 0. Теперь выполните двоичный файл.

        if status = 0 then exec "/bin/bash /opt/libreoffice/loproc_is_up.sh"

Проблема возникает, если статус равен 0. Теперь выполните двоичный файл. - Я даже не понимаю, каким должен быть результат этого звонка. Здесь все в порядке, так зачем что-то выполнять?

Скажем так: с этим конфигом нет случая "успех" (= все хорошо).

Чтобы оптимизировать его, вы должны ловить проблемы только с Monit:

check program lo-check-8101 with path "/opt/libreoffice/chkloproc.sh TestLOPort8101 8101"
    with timeout 10 seconds
    if status != 0 then exec "/opt/libreoffice/loproc_is_down.sh"
    if 2 restarts within 3 cycles then unmonitor

Это означает, что Monit ничего не делает, если статус равен 0.

Еще несколько слов о конфиге:

1. Если я правильно понял (посмотреть этот вопрос), безголовый сервер создаст PID-файл. Так что вы также можете проверить с check process и, возможно, некоторые send/expect магия для проверки того, что служба запущена.
2. Если вы установите .sh исполняемые файлы (+x; т.е. chmod +x /opt/libreoffice/*.sh) и у вас есть правильный Shebang в этих файлах вы можете опустить /bin/bash в ваших исполнениях для лучшей читаемости.

Моя конфигурация по этому поводу (не зная, какой протокол используется :8101, предполагая, что http) будет примерно так:

check process libre-local with pidfile "/var/run/libreoffice-server.pid"
    start program = "/usr/bin/systemctl start libreoffice-server" # Unit name is an assumption!
    stop program = "/usr/bin/systemctl stop libreoffice-server" # Unit name is an assumption!

    if failed
        port 8101
        protocol http
        request "/any_valid_entrypoint"
        for 2 cycles
    then restart

    # if loadavg (5min) per core > 1 for 5 cycles then restart
    if loadavg (5min) > 4 for 5 cycles then restart
    if totalmem > 2 GB for 5 cycles then restart
    if 3 restarts within 5 cycles then unmonitor

Получение loadavg с участием per core требуется последняя версия Monit. Так что он может быть недоступен в вашем дистрибутиве, поэтому я закомментировал эту строку;)

Изменить после ответа от OP (Надеюсь, вы получите уведомление):

(это действительно боль, которую мы не можем комментировать <50 Rep ...)

Если я правильно понял, вам нужно что-то преобразовать, чтобы получить состояние приложения, если преобразование не удается, приложение следует перезапустить. Переведено на Monit:

check program lo-check-8101 with path "CONVERT_HERE"
    with timeout 10 seconds
    if status != 0 then exec "/usr/bin/systemctl restart libreoffice-server"
    if 2 restarts within 3 cycles then unmonitor

... где CONVERT_HERE исполняемый файл завершается с 0, если преобразование прошло успешно, и <> 0, если оно не выполнено. Я все еще чувствую, что что-то здесь упустил. ;)

Не могли бы вы вкратце изложить все три исполняемых файла или что-то в этом роде?

@boppy: Спасибо за ответ.

Вы правы, мне нужно заниматься процессами "Безголовый Libre Office".

LibreOffice немного неприятен и принимает соединения, хотя он уже зависает ... так что вы можете узнать о работоспособности запущенного процесса lo, только если вы можете что-то преобразовать (это происходит в сценарии проверки).

Из-за этого я не могу полагаться на PID или проверку портов ... и пытаюсь обойтись с моим check-script + monit to REJECT соединения, если преобразование не работает.

Идея заключается в следующем:

Если monit добавляет правило в iptables для REJECT подключений к процессам lo, он должен удалить это добавленное правило, если процесс lo вернулся / работоспособен и снова конвертируется.

Возможно, monit - неправильный инструмент для этого, или я просто думаю, что это сложно ... но monit выглядит намного лучше, чем использование cron для выполнения этих проверок и iptables ... возможно, я попробую cron.

Из вашего ответа я узнал важную вещь, а именно, что состояния успеха не существует, если я использую строки «IF STATUS = 0 THEN EXEC ...» в конфигурации monit.

Таким образом, monit не интерпретирует значение выхода 0 как «успех» из-за этой строки «IF ... EXEC».

И спасибо за вашу monit-config ... кажется хорошей идеей перезапустить процессы lo, если они выходят из строя.

Но с monit все еще что-то не так ... Я начинаю monit с включенной отладкой, помещая "-v" в качестве опции в / etc / defaults / monit и вижу следующие строки журнала: (циклы мониторинга настроены на 30 секунд длинный)

[CET Oct 31 16:49:00] error    : 'lo-check-8101' status failed (0) -- conversion ok
[CET Oct 31 16:49:00] debug    : 'lo-check-8101' status succeeded (0) -- conversion ok
[CET Oct 31 16:49:00] debug    : 'lo-check-8101' program started
[CET Oct 31 16:49:30] error    : 'lo-check-8101' status failed (0) -- conversion ok
[CET Oct 31 16:49:30] debug    : 'lo-check-8101' status succeeded (0) -- conversion ok
[CET Oct 31 16:49:30] debug    : 'lo-check-8101' program started

Это ошибка монитора? Возможно, мне нужна более новая версия monit.