wake-up-neo.com

如何测试每周一次的cron工作?

我在cron.week目录中有一个#!/bin/bash文件。

有没有办法测试它是否有效?等不到1周

我在Debian 6上用root

222
dynamic

只需执行cron所做的操作,运行以下命令为root

run-parts -v /etc/cron.weekly

...如果收到“Not a directory:-v”错误,则为下一个错误:

run-parts /etc/cron.weekly -v

选项-v在脚本名称运行之前打印它们。

223
NNRooth

有点超出你的问题的范围......但这就是我的工作。

“我该如何测试一个cron作业?”问题与“如何测试在其他程序启动的非交互式上下文中运行的脚本”密切相关?在cron中,触发器是一些时间条件,但许多其他* nix工具以非交互方式启动脚本或脚本片段,并且这些脚本运行的条件通常包含意外情况并导致破坏,直到错误被整理出来。

这个问题的一般方法是有帮助的。

我最喜欢的技巧之一是使用我写的名为' crontest '的脚本。它在cron内的GNU屏幕会话中启动目标命令,这样你就可以用一个单独的终端连接,看看发生了什么,与脚本交互,甚至使用调试器。

要进行此设置,您可以在crontab条目中使用“all stars”,并在命令行中指定crontest作为第一个命令,例如:

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

所以现在cron将每分钟运行一次命令,但是crontest将确保一次只运行一个实例。如果命令需要一段时间才能运行,您可以执行“screen -x”连接并观察它运行。如果命令是脚本,您可以在顶部放置一个“读取”命令使其停止并等待屏幕附件完成(在附加后按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中不起作用的脚本时,这对我帮助很大。

38
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

结束你的cron,在成功或失败时给你发电子邮件。

4
Low Kian Seong

这些答案都不符合我的具体情况,即我只想运行一次特定的cron作业,然后立即运行。

我在Ubuntu服务器上,我使用cPanel来设置我的cron作业。

我只是写下我当前的设置,然后将它们编辑为一分钟。当我修复另一个错误时,我再次编辑它到现在一分钟。当我完成所有工作后,我只需将设置重置为之前的设置。

示例:现在是下午4:34,所以我放了35 16 * * *,因为它在16:35运行。

它就像一个魅力,而我曾经不得不等待的时间不到一分钟。

我认为这是一个比其他一些答案更好的选择,因为我不想每周运行所有的crons,而且我不想让这项工作每分钟都运行一次。在我准备好再次测试之前,我需要花几分钟时间来解决所有问题。希望这有助于某人。

4
Ben C

我通常通过运行我创建的工作进行测试:

使用两个终端更容易。

跑步工作:

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

多拉克,希望这会有所帮助

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

crontabs/目录中的文件需要 所有者可执行 - octal 700

来源:man cronNNRooth s

2
n611x007

我使用的解决方案如下:

  1. 编辑crontab(使用命令:crontab -e)根据需要频繁运行作业(每1分钟或5分钟)
  2. 修改应该使用cron执行的Shell脚本,将输出打印到某个文件中(例如:echo“Working fine”>>
    output.txt的)
  3. 使用以下命令检查output.txt文件:tail -f output.txt,它将最新添加到此文件中,因此您可以跟踪脚本的执行情况
2
Abhilash