一、背景介绍
此篇文章讲述自己的踩坑血泪史之一。
故事发生在公元2018年，那年风和日丽，接到了新任务：将之前在服务器A上运行的定时备份数据库的任务迁移至服务器B。（上次介绍的定时备份的文章链接）
呵呵，这哪里能称得上任务，举手之劳罢了，后来发现，自己太年轻。
step1：移动 shell 脚本并调整部分参数
step2：创建备份数据放置的文件夹
step3：调整脚本和文件夹的权限
step4：调整 crontab 定时任务，并重新加载了crontab 的配置： service crond reload
好，完事儿，手动跑了遍脚本，没有发现任何问题，于是等着测试定时任务了，但是发现到了设置的时间点数据并没有自动备份下来，接下来就开始了此次的挖坑故事。
</p>
二、挖坑
手动可以运行的脚本，却无法自动运行？what？两者都是 root 用户的操作，于是首先先对比了服务器A和B上的脚本、文件夹、定时任务的异同，
然而并没有发现有任何的不一样，
于是查看了权限，权限也一样，但是仔细查看时候发现了一丝丝猫腻，服务器B的文件权限后面跟了一个点，而服务器A的文件后面却没有，不仔细看还真看不出来。
（后补的图，忽略X权限）
好了，问题找到了，SELinux(Secure Enhanced Linux)， 关乎 linux 的安全策略机制，（具体介绍暂不进行描述，在下只理解了一点点小精髓，并不深入）
于是狠狠补了一课，研究了一天，很是兴奋。
三、踩坑
既然问题找到了，那就试着解决吧。
SELinux的工作模式一共有三种 enforcing、permissive和disabled
① enforcing 强制模式：只要是违反策略的行动都会被禁止，并作为内核信息记录
② permissive 允许模式：违反策略的行动不会被禁止，但是会提示警告信息
③ disabled 禁用模式：禁用SELinux，与不带SELinux系统是一样的，通常情况下我们在不怎么了解SELinux时，将模式设置成disabled，这样在访问一些网络应用时就不会出问题了。
SELinux 的主配置文件是 /etc/sysconfig/selinux，可以查看配置文件来查看工作模式。
或者可以使用 getenforce 命令来查看
当然了，此时也可以使用 setenforce [0|1] 命令来修改工作模式，setenforce 0 表示设置成 permissive，1 表示 enforcing
【注：】但是这是临时的解决方式，重启计算机之后便无效了，要想永久生效，只能修改上文提到的配置文件。
于是我临时调整：setenforce 0
但是之后经过测试，仍不能解决问题，那么久采取了极端的做法，修改配置文件。
于是就挑选了一个月黑风高夜，良辰吉日时，修改了配置文件，重启了服务器。
满怀欣喜地进行测试，还是失败。瞬间受挫。
四、填坑
那么就继续硬着头皮填坑吧。
老规矩，翻日志。
这次翻看的是root 用户的邮箱：tail -f /var/spool/mail/root
我们找到了错误踪迹：
错误很明显，我们脚本内的 mysql 命令，在服务器上并没找到，
于是指定了两步走战略：
① 查询 crontab 定时任务配置内引入的 bin 文件夹路径：
② 查询当前服务器上 mysql 服务的执行路径
果然，服务器 B 上面的mysql默认的安装路径并没有添加在定时任务的列表里面。
接下来问题就相当好解决了，有两种方法：
① 直接将 mysql 的执行文件路径 /usr/local/mysql/bin 添加到定时任务内
② 或者可以建立软连接，
然后下面就是见证奇迹的环节了，当然，问题肯定得到了解决。
五、小结
小结一下下，此次踩坑的缘由很简单，由于出问题的时候并没有第一时间查看日志，所以饶了一点弯路。
不过收货也颇丰，顺便又回顾了一遍 SELinux。
最后，重要的事情说三遍，日志很重要，日志很重要，日志很重要，问题基本上都是可以通过查看日志解决的，但是前提是：日志要详细并且精准到位。