一、背景介绍
此篇文章讲述自己的踩坑血泪史之一。故事发生在公元2018年,那年风和日丽,接到了新任务:将之前在服务器A上运行的定时备份数据库的任务迁移至服务器B。(上次介绍的定时备份的文章链接)
呵呵,这哪里能称得上任务,举手之劳罢了,后来发现,自己太年轻。
step1:移动 shell 脚本并调整部分参数
step2:创建备份数据放置的文件夹
step3:调整脚本和文件夹的权限
step4:调整 crontab 定时任务,并重新加载了crontab 的配置: service crond reload
好,完事儿,手动跑了遍脚本,没有发现任何问题,于是等着测试定时任务了,但是发现到了设置的时间点数据并没有自动备份下来,接下来就开始了此次的挖坑故事。
二、挖坑
手动可以运行的脚本,却无法自动运行?what?两者都是 root 用户的操作,于是首先先对比了服务器A和B上的脚本、文件夹、定时任务的异同,然而并没有发现有任何的不一样,
于是查看了权限,权限也一样,但是仔细查看时候发现了一丝丝猫腻,服务器B的文件权限后面跟了一个点,而服务器A的文件后面却没有,不仔细看还真看不出来。
(后补的图,忽略X权限)

三、踩坑
既然问题找到了,那就试着解决吧。 SELinux的工作模式一共有三种 enforcing、permissive和disabled ① enforcing 强制模式:只要是违反策略的行动都会被禁止,并作为内核信息记录 ② permissive 允许模式:违反策略的行动不会被禁止,但是会提示警告信息 ③ disabled 禁用模式:禁用SELinux,与不带SELinux系统是一样的,通常情况下我们在不怎么了解SELinux时,将模式设置成disabled,这样在访问一些网络应用时就不会出问题了。 SELinux 的主配置文件是 /etc/sysconfig/selinux,可以查看配置文件来查看工作模式。

于是我临时调整:setenforce 0 但是之后经过测试,仍不能解决问题,那么久采取了极端的做法,修改配置文件。
于是就挑选了一个月黑风高夜,良辰吉日时,修改了配置文件,重启了服务器。
满怀欣喜地进行测试,还是失败。瞬间受挫。
四、填坑
那么就继续硬着头皮填坑吧。老规矩,翻日志。
这次翻看的是root 用户的邮箱:tail -f /var/spool/mail/root
我们找到了错误踪迹:

于是指定了两步走战略: ① 查询 crontab 定时任务配置内引入的 bin 文件夹路径:


接下来问题就相当好解决了,有两种方法:
① 直接将 mysql 的执行文件路径 /usr/local/mysql/bin 添加到定时任务内 ② 或者可以建立软连接,

五、小结
小结一下下,此次踩坑的缘由很简单,由于出问题的时候并没有第一时间查看日志,所以饶了一点弯路。不过收货也颇丰,顺便又回顾了一遍 SELinux。 最后,重要的事情说三遍,日志很重要,日志很重要,日志很重要,问题基本上都是可以通过查看日志解决的,但是前提是:日志要详细并且精准到位。

文章评论