如何测试每周的cron工作？
我在cron.week目录中有一个#!/bin/bash文件。
有没有办法测试它是否有效？ 不能等一周
我在Debian 6上有root用户
只要执行cron所做的事情，以root身份运行以下内容：
run-parts -v /etc/cron.weekly
要么
run-parts /etc/cron.weekly -v
如果您收到“不是目录：-v”错误。
-v在运行之前打印脚本名称。
稍微超出你问题的范围......但这就是我所做的。
“我如何测试cron工作？” 问题与“如何测试在其他程序启动的非交互式上下文中运行的脚本”密切相关？ 在cron中，触发器是一些时间条件，但许多其他* nix工具以非交互方式启动脚本或脚本片段，并且这些脚本运行的条件通常包含意外事件并导致破坏，直到错误被排除。
对这个问题的一般方法是有帮助的。
我最喜欢的技术之一是使用我写的叫做'crontest'的脚本。 它从cron内的GNU屏幕会话中启动目标命令，以便您可以附加一个单独的终端来查看正在发生的事情，与脚本进行交互，甚至可以使用调试器。
要设置它，你可以在你的crontab条目中使用“all stars”，并且在命令行中指定crontest作为第一个命令，例如：
* * * * * crontest /command/to/be/tested --param1 --param2
所以现在cron会每分钟运行你的命令，但是crontest将确保一次只运行一个实例。 如果该命令需要时间运行，您可以执行“屏幕-x”来附加并观察它运行。 如果该命令是脚本，则可以在顶部放置一个“读取”命令，使其停止并等待屏幕附件完成（附加后按回车键）
如果你的命令是一个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中工作的脚本时，这帮助了我很多。
链接地址: http://www.djcxy.com/p/66339.html