it-swarm-ru.tech

Как проверить еженедельную работу cron?

У меня есть файл #!/bin/bash в каталоге cron.week.

Есть ли способ проверить, работает ли он? Не могу ждать 1 неделю

Я нахожусь на Debian 6 с рутом

223
dynamic

Просто сделайте то, что делает cron, запустите следующее как root:

run-parts -v /etc/cron.weekly

... или следующий, если вы получаете сообщение об ошибке "Not a directory: -v":

run-parts /etc/cron.weekly -v

Опция -v печатает имена скриптов до их запуска.

224
NNRooth

Немного за рамками твоего вопроса ... но вот что я делаю.

Как мне проверить работу cron? Этот вопрос тесно связан с тем, "как я тестирую скрипты, которые запускаются в неинтерактивных контекстах, запускаемых другими программами?" В cron триггер является неким временным условием, но множество других * nix-средств запускают сценарии или фрагменты сценария неинтерактивными способами, и часто условия, в которых запускаются эти сценарии, содержат что-то неожиданное и вызывают сбой до устранения ошибок.

Общий подход к этой проблеме полезно иметь.

Один из моих любимых приемов - использовать скрипт, который я написал под названием " crontest ". Он запускает команду target внутри сеанса экрана GNU из cron, так что вы можете подключиться к отдельному терминалу, чтобы посмотреть, что происходит, взаимодействовать со сценарием, даже использовать отладчик.

Чтобы настроить это, вы должны использовать "все звезды" в записи crontab и указать crontest в качестве первой команды в командной строке, например:

* * * * * crontest /command/to/be/tested --param1 --param2

Так что теперь cron будет запускать вашу команду каждую минуту, но crontest гарантирует, что одновременно запускается только один экземпляр. Если для выполнения команды требуется время, вы можете выполнить команду "screen -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="[email protected]"
screenBin=$(which screen 2>/dev/null)

function errExit {
    echo "[-err-] [email protected]" | tee -a $crontestLog >&2
}

function log {
    echo "[-stat-] [email protected]" >> $crontestLog
}

function parseArgs {
    while [[ ! -z $1 ]]; do
        case $1 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="[email protected]"
                return 0
                ;;
            *)
                innerArgs="[email protected]"
                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 "[email protected]"

    log "crontest starting at $(date)"
    log "Raw command line: [email protected]"
    log "Inner args: [email protected]"
    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
81
Stabledog

После работы с некоторыми вещами в cron, которые не были мгновенно совместимы, я обнаружил, что следующий подход был хорош для отладки:

crontab -e

* * * * * /path/to/prog var1 var2 &>>/tmp/cron_debug_log.log

Это будет запускать задачу раз в минуту, и вы можете просто посмотреть в файле /tmp/cron_debug_log.log, чтобы выяснить, что происходит.

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

39
Automatico

Я бы использовал файл блокировки, а затем настраивал задание 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
23
dave fernholz

Как насчет помещения его в cron.hourly, ожидания следующего запуска ежечасных заданий cron, а затем его удаления? Это запустится один раз в течение часа и в среде cron. Вы также можете запустить ./your_script, но это не будет иметь ту же среду, что и в cron.

5
Jeremiah Willcock

Помимо этого вы также можете использовать:

http://pypi.python.org/pypi/cronwrap

завернуть свой хрон, чтобы отправить вам электронное письмо в случае успеха или неудачи.

4
Low Kian Seong

Ни один из этих ответов не соответствовал моей конкретной ситуации: я хотел запустить одно конкретное задание cron только один раз и запустить его немедленно.

Я нахожусь на сервере Ubuntu, и я использую cPanel для настройки моих заданий cron.

Я просто записал свои текущие настройки, а затем отредактировал их через одну минуту. Когда я исправил еще одну ошибку, я просто отредактировал ее снова через одну минуту. И когда я все закончил, я просто сбросил настройки обратно на прежние.

Пример: сейчас 4:34 вечера, поэтому я поставил 35 16 * * *, чтобы он работал в 16:35.

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

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

4
Ben C

Обычно я проверяю, запустив задание, которое я создал следующим образом:

Для этого проще использовать два терминала.

запустить работу:

#./jobname.sh

идти к:

#/var/log and run 

запустите следующее:

#tailf /var/log/cron

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

Вот пример простой работы cron. Запуск ням-обновления ...

#!/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).

-у: предположим да; Предположим, что ответ на любой вопрос, который будет задан, - да

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

#chmod +x /etc/cron.daily/jobname.sh 

Надеюсь, это поможет, Дорлак

2
Dorlack
Sudo run-parts --test /var/spool/cron/crontabs/

файлы в этом каталоге crontabs/ должны быть исполняемыми владельцем - восьмеричный 700

источник: man cron и NNRooth

2
n611x007

Я использую следующее решение:

  1. Отредактируйте crontab (используйте команду: crontab -e), чтобы запускать задание так часто, как это необходимо (каждые 1 минуту или 5 минут)
  2. Измените сценарий Shell, который должен выполняться с помощью cron, чтобы распечатать вывод в некоторый файл (например, echo "Работает нормально" >>
    Output.txt)
  3. Проверьте файл output.txt с помощью команды: tail -f output.txt, которая напечатает последние добавления в этот файл, и, таким образом, вы сможете отслеживать выполнение скрипта
2
Abhilash