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

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

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

Я на Debian 6 с root

ОТВЕТЫ

Ответ 1

Просто выполните то, что делает cron, запустите root:

run-parts -v /etc/cron.weekly

или

run-parts /etc/cron.weekly -v

если вы получили ошибку "Не каталог: -v".

-v печатает имена script до их запуска.

Ответ 2

Допустим, что вы не согласны с вашим вопросом... но вот что я делаю.

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

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

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

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

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

Итак, теперь cron будет запускать вашу команду каждую минуту, но crontest гарантирует, что только один экземпляр запускается за раз. Если команде требуется время для запуска, вы можете сделать "экран -x" для прикрепления и просмотра его запуска. Если команда script, вы можете поместить команду "читать" вверху, чтобы остановить ее и дождаться завершения прикрепления к экрану (нажмите Enter после присоединения)

Если ваша команда bash script, вы можете сделать это вместо:

* * * * * 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

Ответ 3

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

crontab -e

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

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

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

Ответ 4

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

Ответ 5

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

Ответ 6

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

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

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

Ответ 7

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

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

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

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

Он работал как шарм, и больше всего мне приходилось ждать чуть меньше минуты.

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

Ответ 8

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

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

выполнить задание:

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

Ответ 9

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

  • Отредактируйте crontab (используйте команду: crontab -e), чтобы выполнять задание так часто при необходимости (каждые 1 минуту или 5 минут).
  • Измените оболочку script, которая должна быть выполнена с помощью cron для вывода вывода в некоторый файл (например: echo "Working fine" )

    output.txt)
  • Проверьте файл output.txt с помощью команды: tail -f output.txt, которая будет печатать последние добавления в этот файл, и, таким образом, вы можете отслеживать выполнение script

Ответ 10

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

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

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

Ответ 11

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

В "Системе > Запланированные задания Cron > Изменить работу с помощью Cron" есть кнопка "Сохранить и запустить сейчас".

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