Как проверить еженедельную работу cron?
У меня есть #!/bin/bash
файл в cron.недельный справочник.
есть ли способ проверить, работает ли он? Не могу ждать 1 неделю
Я на Debian 6 с root
11 ответов
просто сделайте то, что делает cron, запустите следующее Как root
:
run-parts -v /etc/cron.weekly
... или следующий, если вы получите" не каталог: -v " ошибка:
run-parts /etc/cron.weekly -v
опции -v
печатает имена сценариев перед их запуском.
немного выходит за рамки вашего вопроса... но вот что я сделаю.
"как проверить работу cron?"вопрос тесно связан с "как тестировать сценарии, которые выполняются в неинтерактивных контекстах, запущенных другими программами?"В cron триггер-это некоторое условие времени, но многие другие * Nix-объекты запускают скрипты или фрагменты скриптов неинтерактивными способами, и часто условия, в которых эти скрипты запускаются, содержат что-то неожиданное и вызывают поломку, пока ошибки устранены.
общий подход к этой проблеме полезно.
один из моих любимых методов-использовать сценарий, который я написал под названием 'crontest'. Он запускает целевую команду внутри сеанса экрана GNU из cron, так что вы можете прикрепиться к отдельному терминалу, чтобы увидеть, что происходит, взаимодействовать со скриптом, даже использовать отладчик.
чтобы настроить это, вы должны использовать "все звезды" в своей записи crontab и указать crontest в качестве первой команды в командной строке, например:
* * * * * crontest /command/to/be/tested --param1 --param2
Теперь cron будет запускать вашу команду каждую минуту, но crontest гарантирует, что только один экземпляр запускается за раз. Если команда требует времени для запуска, вы можете сделать" экран-x", чтобы прикрепить и посмотреть, как он работает. Если команда является скриптом, вы можете поместить команду "read" вверху, чтобы остановить ее и дождаться завершения вложения экрана (нажмите enter после присоединения)
Если ваша команда является скриптом bash, вы можете сделать это вместо:
* * * * * crontest --bashdb /command/to/be/tested --param1 --param2
Теперь, если вы присоединитесь к "screen-x", вы столкнетесь с интерактивным сеансом bashdb, и вы можете пройти через код, изучить переменные и т. д.
#!/bin/bash
# crontest
# See https://github.com/Stabledog/crontest for canonical source.
# Test wrapper for cron tasks. The suggested use is:
#
# 1. When adding your cron job, use all 5 stars to make it run every minute
# 2. Wrap the command in crontest
#
#
# Example:
#
# $ crontab -e
# * * * * * /usr/local/bin/crontest $HOME/bin/my-new-script --myparams
#
# Now, cron will run your job every minute, but crontest will only allow one
# instance to run at a time.
#
# crontest always wraps the command in "screen -d -m" if possible, so you can
# use "screen -x" to attach and interact with the job.
#
# If --bashdb is used, the command line will be passed to bashdb. Thus you
# can attach with "screen -x" and debug the remaining command in context.
#
# NOTES:
# - crontest can be used in other contexts, it doesn't have to be a cron job.
# Any place where commands are invoked without an interactive terminal and
# may need to be debugged.
#
# - crontest writes its own stuff to /tmp/crontest.log
#
# - If GNU screen isn't available, neither is --bashdb
#
crontestLog=/tmp/crontest.log
lockfile=$(if [[ -d /var/lock ]]; then echo /var/lock/crontest.lock; else echo /tmp/crontest.lock; fi )
useBashdb=false
useScreen=$( if which screen &>/dev/null; then echo true; else echo false; fi )
innerArgs="$@"
screenBin=$(which screen 2>/dev/null)
function errExit {
echo "[-err-] $@" | tee -a $crontestLog >&2
}
function log {
echo "[-stat-] $@" >> $crontestLog
}
function parseArgs {
while [[ ! -z ]]; do
case in
--bashdb)
if ! $useScreen; then
errExit "--bashdb invalid in crontest because GNU screen not installed"
fi
if ! which bashdb &>/dev/null; then
errExit "--bashdb invalid in crontest: no bashdb on the PATH"
fi
useBashdb=true
;;
--)
shift
innerArgs="$@"
return 0
;;
*)
innerArgs="$@"
return 0
;;
esac
shift
done
}
if [[ -z $sourceMe ]]; then
# Lock the lockfile (no, we do not wish to follow the standard
# advice of wrapping this in a subshell!)
exec 9>$lockfile
flock -n 9 || exit 1
# Zap any old log data:
[[ -f $crontestLog ]] && rm -f $crontestLog
parseArgs "$@"
log "crontest starting at $(date)"
log "Raw command line: $@"
log "Inner args: $@"
log "screenBin: $screenBin"
log "useBashdb: $( if $useBashdb; then echo YES; else echo no; fi )"
log "useScreen: $( if $useScreen; then echo YES; else echo no; fi )"
# Were building a command line.
cmdline=""
# If screen is available, put the task inside a pseudo-terminal
# owned by screen. That allows the developer to do a "screen -x" to
# interact with the running command:
if $useScreen; then
cmdline="$screenBin -D -m "
fi
# If bashdb is installed and --bashdb is specified on the command line,
# pass the command to bashdb. This allows the developer to do a "screen -x" to
# interactively debug a bash shell script:
if $useBashdb; then
cmdline="$cmdline $(which bashdb) "
fi
# Finally, append the target command and params:
cmdline="$cmdline $innerArgs"
log "cmdline: $cmdline"
# And run the whole schlock:
$cmdline
res=$?
log "Command result: $res"
echo "[-result-] $(if [[ $res -eq 0 ]]; then echo ok; else echo fail; fi)" >> $crontestLog
# Release the lock:
9<&-
fi
после возни с некоторыми вещами в cron, которые не были мгновенно совместимы, я обнаружил, что следующий подход был хорош для отладки:
crontab -e
* * * * * /path/to/prog var1 var2 &>>/tmp/cron_debug_log.log
это будет запускать задачу один раз в минуту, и вы можете просто посмотреть в чтобы выяснить, что происходит.
это не совсем "пожарная работа", которую вы можете искать, но это очень помогло мне при отладке скрипта, который сначала не работал в cron.
Я бы использовал файл блокировки, а затем установил задание cron для запуска каждую минуту. (используйте crontab-e и * * * * * /path/to/job) таким образом, вы можете просто продолжать редактировать файлы, и каждую минуту они будут протестированы. Кроме того, вы можете остановить cronjob, просто коснувшись файла блокировки.
#!/bin/sh
if [ -e /tmp/cronlock ]
then
echo "cronjob locked"
exit 1
fi
touch /tmp/cronlock
<...do your regular cron here ....>
rm -f /tmp/cronlock
насчет положить его в cron.hourly
, ожидая следующего запуска почасовых заданий cron, а затем удаляя его? Это будет запускаться один раз в течение часа и в среде cron. Вы также можете запустить ./your_script
, но это не будет иметь ту же среду, что и в cron.
помимо этого вы также можете использовать:
http://pypi.python.org/pypi/cronwrap
чтобы завернуть Ваш cron, чтобы отправить вам электронное письмо при успехе или неудаче.
ни один из этих ответов не соответствовал моей конкретной ситуации, которая заключалась в том, что я хотел запустить одно конкретное задание cron, только один раз, и запустить его немедленно.
Я на сервере Ubuntu, и я использую cPanel для настройки моих заданий cron.
Я просто записал свои текущие настройки,а затем отредактировал их, чтобы быть через одну минуту. Когда я исправил еще одну ошибку,я просто отредактировал ее снова через минуту. И когда я все сделал, я просто сбросил настройки обратно, как они были до.
пример: сейчас 4: 34 вечера, поэтому я положил 35 16 * * *, для его запуска в 16: 35.
Это сработало как заклинание, и самое большее, что мне когда-либо приходилось ждать, было чуть меньше одной минуты.
Я думал, что это лучший вариант, чем некоторые другие ответы, потому что я не хотел запускать все мои еженедельные кроны, и я не хотел, чтобы работа выполнялась каждую минуту. Мне требуется несколько минут, чтобы исправить все проблемы, прежде чем я буду готов проверить его снова. Обнадеживающе это кому-то помогает.
Я обычно тестирую, выполняя задание, которое я создал следующим образом:
для этого проще использовать два терминала.
выполнить задание:
#./jobname.sh
на:
#/var/log and run
выполнить следующее:
#tailf /var/log/cron
Это позволяет мне видеть обновление журналов cron в режиме реального времени. Вы также можете просмотреть журнал после его запуска, я предпочитаю смотреть в режиме реального времени.
вот пример простой работы cron. Запуск yum обновление...
#!/bin/bash
YUM=/usr/bin/yum
$YUM -y -R 120 -d 0 -e 0 update yum
$YUM -y -R 10 -e 0 -d 0 update
вот:
первая команда обновит сам yum, а затем применит системные обновления.
- R 120: устанавливает максимальное количество времени, которое yum будет ждать перед выполнением команды
- e 0: устанавливает уровень ошибки в 0 (диапазон 0 - 10). 0 означает печать только критических ошибок, о которых необходимо сообщить.
- d 0: устанавливает уровень отладки в 0-поворачивает вверх или вниз количество вещей, которые печатаются. (диапазон: 0 - 10).
- y: предположим, да; предположим, что ответ на любой вопрос, который будет задан, - да
после того, как я построил задание cron, я запустил следующую команду, чтобы сделать мою работу исполняемой.
#chmod +x /etc/cron.daily/jobname.sh
надеюсь, это поможет, Dorlack
решение я использую выглядит следующим образом:
- Edit crontab(используйте команду: crontab-e), чтобы часто запускать задание по мере необходимости (каждые 1 минуту или 5 минут)
- измените сценарий оболочки, который должен быть выполнен с помощью cron для печати вывода в некоторый файл (e.g: Эхо "работает нормально">>
выход.txt) - Проверьте выход.txt-файл с помощью команды: вывод tail-F.txt, который будет печатать последние дополнения в этот файл, и таким образом вы можете отслеживать выполнение скрипта
Я использую Webmin потому что это жемчужина производительности для тех, кто считает администрирование командной строки немного сложным и непроницаемым.
в веб-интерфейсе" система > запланированные задания Cron > изменить задание Cron "есть кнопка" Сохранить и запустить сейчас".
он отображает вывод команды и это именно то, что мне нужно.