Cron работа не работает последовательно

Question

У меня есть работа cron:

1 0 * * * /usr/bin/wget -q -O /dev/null 'http://123.456.78.90/index/parsedata?&today=1'

Он должен собирать кучу данных из БД в 00:01 каждый день, организовывать их для использования нашим приложением в виде графиков и дисплеев, а затем делать это.

Иногда некоторые графики не обрабатываются, так как не показывают результатов в течение некоторого периода времени. Запуск команды вручную приведет к тому, что они получат правильные данные.

Таким образом, кажется, cron является частью проблемы. Либо cron не запускает это, не соответствует действительности, поскольку я вижу, что большинство записей отображают ожидаемые данные графика, или, возможно, cron не завершает работу? Я не знаю, где искать, поскольку я чувствовал, что, так как ручной запуск вышеуказанной строки сценария работает, почему он не будет работать таким же образом, когда я установил для этого cron? Есть идеи?

Существует еще одно задание cron, которое выполняется каждые 5 минут на одном и том же сервере с использованием того же кода:

*/5 * * * * /usr/bin/wget -q -O /dev/null http://123.456.78.90/index/parsedata

Возможно ли, что первый запуск занимает слишком много времени и все еще обрабатывается, когда запускается этот скрипт, который запускается каждые 5 минут, и это портит ситуацию? Выполнение первого сценария может занять более 5 минут, поэтому второй экземпляр может быть запущен, пока первый находится в процессе обработки. Они оба используют одно и то же действие parsedata() в нашей среде и записывают в одну и ту же базу данных. Может быть? Любые идеи приветствуются.

Answer 1

Задания, терпящие неудачу в cron, но работающие из терминала, обычно являются признаком того, что задание пытается произвести вывод в stdout или stderr и падает, потому что не может.

Похоже, вам нужно войти в систему. Попробуйте перенаправить stdout и stderr в файл, чтобы лучше понять, что происходит:

/usr/bin/wget -q -O /dev/null http://123.456.78.90/index/parsedata >> /tmp/somelogfile.txt 2>&1

Если генерируется какой-то вывод, возможно, он даст вам представление о том, что может быть причиной проблемы. Если после сбоя задания файл журнала по-прежнему пуст, то, по крайней мере, вы знаете, что искать в другом месте.

Answer 2

Если ваши два процесса попадают в тупиковую ситуацию в базе данных, то это может быть причиной более длительного сбоя задания (его выбирают в качестве убиваемой задачи для устранения тупика). Если это так, или если какая-то другая ошибка вызывает сбой процесса, вы можете обнаружить, что ваш скрипт parsedata возвращает полезное сообщение об ошибке (или другую подсказку), но вы никогда не видите его, потому что вы отбрасываете его вывод с помощью -O /dev/null . Я предлагаю вам записывать вывод, а не отправлять его в /dev/null , например:

-O /var/log/dailyparsedata/`date +%Y%m%d_%H%M`

(примечание: это обратные тики, а не одинарные кавычки) каждый день будет создаваться новый файл в /var/log/dailyparsedata/ . Вы можете установить другое задание cron (или настроить logwatch) для удаления файлов старше определенного возраста, чтобы не заполнять раздел этими файлами с течением времени.

Кроме того, могут быть условия ошибки, из-за которых wget даже не видит вывод скрипта (возможно, по какой-то причине он иногда даже не видит веб-сервер по какой-то причине: вполне возможно, если сервер, который он вызывает, является удаленным), в этом случае для него не будет ничего для вывода в файл, указанный в -O , а также для записи сценария outout log в stget и stderr wget в соответствии с предложением Стивена. Поскольку ваши строки cron в настоящее время стоят, большинство реализаций cron будут отправлять эти данные кому-то в виде электронного письма, добавив >> /var/log/dailyparsedata/wget.output 2>&1 , вместо этого эта информация будет сохранена в файле. Я не буду отправлять такой вывод в /tmp как здесь есть два риска: заполнение /tmp журналами, поэтому его основное использование прерывается, и его очищают по умолчанию, когда сервер перезагружается, что означает, что вы теряете журналы, которые вы позже захотите проверить ,