上午正在开会，突然收到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 –
蝴蝶效应
遇到问题要努力去解决而不能轻易放过，不然，它会出其不意给你一棒子~
关注笔者
专注笔者公众号，阅读更多干货文章：）
