重定向/特殊符号及其含义
最好了解在将条目添加到 crontab 时使用的一些重定向和特殊符号。
使用它们的任何错误都可能再次导致 cron 作业失败。
在 cron 作业条目中使用这些符号的示例是：
0 5 * * * /bin/bash -l -c 'export RAILS_ENV=my_env; cd /my_folder; ./script/script.rb 2>&1 > ./log/my_log.log'
重定向文件描述符
有 3 个标准文件描述符：
1. stdin 0 - Standard input to the program. 2. stdout 1 - Standard output from the program. 3. stderr 2 - Standard error output from the program.
通常标准输入来自键盘，标准输出和标准错误进入终端。
但是我们可以将它重定向到一个文件。
最常用（且令人困惑）的重定向之一是 "2>&1" 。
这意味着从命令中获取标准错误输出并将其发送到标准输出所在的同一位置。
除了大多数重定向符号外，在 crontab 中输入 cron 作业条目时还使用了许多其他符号：
| 符号 | 说明 |
|---|---|
| ; | 在后台运行命令 |
| & | Run the command in the background |
| && | 仅当上一个命令成功完成时才运行以下命令（例如 grep string file && cat file） |
| || | 只有在上一个命令没有成功完成时才运行下面的命令 ( 例如 grep string file |
| ( ) | 括号内的命令在子shell中执行 |
| ' | 不要给这些引号内的任何字符赋予任何特殊含义 <br> 从字面上看后面的字符。也用于"escape"换行符，以便用户可以在多行上继续执行命令 |
| " " | 允许使用这些引号替换变量和命令 |
| `command` | 单反引号 -获取此命令的输出并将其替换为命令行上的参数 |
| # | #号之后的所有内容都是注释 |
Cron 工具可用于调度定期发生的命令或者脚本。
用户可以通过向位于 /var/spool/cron/crontabs 目录中的各自 crontabs 添加一个条目并存储为他们的登录名来提交 cron 作业。
以下是一些故障排除技巧和最佳实践，它们在许多情况下都会有所帮助。
'crontab -e' 命令返回一个数字和一个 '?'
有时，当我们尝试使用 crontab -e 命令编辑 crontab 文件时，它会打印一个数字和一个“?”。
这是因为默认情况下， crontab -e 命令使用的编辑器是默认的 solaris 编辑器“ed”，而不是 vi 编辑器。
当 ed 启动时，它会打印 crontab 文件中的字符数，并且没有提示。
为了避免这种情况，可以通过键入 q 来简单地从 ed 编辑器中退出。
现在将 EDITOR 环境变量设置为 vi 并再次运行 crontab -e ：
# EDITOR=vi # export EDITOR
检查 cron 守护进程是否正在运行
检查 cron 守护进程是否在系统中运行 [在 solaris 10 之前]：
# ps -ef |grep cron
要启动或者停止 cron 守护进程，请使用：
# /etc/init.d/cron [stop|start]
如果是 Solaris 10，请检查 cron 服务状态：
# svcs -p svc:/system/cron
要确保 cron 作业正常运行，请在 crontab 中添加以下条目。
* * * * * date > /dev/console
这将每分钟将日期打印到控制台。
如果我们无权访问控制台，也可以使用正在使用的 pts 终端。
检查 cron 权限
有时我们一定遇到错误“消息队列打开错误”。
造成这种情况的原因之一是对 cron 和 crontab 的错误权限。
cron 和 crontab 的适当权限是：
# ls -l /usr/sbin/cron -r-xr-xr-x 1 root sys 57420 Jan 22 2005 /usr/sbin/cron
# ls -l /usr/bin/crontab -r-sr-xr-x 1 root bin 20336 Jan 22 2005 /usr/bin/crontab
注意 crontab 文件的 setuid 权限。
控制对 crontab 的访问
文件 /etc/cron.d/cron.allow 可用于允许用户提交 cron 作业。
如果 cron.allow 文件不存在，则 cron 检查 /etc/cron.d/cron.deny 文件以查看哪些用户不允许提交 cron 作业。
如果两个文件中都存在用户，则 cron 守护程序首先检查 cron.allow 文件并忽略 cron.deny 文件。
如果两个文件都丢失，则只有 root 可以运行作业。
检查脚本的权限和路径
看起来很傻，但我看到很多人犯了这个错误，他们没有为他们想要从 cron 运行的脚本提供可执行权限。
# chmod u+x /path/to/script
还要确保 cron 条目具有脚本和脚本使用的 shell 的绝对路径：
* 5 * * * /bin/bash /path/to/script.sh
检查 cron 日志
很多时候，cron 日志文件 /var/cron/log 清楚地指出了 cronjob 中的问题。
检查脚本应该在 cron 日志中运行的时间段。
这很可能会指出 cronjob 中的错误。
重要的 cron 文件
与 cron 相关的重要文件是：
| 文件 | 作用 |
|---|---|
| /etc/cron.d/cron.allow | 包含有权提交 cronjobs 的用户名的文件 |
| /etc/cron.d/cron.deny | 包含无权提交 cronjobs 的用户名的文件 |
| /var/cron/log | Cron 日志文件 |
| /var/spool/cron/crontabs | 包含所有用户的单个 crontab 文件的目录。 |
用户的密码已过期
很多时候 cron 作业失败是因为拥有该作业的用户的密码已过期。
在这种情况下，我们会在 cron 日志文件 /var/cron/log 中看到以下错误：
Authentication token is no longer valid; new one required CRON (oracle) ERROR: failed to open PAM security session: Success CRON (oracle) ERROR: cannot set security context
这个问题的解决方案是为用户扩展密码：
# passwd -x 10 oracle
清空 crontab 时要小心
如果使用 crontab -e 删除所有 cron 作业，命令 crontab -l 仍将显示所有 cron 作业。
这是因为 crontab -e 不知道如何处理空的 crontab 文件。
所以它不会更新任何更改。
从 crontab 中删除所有作业的正确方法是：
# crontab -r
如何编辑 crontab
编辑 crontab 的最佳方法是使用命令 crontab -e 。
另一种方法是：
1. su to the user whose cron you want to change 2. crontab -l > file [ copy the crontab to a file ]. 3. vi file [ make changes to the file as per your need ] 4. crontab file [ this makes the "file" as new crontab ]
此后无需重新启动 cron 守护程序。
注意：如果我们错误地只运行了 crontab 命令，请不要尝试通过键入 CTRL+D 来退出，因为它会删除 crontab 文件中的所有条目。
使用 CTRL+C 退出 crontab 命令。