Linux crontab命令 被用来提交和管理用户的需要周期性执行的任务，与windows下的计划任务类似，当安装完成 *** 作系统后，默认会安装此服务工具，并且会自动启动crond进程，crond进程每分钟会定期检查是否有要执行的任务，如果有要执行的任务，则自动执行该任务。
crontab文件：指定包含待执行任务的crontab文件。
Linux下的任务调度分为两类：系统任务调度和用户任务调度。
系统任务调度：系统周期性所要执行的工作，比如写缓存数据到硬盘、日志清理等。在/etc目录下有一个crontab文件，这个就是系统任务调度的配置文件。
/etc/crontab文件包括下面几行：
前四行是用来配置crond任务运行的环境变量，第一行SHELL变量指定了系统要使用哪个shell，这里是bash，第二行PATH变量指定了系统执行命令的路径，第三行MAILTO变量指定了crond的任务执行信息将通过电子邮件发送给root用户，如果MAILTO变量的值为空，则表示不发送任务执行信息给用户，第四行的HOME变量指定了在执行命令或者脚本时使用的主目录。
用户任务调度：用户定期要执行的工作，比如用户数据备份、定时邮件提醒等。用户可以使用 crontab 工具来定制自己的计划任务。所有用户定义的crontab文件都被保存在/var/spool/cron目录中。其文件名与用户名一致，使用者权限文件如下：
/etc/cron.deny 该文件中所列用户不允许使用crontab命令
/etc/cron.allow 该文件中所列用户允许使用crontab命令
/var/spool/cron/ 所有用户crontab文件存放的目录,以用户名命名
crontab文件的含义：用户所建立的crontab文件中，每一行都代表一项任务，每行的每个字段代表一项设置，它的格式共分为六个字段，前五段是时间设定段，第六段是要执行的命令段，格式如下：
minute hour day month week command 顺序：分 时 日 月 周
其中：
在以上各个字段中，还可以使用以下特殊字符：
/sbin/service crond start //启动服务
/sbin/service crond stop //关闭服务
/sbin/service crond restart //重启服务
/sbin/service crond reload //重新载入配置
查看crontab服务状态：
service crond status
手动启动crontab服务：
service crond start
查看crontab服务是否已设置为开机启动，执行命令：
ntsysv
加入开机自动启动：
chkconfig –level 35 crond on
每1分钟执行一次command
每小时的第3和第15分钟执行
在上午8点到11点的第3和第15分钟执行
每隔两天的上午8点到11点的第3和第15分钟执行
每个星期一的上午8点到11点的第3和第15分钟执行
每晚的21:30重启smb
每月1、10、22日的4 : 45重启smb
每周六、周日的1:10重启smb
每天18 : 00至23 : 00之间每隔30分钟重启smb
每星期六的晚上11:00 pm重启smb
每一小时重启smb
晚上11点到早上7点之间，每隔一小时重启smb
每月的4号与每周一到周三的11点重启smb
一月一号的4点重启smb
每小时执行/etc/cron.hourly目录内的脚本
经过排查，结果显而易见，crontab执行脚本时缺少用户手工执行脚本时的一些环境变量。用户在登录服务器时，会默认加载当前用户的环境变量（用户环境变量的配置以及加载不在此做过多赘述）。而crontab就不一定了，以老的AIX环境为例，crontab是会拥有当前用户的环境变量的，这也是为什么之前都是正常运行的；而新的Linux环境，明显就是必须要显示地引入当前用户的环境变量，否则会出现一系列问题。
实际上，一开始我是不建议将当前用户的所有环境变量都引入的，毕竟权限大了，谁也控制不住。我的想法是引入部分必要的环境变量就好，其他的环境变量，要用时再说。但是作为一名开发人员，我对Linux运维这块并不是过多了解，于是就找了公司里相关的运维老师。然而，在重试多次后，那位运维老师直接将当前用户的所有环境变量都引入了，简单粗暴。然后我就在嘀咕“问题原因我早就找到了，我只是想要一个最优解，然而你却把我最初的想法告诉了我，那我岂不是舍近求远？？？”。最后在项目组成员都本着“能正常运行就行”的基本原则，还是采用了全量引入当前用户环境变量的方法。
有两种引入方式：
1.在crontab中引用当前用户环境变量
2.在脚本中引用当前用户环境变量
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）