Задание крона перестало работать тихо
Вы уже выполнили шаги, перечисленные на opensuse веб-сайте? Это должно определенно работать.
Существует довольно хорошее объяснение в Прохладных Решениях также
Обычная проблема с заданиями 'крона' состоит в том, что у них есть нулевая среда - в отличие от этого, 'в' заданиях, которые действительно копируют Вашу среду. Когда что-то работает из командной строки а не из 'крона', мой опыт состоит в том, что 'среда' является одной из наиболее распространенных проблем. Иногда Вы сталкиваетесь с другой проблемой - задания 'крона' не выполняются с терминалом, и иногда программы получают stroppy об этом. Однако это находится в 1%-м диапазоне по сравнению с 99% для проблем среды.
Другая ключевая техника, которую я использую, состоит в том, чтобы всегда выполнять сценарий оболочки от 'крона'; сценарий оболочки гарантирует, что среда установлена правильно и затем запускает реальную программу. Если задание 'крона' дает мне проблемы, я могу затем настроить сценарий, чтобы сделать полезные вещи как это:
{
date
env | sort
set -x
...what was there before adding the debug...
} >/tmp/cron.jobname.$$ 2>&1
Это перенаправляет весь вывод - стандартный вывод и стандартную погрешность - к имени файла. Можно встроить метки времени в имя файла, если Вы предпочитаете это идентификатору процесса. Анализ файлов журнала часто показывает проблемы быстро.
-
1Проблема была среда. Часть моего сценария полагалась на путь относительно текущего рабочего каталога. Когда выполнено как автономный сценарий из командной строки, этого wasn' t проблема, но cron' s текущий рабочий dir был мой корневой каталог (это было моим пользователем crontab). Фиксация сценария для разработки правильного пути решила мою проблему. – saturdayplace 27 October 2009 в 21:00
Во-первых, просто проверьте, что crond работает.
Когда cronjobs, которые работают над командной строкой, не удается работать как ожидалось, это обычно - проблема среды для меня - помнят, что cronjob не будет работать как интерактивная оболочка.
От Вашей командной строки, выполненный ENV (1) и копируют их где-нибудь. Затем, измените свой cronjob для выполнения ENV, таким образом, можно сравнить значения. Крон должен послать Вам по электронной почте вывод (Вы сказали, что это было прежде); HD упомянул, как настроить это.
5,20,35,50 * * * * env; /var/www/django-apps/callreport/util.py
Это некоторые идеи для поиска и устранения неисправностей Вашей проблемы:
- Проверьте свои системные журналы, чтобы видеть, запускает ли демон крона на самом деле сценарий
- Если Ваши задания не регистрируются, попытайтесь увеличить регистрирующийся уровень так, чтобы Вы это
cronрегистрирует запуск каждого задания (см.man cron). Например, при выполнении демона крона Vixie это может быть сделано путем определения-L 1опция (или-L 2если Вы также хотите проверить, когда Ваше задание заканчивается). - Из Вашего сценария Python, как только это запускается, создают пустой файл на/tmp каталоге (это - другой способ помочь Вам проверить, что сценарий называет крон, и это запускается без проблем),
Python whereis
вывод должен быть...
/usr/bin/python
затем полный путь к Python перед сценарием.
5,20,35,50 * * * */usr/bin/python/var/www/django-apps/callreport/util.py
-
1Да. Python мог быть указан в Вашей среде через Ваше дистанционное управление. Абсолютное объявление как egorgy говорит, или объявление полного пути в Вашем сценарии может помочь. – physicsmichael 7 September 2009 в 02:56
Я думаю, что можно перенаправить вывод команды в файл для наблюдения, почему это перестало работать, что-то как
/var/www/django-apps/callreport/util.py > /tmp/util_log.txt
большинство случаев, которые я видел тихий отказ, - то, потому что сценарий не мог быть выполнен и не проблема с самим сценарием
-
1Перенаправление вывода ничего не сделало; didn' t даже генерируют файл журнала. Кажется что мое задание крона isn' t работающий вообще. – saturdayplace 18 August 2009 в 19:41
Можно поместить эту строку наверху crontab:
MAILTO="user@domain.com"
Получить почту от крона. Также можно перенаправить вывод к временному сбою, как Dinesh Manne заявляет для проверки то, что произошло с командой. Просто выяснение: действительно ли Вы уверены, что используете пользователя, который работает, команда совпадает с владельцем crontab, который Вы редактируете?
-
1добавленный строка MAILTO, но полученный ничто. И I' m уверенный, что принадлежность файла / полномочия соответствует владельцу crontab. – saturdayplace 18 August 2009 в 19:58
Это кажется, что Вы уже проверили, но двойная проверка, чтобы скрипт был запущен как корректный пользователь. Когда я диагностирую задания крона, мне нравится использовать (на моем Mac) системные вызовы с помощью say управляйте так, чтобы я услышал параметры, которыми я интересуюсь. Таким образом, я мог бы добавить к util.py следующее:
import os
os.system('whoami')
Кроме этого, я поместил свои деньги по проблеме разрешения; Ваше задание крона не может делать вещи, которые Вы спрашиваете, потому что полномочия не позволяют ему.
Вынудите это отказать. Поместите что-то не так вместо #!/usr/bin/python и проверьте, получаете ли Вы сообщение об ошибке по электронной почте - необходимо установить переменную MAILTO на адрес электронной почты. Но проверьте сначала, перестали ли сценарии действительно работать при выполнении его из командной строки. Если Вы все еще не добираетесь, почтовая ошибка проверяют, являются ли некоторые электронные письма stucked в очереди местной почты (mailq). Возможно, это поможет выяснению о тихом отказе.
Кроме того, на каких внутренних системах делает этот сценарий, зависит? DNS, ldap/nis? Это имеет какие-либо hardcoded IP-адреса или имена хостов, который больше не существует (т.е. хост mysql)? Можно ли коррелировать в прошлый раз его, succefully работал с последним изменением, сделанным к сценарию? Кто-то хитрость обновляла до Python на Вашей машине? У Вас есть достаточное дисковое пространство и indoes (df-i)?
У Вас есть пустая строка в конце Вас crontab файлом? Если Вы вынуждаете сценарий работать как корень (плохо, используйте его только для тестирования), он работает?
У Вас есть это задание в crontab пользователя (Можно ли видеть его с crontab -l?) или это в системе crontab (/etc/crontab)? Система crontab (На Linux, по крайней мере, не знайте о других системах), требует дополнительного пользовательского аргумента, что пользователь crontabs не делает.
В пользователе определенный crontab это должно быть похожим:
# crontab -l
...
5,20,35,50 * * * * /var/www/django-apps/callreport/util.py
Принимая во внимание, что та же команда в системе crontab должна быть похожей:
# cat /etc/crontab
...
5,20,35,50 * * * * www-data /var/www/django-apps/callreport/util.py
Пользователь мог бы отличаться в Вашей системе, конечно, но это - общее представление.
-
1