Проверить cron на ошибки

Cron — это демон, который запускает задачи по указанному (заданному) времени и  который работает в наиболее распространенных дистрибутивах Unix / Linux. Поскольку cronjobs основаны на времени, иногда необходимо проверить и убедиться, что задание выполнялось в запланированное время. Иногда люди настраивают cron чтобы они отправляли вывод скрипта через системную почту или перенаправляюте вывод в файл; однако не все кроны настроены одинаково, и мние из них, могут быть настроены на отправку вывода в /dev/null, и тем самым, препятствуя любой возможности проверить выполняемое задание.

Создать cron задание

Первое что стоит проверить — это наличие ПИДа по крону:

# pgrep crond

Или:

# ps ax | grep crond | grep -Ev grep

crond, если он не настроен иначе, будет отправлять сообщение журнала в syslog каждый раз, когда он вызывает запланированное задание. Самый простой способ проверить работу cron на попытку срабатываания задание, — это проверить лог-файл.

В зависимости от Unix/Linux ОС, данный файл может иметь другое название.

Если у вас, CentOS/Fedora/RedHat, то просмотреть нужно:

# less /var/log/cron

Можно отсеять ненужное и поискать только необходимую крон-джобу, например:

# cat /var/log/cron| grep -E "back"

Nov 28 00:00:01 linux-notes CROND[212211]: (root) CMD (/usr/bin/bash /home/linux/scripts/backUPs.sh)
Dec 1 00:00:01 linux-notes CROND[126039]: (root) CMD (/usr/bin/bash /home/linux/scripts/backUPs.sh)

Собственно, все наглядно видно.

Если у вас, Ubuntu/Debian, то просмотреть нужно:

# less /var/log/syslog

Иногда, системные администраторы меняют вывод крона и для того, чтобы проверить куда пишуться логи по cron-job-ам, выполните:

# grep cron /etc/rsyslog.conf

*.info;mail.none;authpriv.none;cron.none                /var/log/messages
# Log cron stuff
cron.*                                                  /var/log/cron

С вывода видно, что у меня используется стандартный файл.

Так же, стоит проверить как настраивали крон-джобы:

# crontab -l

ИЛИ:

# crontab -l -u some_another_user

Возможно было перенаправление вывода в какой-то файл для дальнейшего анализа.

Стоит отметить, то — что некоторые кроны лежат тут:

# ls -lah /etc/cron.daily/
# ls -lah /etc/cron.hourly/
# ls -lah /etc/cron.weekly/
# ls -lah /etc/cron.monthly/

Бывает некоторые задачи запихивают туда.

Чтобы запретить или разрешить добавление крон-задат, нужно прописать юзера в:

# vim /etc/cron.d/cron.allow
# vim /etc/cron.d/cron.deny

Так же, можно восспользоватся следующими командами для проверки статуса, запуска/остановки/перезапуска службы:

# service cron status 
# service cron start 
# service cron stop
# service cron restart

Это все действия были для Linux, но сейчас приведу пример и для mac os x.

Недавно мне пришлось отлаживать работу Cron и проверять, действительно ли она выполняется по заданному расписанию. Я начал искать и проверять все логи и… нашел вроде бы подходящий файл для этого:

# grep cron /var/log/system.log

Но в нем не было признаков логирования крона!

Включить logging для Cron в Mac OSX

Открываем:

# vim /etc/syslog.conf

И прописываем:

cron.* /var/log/cron.log

Для перезапуска syslog-а, выполняем:

# launchctl unload /System/Library/LaunchDaemons/com.apple.syslogd.plist
# launchctl load /System/Library/LaunchDaemons/com.apple.syslogd.plist

Проверяем что получилось!

А для помощи, можно вызвать:

# man crontab

А на этом, у меня все, статья «Проверка работы cron в Unix/Linux» завершена.

Где хранится информация о запуске заданий по расписанию? Для проверки используем Ubuntu Linux 12.04/14.04 LTS сервер. Как проверит, запущен ли cron и правильно ли он работает?

Как проверить запущен ли cron (планировщик заданий)? Используйте команду pgrep  или ps

Результат

Так же вы можете проверить файл /var/log/syslog используя команду grep что бы получить информации о работе планировщика cron

Результат:

Где хранятся журналы работы cron на Ubuntu Linux?

Журналы хранятся в файле /var/log/cron.log. Вы можете настроить его следующим образом. Редактировать /etc/rsyslog.d/50-default.conf файл с помощью текстового редактора, например, vi или nano:

или

Найдите строку

Необходимо её раскомментировать, и перезапустить оба сервиса:

Теперь все сообщения об ошибках в работе планировщика можно будет просматривать в файле

Воспользуйтесь различными командами для поиска нужной информации в логе

 Предоставляем уcлуги администрирования серверов Linux Ububtu

Нет похожих статей.

Несколько слов, как настроить и проверить задачу CRON. Данная заметка относится как к Первой Ветке, так и Второй.

О задаче cron.

Решил написать эту заметку, чтобы не потерялась информация.
Как известно, на Инстанте можно запустить задачу cron, начиная с версии 1.7 (если правильно помню). Задача запускается с сервера и может быть выполнена, даже если никого на сайте нет.

Как задача выполняется.

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

