Linux定时任务crontab详解

Linux crontab是自动化任务神器，简单用，先装再编辑。

安装crontab，RedHat系用yum，Debian系用apt-get。

配置文件懂，/etc/crontab是主，/var/spool/cron/用户名是个人。

添加任务，先写脚本，crontab-e编辑，指定时间执行。

查看任务，crontab-l，看当前用户，-u用户名看特定用户。

删除任务，crontab-e编辑删除，或crontab-r彻底删除。

特殊符号用，代表所有，/,代表步长，-代表区间。

脚本规范，注释，路径，命令路径，权限要全。

示例任务，日志清理每天2 点，时间同步每5 分钟，数据库备份每周一。

问题解决，权限路径查，日志看，环境变量显式设置。

你自己掂量。

linux定时任务--crontab

crontab这玩意儿，说实话，我以前用得挺多的。
你说的都挺对的。

就拿我几年前在杭州的一家公司干运维那会儿说吧，有个服务器要定期备份数据，我就用crontab搞定了。
那时候用的是CentOS 6 ，我直接在终端敲 service crond stop，把定时任务服务关了，为啥？怕它出啥幺蛾子。
然后 service crond start，再开起来。
后来发现备份脚本出了点小bug，赶紧 service crond restart，把服务重启了，脚本立马修正了，又恢复正常了。

还有一次，在武汉的一个项目上，用的是CentOS 7 那会儿我需要把cron服务自启动给关了，防止服务器一重启它就乱跑。
我就用 systemctl disable crond.service，弄好了。
过两天项目结束了，我又得把它开起来，就 systemctlenablecrond.service，搞定。

关于编辑任务，我一般都习惯用 crontab -e，直接进去编辑就好了。
记得有一次，我写任务的时候格式写错了，结果那个任务就没执行。
把我急得，赶紧 crontab -l 查看一下，发现是哪行错了，改了之后保存，任务又正常了。

格式你说的那个 minute hour day month week command，我完全懂。
我以前让一个任务每五分钟运行一次，就直接写 /5 /path/to/script.sh。
还有个任务，每个月1 号凌晨3 点执行，我写的是 0 3 1 /path/to/script.sh。
用逗号和横杠也挺多的，比如星期几要执行周二和周五，我就写 2 ,5 /path/to/script.sh。
隔半小时执行一次，我就写 0-2 3 /2 /path/to/script.sh，这个我常用。

不过啊，要说那些特殊字符啥的，我印象最深的是那个 /，指定间隔频率。
我有个监控脚本，每五分钟看一次服务器状态，我写的是 /5 /path/to/monitor.sh。
简单明了。

总的来说，crontab这东西用好了，能省不少事儿。
就是格式得记牢，别写错了。
你还有啥不明白的，直接问我哈。

linux利用shell脚本与crontab自动检测进程并定时重启

壳脚引号三种，单双反各不同。
单引号里，变量转义无。
双引号里，变量转义活。
反引号命令，先执行再替换。

建脚本用vim，文件名要记牢。
路径对了就创建，编辑随意挑。

crontab任务加，时间设定要准确。
每分钟执行一次，日志记录很重要。
错误日志别漏，系统安全最重要。

桌面程序执行难，环境变量要调。
DISPLAY环境设，终端模式先打开。

壳脚与crontab，进程监控好帮手。
运维工作简化了，效率稳定不用愁。
记得安全与兼容，执行效果才最好。

你自己看，还有什么问题没解决？

如何在Linux中定时执行任务？使用cron命令设置计划任务自动化

说实话，搞Linux定时任务这事儿，我当年也是摸着石头过河。
不过话说回来，crontab这玩意儿一旦用顺了，效率确实能提起来一大截。
我给你细说说我的心得，可能有点啰嗦，但都是踩坑总结出来的。

先说编辑用户级任务。
记得第一次用crontab-e的时候，系统让我选编辑器，我就直接选了vim，结果卡死好几次。
后来改用nano，这老哥是真顺手。
你注意看那格式，分钟时日月周命令，这个顺序千万别乱。
比如我要每天凌晨3 点3 0分跑个备份脚本，就写成"3 03 /home/user/backup.sh"。
最坑我的是周字段，0和7 都代表周日，新手容易搞混。

有意思的是，特殊字符的用法特别直观。
比如/1 0/path/to/clean_logs.sh，这个我用了超多，日志清理任务用着特顺手。
还有那个@reboot，我当年给新服务器装完系统后，第一件事就是用这个自动配置监控脚本。
不过要注意，@reboot任务得放在crontab的特别位置，不是随便放就行。

管理任务的时候，crontab-l这命令简直是我的本命。
半夜醒来发现备份失败了，点开看看是不是时间设错了，一秒搞定。
至于删除任务，crontab-r慎用，我见过同事不小心把所有任务删光的案例，那场面...算了，反正现在都用软删除，错了还能回滚。

系统级任务这块，我建议别直接碰/etc/crontab，除非你懂得够深。
我一般是把脚本扔到/etc/cron.daily，然后让cron每天凌晨自动跑。
有个坑是，这些系统任务默认用root身份执行，所以如果脚本需要访问普通用户文件，会报权限错。
我当时就为这事折腾了半天，最后在脚本里加了sudo命令，结果发现sudo配置太复杂，又绕回用root用户，你说这事儿闹的。

环境变量差异也是老问题。
我有个朋友，每次用cron执行python脚本，总提示找不到模块。
后来发现是PATH变量不一样。
我的建议是，crontab里强制写PATH=/usr/local/bin:/bin，或者直接用绝对路径，比如"/usr/bin/python3 "。
这个教训太深刻了，现在写crontab必带PATH设置。

输出重定向这事儿，我一开始完全没注意。
结果半夜邮件收到手软，全是脚本错误日志。
后来改成">>/var/log/cron.log"，问题立马解决。
不过要注意，如果脚本输出特别大，比如数据库备份，log文件可能会撑爆硬盘，得加个清理逻辑。

调试的时候，我习惯用crontab -l | grep "任务名"，快速定位问题。
更绝的是，你可以sudo -u username bash，手动执行cron命令，看看环境对不对。
我当年排查过脚本找不到某个jar包的问题，就是用这招发现的。
还有个骚操作，crontab任务执行完不产生邮件，但cron日志里会有记录，路径看发行版而定，Debian一般是/var/log/syslog。

总的来说，crontab用好了真省事。
但新手千万别把@reboot和星期0搞混，也别忘了给脚本加执行权限。
还有，如果你在脚本里用了sudo，记得测试下sudoers配置，别出现提权漏洞。
这些细节，说多了都是血泪史啊。