*代表取值范围内的数字
/代表”每”,
-代表从某个数字到某个数字,
,分开几个离散的数字
crontab -e //然后添加相应的任务，wq存盘退出
crontab -l //列出当前的所有调度任务
crontab -l -u jp //列出用户jp的所有调度任务
crontab -r //删除所有任务调度工作| 分 | 小时 | 日 | 月 | 星期 | 命令 |
|---|---|---|---|---|---|
| 0-59 | 0-23 | 1-31 | 1-12 | 0-6 | command (取值范围,0表示周日一般一行对应一个任务) |
| 每个小时的第几分钟执行该任务 | 每天的第几个小时执行该任务 | 每月的第几天执行该任务 | 每年的第几个月执行该任务 | 每周的第几天执行该任务 | 指定要执行的程序 |
//指定每小时的第5分钟执行一次ls命令
5 * * * * ls
//指定每天的 5:30 执行ls命令
30 5 * * * ls
//指定每月8号的7：30分执行ls命令
30 7 8 * * ls
//指定每年的6月8日5：30执行ls命令
30 5 8 6 * ls
//指定每星期日的6:30执行ls命令[注：0表示星期天，1表示星期1，以此类推，也可以用英文来表示，sun表示星期天，mon表示星期一等。]
30 6 * * 0 ls
//每月10号及20号的3：30执行ls命令[注：“，”用来连接多个不连续的时段]
30 3 10,20 * * ls
//每天8-11点的第25分钟执行ls命令[注：“-”用来连接连续的时段]
25 8-11 * * * ls
//每15分钟执行一次ls命令 [即每个小时的第0 15 30 45 60分钟执行ls命令 ]
*/15 * * * * ls
//每个月中，每隔10天6:30执行一次ls命令[即每月的1、11、21、31日是的6：30执行一次ls 命令。 ]
30 6 */10 * * ls
//每天7：50以root 身份执行/etc/cron.daily目录中的所有可执行文件[注：run-parts参数表示，执行后面目录中的所有可执行文件。 ]
50 7 * * * root run-parts /etc/cron.daily
为什么手动执行一切正常，放到 CRON 里就不执行呢？
实际上此类问题多半是因为环境变量导致的，答案就在配置文件里：
shell> cat /etc/crontab
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
HOME=/
# For details see man 4 crontabs
# Example of job definition:
# .---------------- minute (0 - 59)
# | .------------- hour (0 - 23)
# | | .---------- day of month (1 - 31)
# | | | .------- month (1 - 12) OR jan, ...
# | | | | .---- day of week (0 - 6) (Sunday=0 or 7) OR sun, ...
# | | | | |
# * * * * * user-name command to be executed
比如说，你的 PHP 命令位于 /usr/loca/bin 目录，而你在 profile 里已经把这个目录加到了环境变量 PATH 里，不过 crontab 里可没有 /usr/loca/bin 目录，于是就出问题了。对付此类问题的方法很简单，那就是设置 CRON的时候尽可能使用完整的全路径。
此外，有人喜欢直接在 /etc/crontab 里配置定时任务，这同样是十恶不赦的做法，多数时候，我们都
应该使用 crontab -e 的方法来设置，原因是这样有语法检查 。
设置一个 PHP 脚本，每分钟执行一次，怎么搞？听起来这分明就是一道送分题啊：
* * * * * /path/to/php /path/to/file让我们设想如下情况：假如上一分钟的 A 请求还没退出，下一分钟的 B 请求也启动了，就会导致出现 AB 同时请求的情况，如何避免？
答案是 flock，它实现了锁机制：
flock -xn /tmp/lock /path/to/php /path/to/file让我们再来重放一下故障场景：假如上一分钟的 A 请求还没退出，下一分钟的 B 请求也启动了，那么 B 请求会发现 A 请求还没有释放锁，于是它不会执行。
看起来似乎完美解决了问题，不过让我们在加入一点特殊情况：假如因为某些无法预知的原因，导致脚本不能正常结束请求，进而导致不能正常释放锁，那么后续所有其它的 CD 等请求也都无法执行了，如何避免？
答案是 timeout，它实现了超时控制机制：
timeout -s SIGINT 100 flock -xn /tmp/lock /path/to/php /path/to/file让我们再来重放一下故障场景：假如上一分钟的 A 请求还没退出，下一分钟的 B 请求也启动了，那么 B 请求会发现 A 的请求还没有释放锁，于是它不会执行，不过下下分钟的 C 请求肯定能执行，因为在这之前，A 请求已经因为超时被 timeout 干掉了。