Другими словами, если вы собираетесь организовать выполнение на своем сайте какого-то своего скрипта по расписанию, вы должны настроить две независимые вещи:
1. Планировщик заданий на хостинге.
2. Задачу CRON на Инстанте.

Обычно мы настраиваем Планировщик так, чтобы указать путь к нашему инстантовскому скрипту cron.php (есть и на Первой и на Второй ветках), который лежит в корне сайта. Однако мы можем прописать Планировщику любой скрипт.

Настройки

Настройка Планировщика заданий на хостинге

Это самая муторная часть настроек задачи cron. Почему? Потому что на каждом хостинге «свои игрушки» — совершенно разные способы запуска скриптов и разные пути к интерпретатору php и разные пути к вашему сайту.

Если вы неправильно пропишите это задание для Планировщика — вы будете долго ломать голову, из-за чего возникли траблы и на каком этапе.

Поэтому рекомендую не кичиться своей квалификацией программиста и сайтоваятеля. Смело пишите в саппорт хостинга. Попросите их прислать пример строки для Планировщика заданий. В ответ они вам пришлют либо такую строку

* * * * * /usr/local/bin/php -n /home/user/html/cron.php

либо такую

wget -O - -q -t 1 http://ваш_сайт.ru/cron.php

либо такую

@daily php -f /var/www/user_name/data/www/ваш_сайт.ru/cron.php http://ваш_сайт.ru >/dev/null 2>&1

Все строки рабочие, только с разных хостингов. Совершенно не похожи между собой, правда? Именно поэтому не старайтесь скопировать эту строку с одного хостинга на другой, чтобы потом не удивляться, почему CRON не работает. В примерах Планировщика задач обычно есть справка. Те справки, что я до сих пор читал, были написаны на марсианском языке. Иногда буквы русские, но язык все равно марсианский. Поэтому не ковыряйтесь в дурацких справках, а сразу пишите в саппорт!

По виду строки для Планировщика (в ответе из саппорта) можно догадаться, как именно будет запускаться ваша задача cron. Если используется не cli, а wget или cURL, вам придется открыть наш инстантовский файл cron.php любым редактором и закомментировать строку

if(PHP_SAPI != 'cli') die('Access denied');

