上午正在开会,突然收到rgw服务异常的告警(503 Service Unavailable),立马停下来处理告警,避免影响到用户~
我们的rgw frontend用的是apache,之前也遇到过503的问题,经验上反应出应该是/var/run/ceph的目前权限出了问题导致apache进程无法访问到rgw的fastcgi.sock文件,从而导致503。按这个思路去查,果然,所有rgw机子的/var/run/ceph(owner和group均为ceph)的权限都从0777变成了0770!!!
恢复服务为重,先把所有的权限修改正确,再细查权限变化的原因~
那么问题来了,到底是谁修改了/var/run/ceph的权限?
尝试在网上寻找类似的问题,没有发现,自力更生~
嫌疑人 | 分析 |
---|---|
人为 | rgw这些机子和服务是由我负责的,应该不会有人操作这些机子,暂时排除这个可能 |
cron任务 | 没有找到可能做修改的周期性任务 |
ceph组件进程 | ceph各组件已经稳定运行了一年多,服务一直正常,而且组件进程也没有重启过,组件进程修改的可能性较小 |
... | :( |
当你迷茫的时候,不妨看看源码,在ceph的源码中搜索“/run/ceph”,发现了这样的一个文件systemd/ceph.tmpfiles.d,内容是这样的:
d /run/ceph 0770 ceph ceph -
我们的/var/run/ceph目录就是被改成了0770权限,直觉告诉我们,遇到的问题跟这个目录有千丝万缕的联系... 从ceph.spec.in看出,这个文件最终安装成了/usr/lib/tmpfiles.d/ceph-common.conf ,涉及到systemd tmpfiles机制,临时抱佛脚学习下 systemd tmpfiles机制 ~
d /run/ceph 0770 ceph ceph -
对于这条配置,开机时systemd-tmpfiles-setup服务会创建owner和group为ceph、权限为0700的目录/run/ceph;而systemd-tmpfiles-clean服务会周期性(周期为天,可通过systemctl list-timers --all查看)遍历/run/ceph下的文件,根据配置来进行删除,这里配置的是“-”,意为不进行删除
而systemd-tmpfiles-setup服务最终执行的命令为:
/usr/bin/systemd-tmpfiles --create --remove --boot --exclude-prefix=/dev
做个测试,我们创建了内容为“d /run/test 0770 ceph ceph -”的文件/usr/lib/tmpfiles.d/test.conf,然后执行上述命令,果不其然,/run/test目录创建出来了:
root@c144:~$ ll /run/ |grep test
drwxrwx--- 2 ceph ceph 40 Jan 17 09:26 test
我们把/usr/lib/tmpfiles.d/test.conf内容改成“d /run/test 0777 ceph ceph -”,再执行命令,权限发生了变化:
root@c144:~$ ll /run/ |grep test
drwxrwxrwx 2 ceph ceph 40 Jan 17 09:26 test
那问题又来了, 谁调用了/usr/bin/systemd-tmpfiles?
不卖官司了...是这样的:
运维人员更新了systemd的rpm,而systemd rpm的post install脚本调用了该/usr/bin/systemd-tmpfiles,修改了/run/ceph的权限,而/var/run是软链到/run的,最终导致了服务异常
rpm -q --scripts systemd:
...
systemctl start systemd-udevd.service >/dev/null 2>&1 || :
udevadm hwdb --update >/dev/null 2>&1 || :
journalctl --update-catalog >/dev/null 2>&1 || :
systemd-tmpfiles --create >/dev/null 2>&1 || :
...
风险屏蔽
临时修改/usr/lib/tmpfiles.d/ceph-common.conf 文件的内容为:
d /run/ceph 0777 ceph ceph -
蝴蝶效应
遇到问题要努力去解决而不能轻易放过,不然,它会出其不意给你一棒子~
关注笔者
专注笔者公众号,阅读更多干货文章:)