Linux中定时任务依赖cron服务，通过crontab -e编辑任务，每行按“分 时 日 月 周 命令”格式定义，支持特殊字符与@预设，需注意环境变量、路径、权限及输出重定向问题，调试可查日志、手动模拟或重定向输出。
Linux中定时执行任务的核心工具是
cron
，它允许你设置在特定时间或间隔自动运行命令或脚本。通过编辑
crontab
文件，你可以精确地定义这些自动化任务，让系统在无人值守的情况下高效工作。
要在Linux中设置定时任务，我们主要依赖
cron
服务。它就像一个幕后的管家，按照你给定的时间表，准时执行指定的命令或脚本。这个时间表就存储在
crontab
文件中。
首先，你需要打开你的用户
crontab
文件进行编辑。这通常通过以下命令完成：
crontab -e
如果你是第一次使用，系统可能会让你选择一个文本编辑器，比如
vim
或
nano
。选择你熟悉的就好。
crontab
文件的每一行代表一个独立的计划任务，其格式遵循一个特定的模式：
分钟 小时 日 月 周 命令
具体来说：
- 分钟 (0-59)
- 小时 (0-23)
- 日 (1-31)
- 月 (1-12)
- 周 (0-7，其中0和7都代表星期日)
这些字段可以使用以下特殊字符：
-
*
: 匹配所有可能的值。例如，*
在“分钟”字段意味着每分钟。 -
,
: 列举值。例如，1,15,30
在“分钟”字段意味着在第1、15、30分钟执行。 -
-
: 范围。例如，9-17
在“小时”字段意味着从上午9点到下午5点。 -
/
: 步长。例如，*/5
在“分钟”字段意味着每5分钟。 -
@reboot
: 系统启动时执行。 -
@hourly
,@daily
,@weekly
,@monthly
,@yearly
: 方便的预设时间。
举几个例子：
-
每天凌晨3点30分执行一个脚本：
30 3 * * * /path/to/your/script.sh
-
每周一、三、五的上午9点执行一个命令：
0 9 * * 1,3,5 /usr/bin/some_command
-
每10分钟执行一次日志清理脚本：
*/10 * * * * /path/to/clean_logs.sh
需要注意的是，
cron
执行任务时的环境可能和你的交互式shell环境不同，所以最好使用命令的完整路径，或者在脚本中明确设置
PATH
变量。另外，任何输出（标准输出和标准错误）都会默认通过邮件发送给
crontab
的所有者，这在调试时很有用，但如果任务频繁且输出量大，可能会导致邮箱被塞满。你可以通过重定向输出到
/dev/null
来避免这种情况：
*/10 * * * * /path/to/clean_logs.sh > /dev/null 2>&1
保存并退出编辑器后，
cron
服务会自动加载你的新配置。如果需要查看当前用户的计划任务列表，可以使用：
crontab -l
要删除所有计划任务，可以使用：
crontab -r
对于系统级别的定时任务，你可以编辑
/etc/crontab
文件，或者将脚本放入
/etc/cron.hourly
,
/etc/cron.daily
,
/etc/cron.weekly
,
/etc/cron.monthly
等目录。这些目录下的脚本会由
cron
服务按照预设的频率自动执行。不过，对于普通用户来说，使用
crontab -e
来管理自己的任务通常更安全、更方便。
cron任务执行失败了怎么办？如何排查和调试？
cron
任务执行失败，这几乎是每个用
cron
的人都会遇到的“经典”问题。我个人就没少在这上面花时间，尤其是在脚本在命令行下跑得好好的，一进
cron
就“哑火”的时候。排查这类问题，其实是有套路的。
最直接的线索通常在日志里。
cron
服务本身会记录任务的执行情况，尽管它不会把脚本内部的错误信息全部打印出来。你通常可以在
/var/log/syslog
或
/var/log/cron.log
（具体位置可能因Linux发行版而异）中找到
cron
尝试执行任务的记录。看看有没有
CRON
相关的错误信息，比如权限问题，或者命令找不到。
然后，一个非常常见的“坑”是环境差异。当你通过
SSH
登录系统执行命令时，你拥有一个完整的用户环境，包含各种环境变量，比如
PATH
。但
cron
执行任务时，它通常在一个非常简陋的环境下运行，
PATH
变量可能只包含
/usr/bin:/bin
等少数几个路径。这意味着如果你在脚本里调用了某个命令，而这个命令不在
cron
的默认
PATH
里，它就找不到。 解决方案：
-
使用命令的绝对路径： 例如，不要只写
python script.py
，而是写/usr/bin/python /path/to/script.py
。 -
在脚本开头设置
PATH
： 在你的脚本顶部加上一行export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
，或者根据需要添加其他路径。 -
在
crontab
文件顶部设置SHELL
和PATH
：SHELL=/bin/bash PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin * * * * * /path/to/your/script.sh
再来就是脚本本身的权限问题。确保你的脚本有执行权限：
chmod +x /path/to/your/script.sh
如果脚本内部有错误，
cron
默认会将标准输出和标准错误通过邮件发送给
crontab
的所有者。但很多服务器可能没有配置邮件服务，或者你根本不看邮件。这时，最有效的调试方法是将脚本的输出重定向到一个文件：
* * * * * /path/to/your/script.sh > /tmp/cron_debug.log 2>&1
这样，脚本运行时的所有输出和错误都会写入
/tmp/cron_debug.log
文件。你可以查看这个文件来发现脚本内部的错误信息。
手动测试也是不可或缺的一步。在命令行下，以
cron
运行的相同用户身份，手动执行你的脚本。
sudo -u your_username /path/to/your/script.sh
这样可以模拟
cron
的环境，看看脚本是否能正常运行。
最后，别忘了用户上下文。你设置的
crontab -e
任务是以你当前用户身份运行的。如果你的脚本需要访问只有
root
用户才能访问的文件或执行
root
权限才能执行的操作，那它肯定会失败。这种情况下，你可能需要考虑使用
root
用户的
crontab
(
sudo crontab -e
)，或者在脚本内部使用
sudo
（但要小心配置