Если этого не сделать, задача cron не сработает, даже если Планировщик настроен правильно. (Говорю для тех, кто в танке: закомментировать строку означает поставить перед ней // — две косые черты, или слэша)

Предопределенная константа PHP_SAPI объявляется ядром php на хостинге вместе с другими константами. О том, как узнать ее значение, чуть ниже.

Немного справочной информации

CLI — Command line interface, интерфейс командной строки. Рассмотрим пример, относящийся к cli.
Еще раз посмотрите на строку

* * * * * /usr/local/bin/php -n /home/user/html/cron.php

Эта строка конфигурации /etc/crontab. Строка состоит из имени команды, необязательных ключей и необязательных параметров. Если есть ключи и/или параметры, они отделяются от команды и друг друга обязательными пробелами.

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

Далее через пробел идет путь к интерпретатору php. Это очень важный параметр. Если вы указали путь неправильно — ваша задача cron не сработает. Именно этот путь вам и надо «выжать» из Вашего саппорта. Потому что практика показывает, что люди, сидящие в саппорте, часто сами не знают этого пути. Они пишут в ответ всякую фигню. Просите их пригласить к разговору человека квалифицированного. Обычно это админ сервера. Только когда к переписке подключится админ сервера, только тогда вы получите нужные сведения.

После параметра «путь» через пробел стоит ключ -n, который отключает запуск ionCube. Если ваш запускаемый скрипт зашифрован ionCube, этот ключ следует убрать. Как получить описания ключей? У себя дома (на Денвере) я нашел перечень этих ключей (их двенадцать) с описаниями на английском, набрав в командной строке z:usrbinphp.exe -h

Для тех, кто в танке, подсказываю, что в Винде командная строка вызывается cmd.exe, будучи набранной в поле «Выполнить» (для ХР), и в поле «Найти программы» (для Семерки). Поле «Выполнить/Найти» можно открыть в любой Винде, нажав комбинацию клавиш «Win+R». У кого вместо Денвера стоит Open Server, предупреждаю, что файл php.exe может находиться и по другому адресу (в этом случае юзайте поиск).

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

WGET — википедия вещает нам, что это свободная неинтерактивная консольная программа для загрузки файлов по сети. Вот почему во втором примере в качестве параметра указано сетевое имя вашего сайта с протоколом http:// Эта программа также поддерживает протоколы https:// и ftp://
Там же, в википедии, я нашел несколько примеров ключей.

cURL — хорошая альтернатива wget. Делает все тоже самое, что делает wget, плюс еще много чего. Смотрите википедию.

Если саппорта нет (или он несет фигню)

Но как быть, если строка Планировщика не работает, а саппорт высокомерно молчит? Или дятлы, засевшие в саппорте деревянного хостинга, несут ахинею? Например, направляют вас на тот самый FAQ (на марсианском языке), который вы уже и так вдоль и поперек изучили?

Поневоле приходится справляться самому.

Здесь приведен способ самостоятельно узнать, правильно ли Вы настроили Планировщик.

1. В корне сайта создайте два файла:
my_cron.txt с правами 777.
my_cron.php с правами 755 или 751

Первый файл my_cron.txt (это наш лог, куда скрипт будет писать сообщения) оставьте пустым.
Второй файл my_cron.php откройте в редакторе и впишите примерно такой текст:

<?php 
$fd = fopen("/home/user/mysite_ru/my_cron.txt","a"); 
fwrite($fd, "Обращение к файлу - ".date("d.m.Y H:i")."rn"); 



  


                       
  



?>

Как Вы уже поняли, команда fopen(‘path_to_log’) содержит путь к логу. Часто этот путь следует указывать от корня хостинга (а не корня сайта). Естественно, на каждом хостинге (и для каждого Вашего сайта, если их несколько) этот путь будет различным.

2. Начинаем эксперименты. В Панели управления хостинга ищите Планировщик заданий (он может называться по разному). Настраиваете Планировщик заданий. Как правило, для этого в него надо добавить строку, которую вы составили по примерам, приведенным в FAQ вашего хостинга.
Например:

* * * * * /usr/local/bin/php -n /home/user/html/my_cron.php

Некоторые Панели управления хостингом (например, ISP) содержат кнопку для задачи cron «Запустить задачу». Если кнопки «Запустить задачу» нет, пропускаете пункт 2.1. Сразу переходите к п.3.

2.1.Если кнопка есть, нажмите на нее. Если вернулась белая страница, без всяких ответов, порадуйтесь первой победе и переходите к п.3. Если при нажатии на кнопку «Запустить задачу» появляется короткая строка вроде

Exited with return code = 123

значит, вернуло ошибку с кодом 123 и Планировщик не работает. Нет смысла двигаться дальше, пока есть ошибка. По коду можно узнать, что пошло не так: пишите этот код саппорту.

3. Настроив Планировщик, идите перекусите. Чаю попейте.

4. Попив чаю, заглядываете в файл my_cron.txt. Если Планировщик сработал, он запустит на выполнение Ваш скрипт my_cron.php.
Приведенный выше пример запускает скрипт my_cron.php каждую минуту. Он пишет в лог my_cron.txt строчки вроде

Обращение к файлу - 11.01.2014 22:13
Обращение к файлу - 11.01.2014 22:14
Обращение к файлу - 11.01.2014 22:15
Обращение к файлу - 11.01.2014 22:16
Обращение к файлу - 11.01.2014 22:17

Если видите аналогичные строчки, радуйтесь — Планировщик работает. Первая часть задачи выполнена.

Если лог пуст — значит Планировщик не работает. Вернитесь к п.2. Экспериментируйте с путями. Возможно, неправильно прописаны пути к интерпретатору php или вашему скрипту. Как их узнать? Узнать этот путь можно из phpinfo(). Для этого идите в админку Настройки -> Информация PHP.

Только когда в логе что-то появилось, имеет смысл двигаться дальше.

5. Остальное дело техники.

5.1. Следует удалить файлы my_cron.txt и my_cron.php, из корня сайта, чтобы они не лежали там в виде мусора.

5.2. Затем отредактируйте командную строку Планировщика, чтобы вместо нашего тестового скрипта my_cron.php был прописан скрипт Инстанта cron.php.

5.3. Скорее всего, придется еще перенастроить время срабатывания Планировщика.

Звездочки, которые мы видим, обозначают:
Минуты Часы Дни_месяца Месяц День_недели

Вместо звездочек можно ставить точные цифровые значения, диапазон или перечень. Диапазон указывается через дефис (например, 1-4 означает 1,2,3,4), перечень указывается через запятую, например, 1,2,3,4)

Примеры настроек временных интервалов Планировщика
каждый час (точнее, каждую нулевую минуту, которая раз в час бывает):

0 * * * * /usr/local/bin/php -n /home/user/html/cron.php

или
каждые полчаса (точнее, каждую нулевую и тридцатую минуту):

0, 30 * * * * /usr/local/bin/php -n /home/user/html/cron.php

или
каждый день (точнее, каждый нулевой час, сиречь полночь):

* 0 * * * /usr/local/bin/php -n /home/user/html/cron.php



  


                       
  

или
каждый день в 8:15 утра:

15 8 * * * /usr/local/bin/php -n /home/user/html/cron.php

или
каждое воскресенье в 12:00

00 12 * * 7 wget http://site_name.com/test-cron.php

и так далее. Думаю, теперь понятно.

Иногда вместо звездочек для каждого часа следует прописывать @hourly, каждый день — @daily и так далее. Я же говорю — не пытайтесь угадать, как должна выглядеть правильная строка планировщика, а сразу пишите в саппорт!

Только после того, как Планировщик задач на хостинге заработал и Вы его настроили, можно перейти к следующей части — настройки CRON на Инстанте.

Если задача CRON движка все равно не запускается

Иногда бывает, что Планировщик на хостинге срабатывает, наш тестовый скрипт my_cron.php успешно пишет в лог, а задача cron все равно не выполняется. И Первая и Вторая ветки в корнях содержат файл cron.php. Одна из первых строчек этого файла выглядит так:

if(PHP_SAPI != 'cli') { die('Access denied'); }

Как мы видим здесь проверяется значение предопределенной константы PHP_SAPI. Эта константа объявляется самим ядром PHP на хостинге и переопределить мы ее не можем. Зато можем узнать ее значение. Это можно сделать несколькими способами. Выбирайте любой, какой вам больше нравится.

