-1

собратья,

Я пытаюсь запустить сторожевое задание cron, чтобы убедиться, что процесс запущен (DreamHost продолжает уничтожать процессы). Я был вдохновлен этим вопросом SU.

Тем не менее, двойная труба || кажется не работает.

Моя запись cron:

# watchdog MAILTO="me@gmail.com" @daily . ~/.bashrc && cd /home/chucknorris/workingfolder/ && pgrep -f "python /home/chucknorris/workingfolder/web2py.py -K LLBean" > /dev/null || echo Hello

Проблема заключается в следующем: если процесс python не запущен, я не получаю сообщение «Hello» по почте.

Если я перейду на одну трубу |

pgrep -f "python /home/chucknorris/workingfolder/web2py.py -K LLBean" > /dev/null | echo Hello

Работа cron работает нормально. Я получил сообщение Hello если мой процесс python запущен.

С другой стороны, двойная труба отлично работает прямо в корпусе.

Так мне кажется || не работает только в работе cron.

Не могли бы вы помочь мне понять, почему?

Спасибо!

2 ответа2

1

Я думаю, что здесь не причина, почему это не работает.

двойная труба "||" является логическим оператором ИЛИ в выражении оболочки.

Ваша команда примерно такая:

cmd_group_1 && cmd_group_2 && cmd_group_3 || cmd_group_4

Например:
A)

  1. * cmd_group_1 * сбой выполнения -> тогда код выхода не будет равен нулю
  2. * cmd_group_4 * будет выполнен

B)

  1. * cmd_group_1 *, * cmd_group_2 *, * cmd_group3 * проход выполнения
  2. * cmd_group_4 * НЕ будет выполнен

РЕДАКТИРОВАТЬ:
Я тестирую нижеупомянутую запись в crontab в cron, и она работает: * * * * * aaa || echo "hello" >>/tmp/test aaa - несуществующая команда, так что это не получится, и привет будет записан в /tmp /test

-1

@Period заменяет дату и время; ИМХО cron должен выдавать ошибку в системном журнале о "." будучи недопустимым пользователем. Если это уже не пользовательский crontab.

Ваш вопрос не дает никаких подробностей о контексте:- дистрибуция - версия - где хранится этот cron (путь важен для некоторых аспектов)- имя файла (имя также критично)- файл cron conf

В частности, в предоставленной вами выдержке не указывается используемая оболочка; и вы загружаете файл bashrc, в то время как bash почти никогда не используется оболочкой. Таким образом, в зависимости от содержимого вашего файла bashrc, поведение уже непредсказуемо на уровне попытки выполнить точку.

В зависимости от оболочки && может не поддерживаться.

О том, что последняя часть вашей строки никогда не интерпретируется, возможно, потому, что она никогда не читается оболочкой. Факт в том, что большинство реализаций cron имеют максимальную длину; и любой байт после этого предела просто игнорируется. Этот предел может варьироваться в зависимости от реализации между 128 и 1024 байтами, что я встречал. Наиболее частые значения - 192 и 256. И, конечно же, cron не сообщает об этой проблеме в системных журналах (даже при перезагрузке).

Поскольку вы не предоставляете никакого контекста, вы должны самостоятельно прочитать справочную страницу, в зависимости от вашего дистрибутива, вашей версии и используемого пакета cron.

Я знаю, что на самом деле не отвечаю на вопрос, потому что поставленный вопрос неоднозначен и не может получить ответ.

Вы можете проверить глобальный синтаксис с помощью более короткой строки, например:

* * * * * root /bin/true && echo true || echo false
* * * * * root /bin/false && echo true || echo false

затем поместите ваш код в сценарий (я помещаю пользовательские сценарии в ~/ .sh/, а системные в / usr / local / bin для доступных пользователю сценариев и / usr / local / sbin для недоступных для пользователей)

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .