????????crond是Linux系统中用来定期执行命令或指定程序任务的一种服务或软件,与Windows下的计划任务类似。当安装完成操作系统后,默认会安装此服务工具,并且会自动启动crond进程。crond进程每分钟会定期检查是否有要执行的任务,如果有要执行的任务,则自动执行该任务。
????????Linux下的任务调度分为两类,系统任务调度和用户任务调度。系统任务调度是系统周期性所要执行的工作,比如写缓存数据到硬盘、日志清理等。在/etc目录下有一个crontab文件,这个就是系统任务调度的配置文件。
????????Linux下的crontab是一个用于设置周期性被执行的任务的工具。用户可以使用crontab命令来编辑、查看或删除定时任务。在Linux系统中,crontab命令常见于Unix和Linux的操作系统之中,用于设置周期性被执行的指令。
????????crontab储存的指令被守护进程激活,通常被称为cron jobs。crond在后台运行,每一分钟检查是否有预定的作业需要执行。如果使用控制文件被修改了,cron守护进程(crond)不必被重启,而是直接读取文件。
service crond start // 启动服务
service crond stop // 关闭服务
service crond restart // 重启服务
service crond reload // 重新载入配置
service crond status // 查看服务状态
????????安装完成操作系统后,默认会安装 crond 服务工具,且 crond 服务默认就是自启动的。crond 进程每分钟会定期检查是否有要执行的任务,如果有,则会自动执行该任务。
执行命令如下:
(base)[root@uat ~]#service crond start
Redirecting to /bin/systemctl start crond.service
(base)[root@uat ~]#service crond stop
Redirecting to /bin/systemctl stop crond.service
(base)[root@uat ~]#service crond restart
Redirecting to /bin/systemctl restart crond.service
(base)[root@uat ~]#service crond reload
Redirecting to /bin/systemctl reload crond.service
(base)[root@uat ~]#service crond status
Redirecting to /bin/systemctl status crond.service
● crond.service - Command Scheduler
Loaded: loaded (/usr/lib/systemd/system/crond.service; enabled; vendor preset: enabled)
Active: active (running) since 日 2023-12-24 16:16:49 CST; 12s ago
Process: 8293 ExecReload=/bin/kill -HUP $MAINPID (code=exited, status=0/SUCCESS)
Main PID: 7518 (crond)
Tasks: 1
Memory: 640.0K
CGroup: /system.slice/crond.service
└─7518 /usr/sbin/crond -n
12月 24 16:16:49 uat.drd.gzhxrcb systemd[1]: Started Command Scheduler.
12月 24 16:16:49 uat.drd.gzhxrcb crond[7518]: (CRON) INFO (RANDOM_DELAY will be scaled with factor 86% if used.)
12月 24 16:16:49 uat.drd.gzhxrcb crond[7518]: (CRON) INFO (running with inotify support)
12月 24 16:16:49 uat.drd.gzhxrcb crond[7518]: (CRON) INFO (@reboot jobs will be run at computer's startup.)
12月 24 16:16:55 uat.drd.gzhxrcb systemd[1]: Reloading Command Scheduler.
12月 24 16:16:55 uat.drd.gzhxrcb systemd[1]: Reloaded Command Scheduler.
12月 24 16:17:01 uat.drd.gzhxrcb crond[7518]: (CRON) INFO (running with inotify support)
????????crontab 命令是通过 /etc/cron.allow 和 /etc/cron.deny 文件来限制某些用户是否可以使用 crontab 命令的。
? ? ? ? 命令使用原则:
· 如果两个文件都不存在,则只有root用户才能使用crontab命令。
· 如果cron.allow存在, cron.deny不存在,则只有列在cron.allow文件里的用户才能使用crontab命令,如果root用户也不在里面,则root用户也不能使用crontab。
· 如果cron.deny存在, cron.allow不存在,则只有列在cron.deny文件里面的用户不能使用crontab命令,其它用户都能使用。
· /etc/cron.allow优先级高于/etc/cron.deny
· 都存在情况下,只有写入/etc/cron.allow文件的用户可以使用 crontab 命令,没有写入的用户不能使用 crontab 命令。若用户同时有/etc/cron.allow和/etc/cron.deny中,则/etc/cron.deny被忽略。
? ? ? ? Linux系统默认只有/etc/cron.deny文件,如下图所示:
[root@localhost ~]# crontab [选项] [file]
说明:
示例:
????????查看内在使用情况:
? ? ? ? 有一天我发现框中的区域即缓存的内存非常的高,可用内在非常的低,有一些应用启动不起来,于是写了一个清缓存的脚本,如下:
[root@drd app]# vi cleanBuffCache.sh
#!/bin/bash
echo "开始清理缓存"
# 写入硬盘,防止数据丢失
sync;sync;sync;
# 延迟10S
sleep 10
echo 1 > /proc/sys/vm/drop_caches
echo 2 > /proc/sys/vm/drop_caches
echo 3 > /proc/sys/vm/drop_caches
echo "清理缓存结束"
? ? ? ? 然后配置crontab如下:
[root@drd app]# crontab -e
0 0 * * * /home/***文件绝对路径***/cleanBufferCache.sh
????????当“crontab -e”编辑完成之后,一旦保存退出,那么这个定时任务实际就会写入 /var/spool/cron/ 目录中,每个用户的定时任务用自己的用户名进行区分。而且 crontab 命令只要保存就会生效,只要 crond 服务是启动的。
????????然后使用 service crond reload 命令重新载入配置,使刚刚配的任务生效。(或者用service crond restart?或?service crond stop?再service crond start?均可)
语法:
minute hour day month week command
? ? ? ? 如上配置0 0 * * * /home/***文件绝对路径***/cleanBufferCache.sh
特殊符号说明:
示例:
配置规则 | 说明 |
45 22 * * * | 在 22 点 45 分执行命令 |
0 17 * * 1 | 在每周一的 17 点 0 分执行命令 |
0 5 1,15 * * | 在每月 1 日和 15 日的凌晨 5 点 0 分执行命令 |
40 4 * * 1-5 | 在每周一到周五的凌晨 4 点 40 分执行命令 |
*/10 4 * * * | 在每天的凌晨 4 点,每隔 10 分钟执行一次命令 |
0 0 1,15 * | 在每月 1 日和 15 日,每周一个 0 点 0 分都会执行命令,注意:星期几和几日最好不要同时出现,因为它们定义的都是天,非常容易让管理员混淆 |
0 6 * * * | 每天早上6点执行 |
0 */2 * * * | 每两个小时 |
0 11 4 * 1-3 | 每个月的4号和每个礼拜的礼拜一到礼拜三的早上11点 |
0 4 1 1 * | 1月1日早上4点 |
推荐Crontab命令?执行时间工具网站:crontab执行时间计算 - 在线工具,可以此网站来测试和验证CRON表达式的执行计划。? ?
易踩坑:2.2?第六个参数 command是一个可执行命令和可执行的文件,若此参数是文件一定要把这个文件的权限修改为可执行的文件,否则不生效。