Как узнать значение PHP_SAPI

1. Записать в лог. Аналогично, как мы делали выше, но в в файл my_cron.php добавляем строчку

fwrite($fd, 'PHP_SAPI = '.PHP_SAPI."rn");

2. Вывести в браузер. В любом месте файла index.php (как Первой, так и Второй ветки, находится в корне) добавляем строчку

echo 'PHP_SAPI = '; print_r(PHP_SAPI);

На одном из хостингов, где я держу один из своих сайтов мне вывело, например:
PHP_SAPI = cgi-fcgi
Поскольку задачу крон на этом сайте мне запускать не надо, то и фиг с ним.

Но если надо, нужно:
— либо выкручивать руки хостеру, чтобы сконфигурировал вам ядро PHP вместе с cli,
— либо закоментировать строчку

if(PHP_SAPI != 'cli') { die('Access denied'); }

что крайне не рекомендуется

Некоторые продвинутые хостинги позволяют юзеру самому сконфигурировать себе ядро PHP, выставляя галки напротив соответствующих модулей в Панели управления аккаунтом. Кроме cli можно включить, например, mb_string, IonCube и другие примочки, без которых наш Инстант не сможет работать полноценно.

Задача CRON на InstantCMS 1.х.х

Теперь, когда вы уверены, что Планировщик работает, останется:
— создать задачу CRON InstantCMS и
— написать скрипт, который будет выполняться на сайте от задачи CRON нашего движка.

Создание скрипта — задачи cron для Инстанта Первой ветки

Начнем со скрипта. Откройте папку(в Первой ветке это includes/myphp/), где уже лежит файл, поставляемый вместе с движком — includes/myphp/test.php. Напишите скрипт с именем my_cron.php (или любым другим, исходя из своей задачи, здесь my_cron.php для примера) и положите его рядом с test.php. Содержание этого файла пропишите таким:

<?php 
$fd = fopen("my_cron.txt","a"); 
fwrite($fd, "Обращение к файлу - ".date("d.m.Y H:i")."rn"); 
?>

Обратите внимание, что здесь путь не указан. Это сделано намерено. Параметр «а» в команде fopen() автоматически создает файл, если его нет. Этим можно воспользоваться для наших целей. В зависимости от настроек хостинга файл автоматически создастся либо в корне сайта, либо в той папке, где лежит файл my_cron.php.

Если файл НЕ создался, надо искать причину.

Подсказка, как проверить задачу CRON движка без Планировщика

Проверить связку my_cron.php — my_cron.txt можно очень быстро и очень просто, даже не используя CRON.
Воспользуемся фильтрами Инстанта.

Возьмите любую статью и откройте ее на редактирование. В ней в любом месте вставьте запускающую конструкцию фильтра: {ФАЙЛ=my_cron.php}. Сохраните статью.

Стоит вам открыть эту статью для чтения, фильтр сработает. Он запустит includes/myphp/my_cron.php, а тот пропишет в my_cron.txt строчку

Обращение к файлу - 11.01.2014 22:14...

и так далее.

Если НЕ сработало:
— разбирайтесь с путями
— возможно, потребуется изменить cmod папки, где должен создаться файл.

Убедившись, что связка my_cron.php + my_cron.txt работает, можете удалить файл my_cron.txt, а my_cron.php переименовать сообразно Вашей задачи. Не забудьте из статьи удалить фильтр.
Открывайте свой будущий скрипт редактором и творите. Тут все зависит от вашего мастерства программиста.

Добавление задач

Теперь создаем задачу cron САМОГО Инстанта. Идем в админку, Настройки->Задачи CRON. Нажимаем зеленый плюсик. В открывшейся форме отвечаем на простые вопросы, а в поле Скрипт прописываем путь к нашему скрипту и его имя. Остальные поля оставляем незаполненными — они нам пока не нужны.

Наш скрипт должен работать.

Немного о том, как работает задача cron на Инстанте

Наш скрипт cron.php инициализирует ядро и все ядерные классы. Затем загружает из БД перечень задач CRON. Получается массив, каждый элемент которого — задача CRON. Файл cron.php перебирает массив, поэтому эти эти задачи последовательно выполняются.

Все задачи хранятся в БД в таблице cms_cron_jobs. Каждая запись — это отдельная задача.

Использование ядерных методов движка при запуске задачи CRON на Первой ветке.

Если вы зашли в админке в задачу cron, то можете увидеть поля для запуска некоторых ядерных методов движка.

Следует отметить, что далеко не все методы ядра могут быть выполнены таким образом. Например метод getHost() может быть вызван из командной строки сервера (читай, по команде Планировщика), поскольку имеет код, позволяющий обработать данные, полученные с сервера. А вот, к примеру, метод checkMenuAccess() у вас не сработает, поскольку работает с сессией. А какая сессия, если скрипт запускается не от браузера-клиента, а прямо с сервака? Суперглобальный массив $_SERVER не определен. Переменные окружения вообще не определены. Сессия не запущена.

Помните, прописывая в задачу cron методы ядра на исполнение, вы можете получить их неисполнение. Аналогично, если вы указали подходящий вам метод из модели компонента, понадеявшись, что он сработает по задаче cron и вернет данные, будте готовы испить горькую чашу разочарования. Здесь Вам не обойтись без досконального знания не только самого нашего InstantCMS, но и CGI.

