Проверьте еженедельную работу cron [закрыто]

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

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

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

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

run-parts -v /etc/cron.weekly

... или следующий, если вы получаете сообщение об ошибке «Не каталог: -v»:

run-parts /etc/cron.weekly -v

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

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

Как мне проверить работу cron? Этот вопрос тесно связан с тем, «как я тестирую скрипты, которые запускаются в неинтерактивных контекстах, запускаемых другими программами?» В cron триггер является некоторым условием времени, но множество других * nix-средств запускают сценарии или фрагменты сценария неинтерактивными способами, и часто условия, в которых запускаются эти сценарии, содержат что-то неожиданное и вызывают сбой до устранения ошибок. (См. Также: https://stackoverflow.com/a/17805088/237059 ).

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

Один из моих любимых приемов - использовать сценарий, который я написал под названием « 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="$@"
screenBin=$(which screen 2>/dev/null)

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

function log {
    echo "[-stat-] $@" >> $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="$@"
                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

Это будет запускать задачу раз в минуту, и вы можете просто посмотреть в /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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

sudo run-parts --test /var/spool/cron/crontabs/

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

Источник: man cronи NNRooth«s

Я использую Webmin, потому что это жемчужина производительности для тех, кто считает администрирование командной строки немного пугающим и непроницаемым.

В веб-интерфейсе «Система> Запланированные задания Cron> Редактировать задание Cron» есть кнопка «Сохранить и запустить сейчас».

Он отображает вывод команды и именно то, что мне нужно.