A New Start

踩坑记:linux定时器crontab错误 mysql command not found

一、背景介绍

    此篇文章讲述自己的踩坑血泪史之一。

    故事发生在公元2018年,那年风和日丽,接到了新任务:将之前在服务器A上运行的定时备份数据库的任务迁移至服务器B。(上次介绍的定时备份的文章链接

    呵呵,这哪里能称得上任务,举手之劳罢了,后来发现,自己太年轻。

        step1:移动 shell 脚本并调整部分参数

        step2:创建备份数据放置的文件夹

        step3:调整脚本和文件夹的权限

        step4:调整 crontab 定时任务,并重新加载了crontab 的配置: service crond reload

    好,完事儿,手动跑了遍脚本,没有发现任何问题,于是等着测试定时任务了,但是发现到了设置的时间点数据并没有自动备份下来,接下来就开始了此次的挖坑故事。

二、挖坑

    手动可以运行的脚本,却无法自动运行?what?两者都是 root 用户的操作,于是首先先对比了服务器A和B上的脚本、文件夹、定时任务的异同,

    然而并没有发现有任何的不一样,

    于是查看了权限,权限也一样,但是仔细查看时候发现了一丝丝猫腻,服务器B的文件权限后面跟了一个点,而服务器A的文件后面却没有,不仔细看还真看不出来。

        (后补的图,忽略X权限)

    crontab mysql commond not find 05.png

    好了,问题找到了,SELinux(Secure Enhanced Linux), 关乎 linux 的安全策略机制,(具体介绍暂不进行描述,在下只理解了一点点小精髓,并不深入)

    于是狠狠补了一课,研究了一天,很是兴奋。

    

三、踩坑

    既然问题找到了,那就试着解决吧。

    SELinux的工作模式一共有三种 enforcing、permissive和disabled  

        ① enforcing  强制模式:只要是违反策略的行动都会被禁止,并作为内核信息记录

        ② permissive 允许模式:违反策略的行动不会被禁止,但是会提示警告信息 

        ③ disabled  禁用模式:禁用SELinux,与不带SELinux系统是一样的,通常情况下我们在不怎么了解SELinux时,将模式设置成disabled,这样在访问一些网络应用时就不会出问题了。

    SELinux 的主配置文件是 /etc/sysconfig/selinux,可以查看配置文件来查看工作模式。

        crontab mysql commond not find 06.png

    或者可以使用 getenforce  命令来查看

        crontab mysql commond not find 07.png

    当然了,此时也可以使用 setenforce [0|1]  命令来修改工作模式,setenforce 0 表示设置成 permissive,1 表示 enforcing

        【注:】但是这是临时的解决方式,重启计算机之后便无效了,要想永久生效,只能修改上文提到的配置文件。

    于是我临时调整:setenforce 0

    但是之后经过测试,仍不能解决问题,那么久采取了极端的做法,修改配置文件。

    于是就挑选了一个月黑风高夜,良辰吉日时,修改了配置文件,重启了服务器。

    满怀欣喜地进行测试,还是失败。瞬间受挫。

四、填坑

    那么就继续硬着头皮填坑吧。

    老规矩,翻日志。

    这次翻看的是root 用户的邮箱:tail -f /var/spool/mail/root   

    我们找到了错误踪迹:

    crontab mysql commond not find 01.png

    错误很明显,我们脚本内的 mysql 命令,在服务器上并没找到,

    于是指定了两步走战略:

        ① 查询 crontab 定时任务配置内引入的 bin 文件夹路径:

            crontab mysql commond not find 02.png

        ② 查询当前服务器上 mysql 服务的执行路径

            crontab mysql commond not find 03.png

    果然,服务器 B 上面的mysql默认的安装路径并没有添加在定时任务的列表里面。

    接下来问题就相当好解决了,有两种方法:

        ① 直接将 mysql 的执行文件路径 /usr/local/mysql/bin 添加到定时任务内

        ② 或者可以建立软连接,

            crontab mysql commond not find 04.png

    

    然后下面就是见证奇迹的环节了,当然,问题肯定得到了解决。

五、小结

    小结一下下,此次踩坑的缘由很简单,由于出问题的时候并没有第一时间查看日志,所以饶了一点弯路。

    不过收货也颇丰,顺便又回顾了一遍 SELinux。

    最后,重要的事情说三遍,日志很重要,日志很重要,日志很重要,问题基本上都是可以通过查看日志解决的,但是前提是:日志要详细并且精准到位。

点赞

发表评论

电子邮件地址不会被公开。 必填项已用*标注