Задача CRON на InstantCMS 2.х.х

Теперь, когда вы уверены, что Планировщик работает, останется создать задачу CRON InstantCMS 2.

1. Пишем скрипт. Скрипт должен находиться в папке system/controllers/имя_вашего _компонента/hooks/. Имя скрипту даете сами, но он должен обязательно начинаться на cron_: например, cron_my_script.php.

2. Идем в админку Панель управления -> Настройки -> Планировщик.

Нажмите зеленый плюсик и заполните поля.
— Поле «Описание». Сюда можете написать любой текст.
— Поле «Компонент». Укажите системное имя компонента. Если свой пишите, сюда добавьте имя своего компонента.
— Поле «Хук». Укажите имя скрипта (хука) — того самого, который вы создали немного раньше. В поле надо вписывать НЕ полное имя скрипта, а с отброшенным префиксом cron_. То есть для скрипта с именем cron_my_script.php вы указываете имя хука my_script.php.
— Поле «Период». Укажите период в минутах.
— Галка «Задача активна» Поставьте галку если хотите, чтобы задача была включена.

Как быть, если в скриптах, которые Вы написали, орфографические ошибки?

Никто из нас не безгрешен. Программируя, я всегда включаю вывод ошибок в браузер. Их видно моментально. Но куда выводить ошибки, которые возникли в скриптах, запущенных от Планировщика заданий? Ведь скрипты срабатывают не по запросу браузера!

Для этого на многих хостингах предусмотрена такая фича: все сообщения отправляются на чей-нибудь почтовый ящик. Обязательно укажите свой ящик в настройках Планировщика. Тогда Вы будете получать от него сообщения интерпретатора php. Те самые, которые он, в случае обнаружения ошибки, отправляет в браузер.

Правда, эта штука будет забивать вам ящик и при успешном срабатывании задачи cron, сообщениями вроде:

X-Powered-By: PHP/5.3.29
Content-type: text/html

Чтобы этого не происходило, добавьте в конец строки Планировщика на хостинге, через пробел, команду >/dev/null 2>&1.
Например:

* * * * * /usr/local/bin/php -n /home/user/html/my_cron.php >/dev/null 2>&1

Точный вид команды узнайте у саппорта своего хостинга.

.

P.S. Я тут на днях порезвился и написал такой скрипт — у меня работает)))

Куда говорить «спасибо» за статью

яд 410011913797936

The cron job scheduler has been bundled with unix and linux operating systems for decades. It’s widely used and usually very reliable.
This guide will walk you through locating cron jobs on your server, validating their schedules, and debugging common problems.

In this guide

1. The common reasons cron jobs fail
2. What to do if your cron job isn’t running when expected
3. What to do if your cron job fails unexpectedly
4. What to do if nothing else works

The common reasons cron jobs fail

Cron jobs can fail for an infinite variety of reasons but at Cronitor we have observed common failure patterns that
can provide a useful starting point for your debugging process. In the rest of this guide, we will dive into these
common failures with suggestions and solutions.

If you’re adding a new cron job and it is not working…

• Schedule errors are easy to make

  Cron job schedule expressions are quirky and difficult to write. If your job didn’t run when you expected it to,
  the easiest thing to rule out is a mistake with the cron expression.

• Cron has subtle environment differences

  A common experience is to have a job that works flawlessly when run at the command line but fails whenever
  it’s run by cron. When this happens, eliminate these common failures:

  1. The command has an unresovable relative path like ../scripts. (Try an absolute path)
  2. The job uses environment variables. (Cron does not load .bashrc and similar files)
  3. The command uses advanced bash features (cron uses /bin/sh by default)

  Tip:Our free software, CronitorCLI, includes a shell command to test run any job the way cron does.

• There is a problem with permissions

  Invalid permissions can cause your cron jobs to fail in at least 3 ways. This guide will cover them all.

If your cron job stopped working suddenly…

• System resources have been depleted

  The most stable cron job is no match for a disk that is full or an OS that can’t spawn new threads. Check all the usual graphs to rule this out.

• You’ve reached an inflection point

  Cron jobs are often used for batch processing and other data-intensive tasks that can reveal the constraints of your stack. Jobs often work fine until your data size grows to a point where
  queries start timing-out or file transfers are too slow.

• Infrastructure drift occurs

  When app configuration and code changes are deployed it can be easy to overlook the cron jobs on each server. This causes infrastructure drift where hosts are retired or credentials change that break the forgotten cron jobs.

• Jobs have begun to overlap themselves

  Cron is a very simple scheduler that starts a job at the scheduled time, even if the previous invocation is still running. A small slow-down can lead to a pile-up of overlapped jobs sucking up available resources.

• A bug has been introduced

  Sometimes a failure has nothing to do with cron. It can be difficult to thoroughly test cron jobs in a development environment and a bug might exist only in production.

What to do if your cron job doesn’t run when expected

You may find that you have scheduled a cron job that is just not running when expected. Follow these steps to locate your scheduled job and diagnose the problem.

