如何testing每周一次的cron工作？
我在cron.week目录下有一个#!/bin/bash文件。
有没有一种方法来testing它是否工作？ 不能等一周
我在Debian 6的根目录下
只要做cron做的事情，以root身份运行以下内容：
run-parts -v /etc/cron.weekly
要么
run-parts /etc/cron.weekly -v
如果您收到“不是目录：-v”错误。
-v在运行之前打印脚本名称。
稍微超出你的问题的范围…但这是我做的。
“我如何testing一个cron工作？” 问题与“如何testing在其他程序启动的非交互式上下文中运行的脚本”密切相关？ 在cron中，触发器是一些时间条件，但许多其他* nix工具以非交互方式启动脚本或脚本片段，而且这些脚本运行的条件通常包含意外的事情，并导致破坏，直到错误被排除。
这个问题的一般方法是有帮助的。
我最喜欢的技术之一是使用我写的叫做“ crontest ”的脚本。 它从cron内的GNU屏幕会话中启动目标命令，以便您可以附加一个单独的terminal，以查看发生了什么，与脚本交互，甚至使用debugging器。
要设置它，你可以在你的crontab条目中使用“all stars”，并在命令行中指定crontest作为第一个命令，例如：
* * * * * crontest /command/to/be/tested --param1 --param2
所以现在cron会每分钟运行你的命令，但是crontest将确保一次只运行一个实例。 如果命令运行需要时间，您可以执行“screen -x”来附加并观察运行。 如果该命令是脚本，则可以在顶部放置一个“读取”命令，使其停止并等待屏幕附件完成（附加后按回车键）
如果你的命令是一个bash脚本，你可以这样做：
* * * * * crontest --bashdb /command/to/be/tested --param1 --param2
现在，如果你附加“screen -x”，你将面临一个交互式的bashdb会话，你可以遍历代码，检查variables等。
#!/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中的一些不兼容的东西搞乱之后，我发现以下方法对于debugging是很好的：
crontab -e * * * * * /path/to/prog var1 var2 &>>/tmp/cron_debug_log.log
这将每分钟运行一次任务，您只需查看/tmp/cron_debug_log.log文件即可确定发生了什么。
这不完全是你可能正在寻找的“火力工作”，但是这在debugging一个在cron中不起作用的脚本的时候帮了我很大的忙。
我会使用一个locking文件，然后将cron作业设置为每分钟运行一次。 （使用crontab -e和* * * * * / path / to / job）这样你就可以继续编辑这些文件，并且每一分钟都会被testing出来。 另外，你可以通过触摸locking文件来停止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作业。
我只是写下我目前的设置，然后将其编辑为从现在开始的一分钟。 当我修复了另外一个bug的时候，我从现在开始只是再编辑一次。 当我完成所有工作后，我只是将设置重新设置回原来的样子。
例如：现在是4:34，所以我把35 16 * * *放在16:35。
它的function如同一种魅力，而我所能等待的最多时间不到一分钟。
我认为这是一个比其他答案更好的select，因为我不想运行所有的每周定时器，我不希望这项工作每分钟都运行。 在我准备再次testing之前，需要几分钟的时间才能解决问题。 希望这有助于某人。
我通常通过运行我创build的工作来testing：
使用两个terminal来做这个比较容易。
运行工作：
#./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：将debugging级别设置为0 – 打开或closures打印的内容。 （范围：0 – 10）。
-y：假设是的; 假设对任何问题的答案是肯定的
在我build立了cron作业之后，我运行了下面的命令来使我的作业可执行。
#chmod +x /etc/cron.daily/jobname.sh
希望这可以帮助Dorlack
我正在使用的解决scheme如下所示：
- 编辑crontab（使用命令：crontab -e）根据需要频繁运行作业（每1分钟或5分钟）
- 修改应该使用cron执行的shell脚本将输出打印到某个文件中（例如：echo“Working fine”>>
output.txt中） - 使用命令：tail -f output.txt检查output.txt文件，该命令会将最新添加到此文件中，从而可以跟踪脚本的执行情况
sudo run-parts --test /var/spool/cron/crontabs/
该crontabs/目录中的文件需要由拥有者 – 八进制700来执行
来源： man cron和NNRooth的
我正在使用Webmin，因为对于发现命令行pipe理的人来说，它是一个生产力gem，有点令人望而生畏。
在“系统>计划Cron作业>编辑Cron作业”Web界面中有一个“保存并立即运行”button。
它显示命令的输出，正是我所需要的。
