「磁盘挂载掉了你帮我挂回去，注意有数据别把我数据删了。」

这句话我记到现在。一台宝塔 CentOS，上面跑 Discuz 论坛，MySQL 5.7.44、nginx、php-fpm 都是宝塔装的。盘没挂上，网站自然打不开，但真正麻烦的是把盘挂回去之后。

挂载那一段就不展开了，只读认盘、改 fstab 用 UUID、回读 findmnt，之前写过（磁盘 97%，一口咬定是日志）。这里说后面的：df -h 已经正常，/www 里的东西也都在，可 MySQL 就是起不来，站点 502。

先看服务状态。systemctl is-active mysqld 回了一个 active。

我心里还松了一下，以为只是 nginx 没拉起来。再顺手 ps -ef | grep [m]ysqld，空的。socket 文件也不存在。一个说活着，一个说连影子都没有。

这种情况别急着骂 systemd。宝塔的 MySQL 走的是 init 脚本，is-active 对 LSB 脚本的判断本来就粗，看退出码和 pidfile 那一套。那次更具体：脚本里 PATH 不全，跑 my_print_defaults 直接 command not found，状态判断跟着失真；再加上当时 /www 刚挂回来，datadir 里的东西还没完全对上。两个条件叠在一起，就出了个「嘴上说 active、实际没进程」的假象。

绕开状态，直接拿真实日志：/www/server/mysql/bin/mysqld_safe --defaults-file=/etc/my.cnf --user=mysql。这样一跑，err 日志里才有话。

nginx 那边也有意思。它开机自启的时间是 21:32，那会儿 /www 还是空的，配置全不在，所以 failed。等盘挂好，nginx -t 直接通过，start 就活了。它不是坏了，是被上游的挂载故障带停的。这两种情况的处理方式完全不一样，分不清就容易去重装软件。

最后收在 502 上。80 端口已经通了，页面还是 502，说明请求到了 nginx、没到 PHP。宝塔一台机器上装了 55、71、85 三个 PHP 版本，翻 vhost 里的 include enable-php-85.conf 才确定这个站用的是 8.5，起对应的 php-fpm-85，然后 301 跳 /bbs、再 200。

从头到尾 12 分钟，44 条命令。但真正耗时间的不是敲命令，是判断「它到底活没活」。做七亿批量远程管理工具这几年，我发现大家看机器状态都太信那一行绿字了：面板上绿灯、systemctl 说 active、监控显示 200，就默认服务在跑。真出事的时候，这三样经常一起骗人。

后来我自己定了个笨办法，进程、socket、端口，三样都对上才算活。麻烦是麻烦点，但比事后跟人解释「它显示是好的」强。平时几台机器来回看，我图省事就用七亿批量远程管理工具开几个 SSH 标签页，进程和端口在同一个窗口里查，不用来回切终端。

写这篇的时候我又想了一遍：那个 active 要是当时没多看一眼 ps，后面清 binlog、重启库，全得在错误的假设上做。现在每次有人跟我说「服务是好的」，我都先问一句：进程号多少。对方愣一下，我就知道自己还得上去看一遍。

顺手提一句，七亿批量远程管理工具 是免费的，Windows 端，RDP 九宫格、SSH 终端、SFTP、FTP 都在一起。云主机和服务器那边是七亿网络在做，韩国、香港节点都有。