1. Locate the scheduled job

   Tip:If you know where your job is scheduled, skip this step

   Cron jobs are run by a system daemon called crond that watches several locations for scheduled jobs. The first step to understanding why your job didn’t start when expected
   is to find where your job is scheduled.

   Search manually for cron jobs on your server

   • Check your user crontab with crontab -l

     dev01: ~ $ crontab -l
     # Edit this file to introduce tasks to be run by cron.
     # m h  dom mon dow   command
     5 4 * * *      /var/cronitor/bin/database-backup.sh

   • Jobs are commonly created by adding a crontab file in /etc/cron.d/
   • System-level cron jobs can also be added as a line in /etc/crontab
   • Sometimes for easy scheduling, jobs are added to /etc/cron.hourly/, /etc/cron.daily/, /etc/cron.weekly/
     or /etc/cron.monthly/
   • It’s possible that the job was created in the crontab of another user. Go through each user’s crontab using crontab -u username -l

   Or, scan for cron jobs automatically with CronitorCLI

   • Install CronitorCLI for free

   • Run cronitor list to scan your system for cron jobs:
     

     

   If you can’t find your job but believe it was previously scheduled double check that you are on the correct server.

2. Validate your job schedule

   Once you have found your job, verify that it’s scheduled correctly. Cron schedules are commonly used because they are expressive and powerful, but like regular expressions can sometimes be difficult to read.
   We suggest using Crontab Guru to validate your schedule.

   • Paste the schedule expression from your crontab into the text field on Crontab Guru
   • Verify that the plaintext translation of your schedule is correct, and that the next scheduled execution times match your expectations
   • Check that the effective server timezone matches your expectation. In addition to checking system time using date,
     check your crontab file for TZ or CRON_TZ timezone declarations that would override system settings.
     For example, CRON_TZ=America/New_York

3. Check your permissions

   Invalid permissions can cause your cron jobs to fail in at least 3 ways:

   1. Jobs added as files in a /etc/cron.*/ directory must be owned by root. Files owned by other users will be ignored and you may see a message similar to
      WRONG FILE OWNER in your syslog.
   2. The command must be executable by the user that cron is running your job as. For example if your ubuntu user crontab invokes a script like
      database-backup.sh, ubuntu must have permission to execute the script. The most direct way is to ensure that the ubuntu
      user owns the file and then ensure execute permissions are available using chmod +x database-backup.sh.
   3. The user account must be allowed to use cron. First, if a /etc/cron.allow file exists, the user must be listed. Separately,
      the user cannot be in a /etc/cron.deny list.

   Related to the permissions problem, ensure that if your command string contains a % that it is escaped with a backslash.

4. Check that your cron job is running by finding the attempted execution in syslog

   When cron attempts to run a command, it logs it in syslog.
   By grepping syslog for the name of the command you found in a crontab file you can validate that your job is scheduled correctly and cron is running.

   • Begin by grepping for the command in /var/log/syslog (You will probably need root or sudo access.)

     dev01: ~ $ grep database-backup.sh /var/log/syslog
     Aug  5 4:05:01 dev01 CRON[2128]: (ubuntu) CMD (/var/cronitor/bin/database-backup.sh)

   • If you can’t find your command in the syslog it could be that the log has been rotated or cleared since your job ran. If possible, rule that out by updating the job to run every minute by changing its schedule to * * * * *.
   • If your command doesn’t appear as an entry in syslog within 2 minutes the problem could be with the underlying cron daemon known as crond. Rule this out quickly by verifying that cron is running by looking up its process ID. If cron is not running no process ID will be returned.

     dev01: ~ $ pgrep cron
     323

   • If you’ve located your job in a crontab file but persistently cannot find it referenced in syslog, double check that crond has correctly loaded your crontab file. The easiest way to do this is to force
     a reparse of your crontab by running EDITOR=true crontab -e from your command prompt. If everything is up to date you will see a message like No modification made. Any other
     message indicates that your crontab file was not reloaded after a previous update but has now been updated. This will also ensure that your crontab file is free of syntax errors.

If you can see in syslog that your job was scheduled and attempted to run correctly but still did not produce the expected result you can assume there is a problem with the command you are trying to run.

What to do if your cron job fails unexpectedly

Your cron jobs, like every other part of your system, will eventually fail. This section will walk you through testing your job and spotting common failures.

1. Test run your command like cron does

   When cron runs your command the environment is different from your normal command prompt in subtle but important ways. The first step to troubleshooting is to simulate the cron environment and
   run your command in an interactive shell.

   Run any command like cron does with CronitorCLI

   • Install CronitorCLI for free

   • To force a scheduled cron job to run immediately, use cronitor select to scan your system and present a list of jobs to choose from.
   • To simulate running any command the way cron does, use cronitor shell:
     

     

   Or, manually test run a command like cron does

   • If you are parsing a file in /etc/cron.d/ or /etc/crontab each line is allowed to have an effective «run as» username
     after the schedule and before the command itself. If this applies to your job, or if your job is in another user’s crontab, begin by opening a bash prompt as that user sudo -u username bash
   • By default, cron will run your command using /bin/sh, not the bash or zsh prompt you are familiar with. Double check your crontab file for an optional
     SHELL=/bin/bash declaration. If using the default /bin/sh shell, certain features that work in bash like [[command]] syntax will cause syntax errors under cron.
   • Unlike your interactive shell, cron doesn’t load your bashrc or bash_profile so any environment variables defined there are unavailable in your cron jobs. This is true even if you have a SHELL=/bin/bash declaration. To simulate this, create a command prompt with a clean environment.

     dev01: ~ $ env -i /bin/sh
     $

   • By default, cron will run commands with your home directory as the current working directory. To ensure you are running the command like cron does, run cd ~ at your prompt.
   • Paste the command to run (everything after the schedule or declared username) into the command prompt. If crontab is unable to run your command, this should fail too and will hopefully contain a useful error message.
     Common errors include invalid permissions, command not found, and command line syntax errors.
   • If no useful error message is available, double check any application logs your job is expected to produce, and ensure that you are not redirecting log and error messages.
     In linux, command >> /path/to/file will redirect console log messages to the specified file and command >> /path/to/file 2>&1 will redirect both the console log and error messages.
     Determine if your command has a verbose output or debug log flag that can be added to see additional details at runtime.
   • Ideally, if your job is failing under cron it will fail here too and you will see a useful error message, giving you a chance to modify and debug as needed. Common errors include file not found, misconfigured permissions, and commandline syntax errors.

2. Check for overlapping jobs

   At Cronitor our data shows that runtime durations increase over time for a large percentage of cron jobs. As your dataset and user base grows it’s normal to find yourself in a situation
   where cron starts an instance of your job before the previous one has finished. Depending on the nature of your job this might not be a problem, but several undesired side effects are possible:

   • Unexpected server or database load could impact other users
   • Locking of shared resources could cause deadlocks and prevent your jobs from ever completing successfully
   • Creation of an unanticipated race condition that might result in records being processed multiple times, amplifying server load and possibly impacting customers

   To verify if any instances of a job are running on your server presently, grep your process list. In this example, 3 job invocations are running simultaneously:

   dev01: ~ $ ps aux | grep database-backup.sh
   ubuntu           1343   0.0  0.1  2585948  12004   ??  S    31Jul18   1:04.15 /var/cronitor/bin/database-backup.sh
   ubuntu           3659   0.0  0.1  2544664    952   ??  S     1Aug18   0:34.35 /var/cronitor/bin/database-backup.sh
   ubuntu           7309   0.0  0.1  2544664   8012   ??  S     2Aug18   0:18.01 /var/cronitor/bin/database-backup.sh

   To quickly recover from this, first kill the overlapping jobs and then watch closely when your command is next scheduled to run. It’s possible that a one time failure cascaded into several overlapping instances.
   If it becomes clear that the job often takes longer than the interval between job invocations you may need to take additional steps, e.g.:

   • Increase the duration between invocations of your job. For example if your job runs every minute now, consider running it every other minute.
   • Use a tool like flock to ensure that only a single instance of your command is running at any given time. Using flock is easy. After installing
     from apt-get or yum you only need to prefix the command in your crontab:

   dev01: ~ $ crontab -l
   # Edit this file to introduce tasks to be run by cron.
   # m h  dom mon dow   command
   * * * * *      flock -w 0 /var/cronitor/bin/database-backup.sh

   Read more about flock from the man page.

What to do if nothing else works

Here are a few things you can try if you’ve followed this guide and find that your job works flawlessly when run from the cron-like command prompt but fails to complete successful under crontab.

• First get the most basic cron job working with a command like date >> /tmp/cronlog. This command will simply echo the execution time to the log file each time it runs. Schedule this to run every minute and tail the logfile for results.

• If your basic command works, replace it with your command. As a sanity check, verify if it works.

• If your command works by invoking a runtime like python some-command.py perform a few checks to determine that the runtime version and environment is correct. Each language runtime has quirks
  that can cause unexpected behavior under crontab.

  • For python you might find that your web app is using a virtual environment you need to invoke in your crontab.
  • For node a common problem is falling back to a much older version bundled with the distribution.
  • When using php you might run into the issue that custom settings or extensions that work in your web app
    are not working under cron or commandline because a different php.ini is loaded.

  If you are using a runtime to invoke your command double check that it’s pointing to the expected version from within the cron environment.

• If nothing else works, restart the cron daemon and hope it helps, stranger things have happened. The way to do this varies from distro to distro so it’s best to ask google.

Cronitor automatically finds and monitors cron jobs.  Complete your setup in minutes.

Get Started Free

The syntax for the crontab entry looks correct. Indeed, if you edit your crontab using «crontab -e» (as you should), you’ll get an error if you specify a syntactically invalid crontab entry anyway.

1. Firstly, does /path_to_my_php_script/info.php run correctly from the command-line?

2. If so, does it also run correctly like this?:

   /bin/sh -c "(export PATH=/usr/bin:/bin; /path_to_my_php_script/info.php </dev/null)"
   

3. If that works, does it work like this?

   /bin/sh -c "(export PATH=/usr/bin:/bin; /path_to_my_php_script/info.php </dev/null >/dev/null 2>&1)"
   

Step (3) is similar to how cron will run your program (as documented in «man 5 cron».

The most likely problem you’re having is that the PATH cron is using to run your program is too restrictive. Therefore, you may wish to add something like the following to the top of your crontab entry (you’ll need to add in whatever directories your script will need):

PATH=~/bin:/usr/bin/:/bin

Also note that cron will by default use /bin/sh, not bash. If you need bash, also add this to the start of your crontab file:

SHELL=/bin/bash

Note that both those changes will affect all the crontab entries. If you just want to modify these values for your info.php program, you could do something like this:

*/2 * * * * /bin/bash -c ". ~/.bashrc; /path_to_my_php_script/info.php"

It’s also worth mentioning that on a system configured for «mail» (in other words a system which has an MTA configured [sendmail/postfix/etc]), all output from crontab programs is sent to you via email automatically. A default Ubuntu desktop system won’t have local mail configured, but if you’re working on a server you can just type «mail» in a terminal to see all those cron mails. This also applies to the «at» command.

Ubuntu Linux проверка ошибок cron

Где хранится информация о запуске заданий по расписанию? Для проверки используем Ubuntu Linux 12.04/14.04 LTS сервер. Как проверит, запущен ли cron и правильно ли он работает?

Как проверить запущен ли cron (планировщик заданий)? Используйте команду pgrep  или ps

pgrep cron ps aux | grep cron sudo service cron status sudo status cron

Результат

Так же вы можете проверить файл /var/log/syslog используя команду grep что бы получить информации о работе планировщика cron

$ sudo grep —color -i cron /var/log/syslog

Результат:

Jan 17 17:43:21 planetvenus cron[229]: (CRON) INFO (pidfile fd = 3) Jan 17 17:43:21 planetvenus cron[240]: (CRON) STARTUP (fork ok) Jan 17 17:43:21 planetvenus cron[240]: (CRON) INFO (Running @reboot jobs) Jan 17 18:01:01 planetvenus cron[240]: (*system*cache) NOT A REGULAR FILE (/etc/cron.d/cache) Jan 17 18:01:01 planetvenus cron[240]: (*system*output) NOT A REGULAR FILE (/etc/cron.d/output)

Где хранятся журналы работы cron на Ubuntu Linux?

Журналы хранятся в файле /var/log/cron.log. Вы можете настроить его следующим образом. Редактировать /etc/rsyslog.d/50-default.conf файл с помощью текстового редактора, например, vi или nano:

$ sudo vi /etc/rsyslog.d/50-default.conf

или

$ sudo nano /etc/rsyslog.d/50-default.conf

Найдите строку

#cron.* /var/log/cron.log

Необходимо её раскомментировать, и перезапустить оба сервиса:

$ sudo service rsyslog restart

$ sudo service cron restart

Теперь все сообщения об ошибках в работе планировщика можно будет просматривать в файле

/var/log/cron.log

Воспользуйтесь различными командами для поиска нужной информации в логе

$ sudo grep что_нибудь/var/log/cron.log $ sudo more /var/log/cron.log $ sudo tail -f /var/log/cron.log $ sudo egrep -i ‘error|log’ /var/log/cron.log $ sudo tail -F /var/log/cron.log

In this article, We are going to Learn How to test a Cron Job?

Like a Pro 😎😎

These are exact strategies I have used to test multiple Cron jobs over 5 years of time

What is the Cron Job?

The software utility Cron is a time-based job scheduler in Unix-like computer operating systems

People who set up and maintain software environments use cron to schedule jobs (commands or shell scripts) to run periodically at fixed times, dates, or intervals.

How to test a Cron Job?

Below are the few points/Pre-made Test cases for the Cron Job Testing:-

Open the Corntab – Its an online tool that will help you to Check the Cron time.
You can enter the cron time and it will tell you when this cron will trigger.
Note down the time and verify if its correct one.

Mock the Cron time

To verify quickly Mock the Cron time by 1-2 minutes by changing it for quick testing (if it’s long for an hour/day long). – High

Make it debuggable as QA

Ask the devs to create a shortcut for it. In the server or any other way to directly run it by you so that you can test it when you need it.(saves time)

This way, You can easily run the cron at any time by own and debug it fast and quick

As Devs to Switch On Logs

Ask dev to add the logs for monitor purposes and monitor it while testing.
Use below command for logs

• * * * * /path/script.sh &> /path/script.log or
  tail -f /var/log/cron

Test Cron as CRUD

Do testing by doing changing things as we do in CRUD(Not always, Crud means update/delete etc whichever is relevant) and verify results. – High

Break the Flow of Cron and Verify

Break something the job relies on upon and schedule it to run again in a few minutes – Verify the results.

Validate with Real Data

After deployment – Validate it with real data also. – High

Make sure About Server and System Time

Keep system time and user system time in mind while testing CRON’s as scheduling is by server GMT time usually.

Verify Impact on the failure of Cron

Negative scenario: What if CRON is stopped the midway execution, any impacts it will have?

Break the Flow of Cron – Multiple times running it

Negative – Discuss with dev if there is any possibility of the same Cron getting run multiple times.

Risk of Failed Cron – Verify and Let Dev know

Negative – Discuss with dev if it fails to the job – What is the risk/ solution for it(did we get the mail if it fails ?)

Regression of Cron Job

Test for scenarios which shouldn’t get affected by Cron job(e.g. the other Cron should not affect other cron)

Let’s take an Example

This is sample Cron job template in crontab

0/1 * * * * /usr/bin/python /home/my_username/hello.py > /home/my_username/log.txt

Hello.py:

Check and Verify its scenarios.

One Small Request:

If you enjoyed reading this article, kindly give it a share. Your share is extremely helpful to spread our message and help more bloggers like you.

—
Be sure to subscribe for more videos like this!