服务器重启后业务起不来，九成问题出在服务依赖、磁盘挂载和网络配置这三件事上，排查顺序比排查本身更重要。
服务器重启这件事,表面上就是敲个命令等它转一圈，但真正让人头疼的从来不是重启这个动作，而是重启之后那一屋子的烂摊子，数据库连不上、网站打不开、应用报错、端口没监听，这些问题在重启前一个都没有，重启后全冒出来了，很多运维新手在服务器重启后第一反应是到处点、到处看，折腾半小时也不知道问题在哪，作为一台天天被你开机关机的服务器，我建议你先冷静下来，按以下顺序排查。
服务器重启后服务起不来的排查顺序
先看硬件和系统层有没有正常起来
服务器重启后,你看到的第一个界面是BIOS或UEFI自检，然后是GRUB引导菜单，再然后才是内核启动日志，多数情况下系统能正常启动，但如果你用的是老旧的物理机，硬盘灯狂闪却卡在登录界面，优先考虑文件系统损坏，这是服务器重启后比较常见的物理层故障之一。
系统层面的排查命令就那么几条,uptime 看负载和运行时间，dmesg 看内核日志有没有硬件报错，df -h 看磁盘空间和挂载状态，free -h 看内存使用。
磁盘挂载是重启后最容易翻车的地方
这个问题在服务器重启后服务起不来的案例中占比相当大,具体表现是：磁盘目录还在，但里面的文件全不见了，或者应用能启动但读写报错，原因在于/etc/fstab 里配置了开机自动挂载，但挂载点对应的设备或文件系统在开机那一刻还没准备好，系统就直接跳过了。
网络服务是否正常就绪
网络这块看起来简单,实际上服务器重启后出问题的地方特别多，最常见的是网卡没被正确激活，现在多数Linux发行版默认用NetworkManager管理网络，但如果你改过配置文件，重启后可能发现网卡显示UP但在系统启动时没有分配到IP地址。
排查网络问题先用 ip addr 看IP有没有拿到，再用 ping 测网关通不通，最后检查/etc/resolv.conf 看DNS配没配好，对于云服务器，只探活IP而不测端口，很容易漏掉安全组层面的问题。
系统日志是服务器重启后的第一现场
journalctl -b -p err 这条命令查看本次开机后的错误级日志，journalctl -b 查看本次开机的全部日志，journalctl --list-boots 列出历史开机记录，多数情况下，系统日志里已经明确写了哪个服务启动失败、失败原因是什么，只是你还没去看。
看日志有个技巧：不要只看你关心的那个服务的日志，要看它依赖的所有上下游服务的日志，应用起不来，往往是它依赖的数据库或Redis还没就绪，而不是应用本身有问题。
服务器重启后网站打不开的原因分析与修复
服务依赖顺序错乱
这是一个非常高频的场景：服务器重启后网站打不开，你手动启动Web服务它就正常，但每次重启后它又起不来，原因基本锁定在服务依赖没有配置好，以systemd为例，Nginx可能需要MySQL就绪后才能启动，但你没有写依赖关系，导致Nginx在MySQL之前运行，连接数据库失败就自动退出了。
解决这类问题的思路有三个：
- 使用
systemd的服务依赖配置，通过After=和Requires=指令控制启动顺序 - 在应用启动脚本里加重试和等待逻辑
- 改用进程守护工具（比如Supervisor）来托管核心服务，自动拉起挂掉的进程
端口被占用或监听地址不对
服务器重启后出现的端口冲突,大多数情况下指向某个服务启动了多次，或两个服务抢同一个端口，查冲突用 ss -lntp 或 lsof -i:端口号。
监听地址又是一个容易忽略的坑,配置文件里写的 listen 127.0.0.1:8080，重启后你从外网访问肯定不通，这不是重启导致的问题，而是你配置本来就只允许本机访问，重启前没暴露只是因为连接一直保持活跃。云安全组或防火墙规则可能在重启后被重置或覆盖，导致端口不通。
数据库连接池和缓存没预热
服务器重启后网站打不开,还有一种表现是：页面能打开但特别慢，像是卡死了一样，这个大概率是数据库连接池和缓存全被清空导致的，重启前，连接池是热的，缓存是满的，请求很快就打完了，重启后一切归零，数据库要重新建立连接，Redis要重新加载数据，首次请求自然会慢。
多数情况下这个现象会在一段时间内自行缓解,但如果你等不了，可以配置数据库连接池预热机制和缓存预加载脚本，云厂商提供的负载均衡健康检查，在重启后短时间内会持续判定后端不健康，导致流量不转发。
文件权限和属主变化
这种问题比较隐蔽,如果服务器重启后某个应用的数据目录读不了、写不了，优先检查目录属主和权限位是否因为系统时间、用户ID映射等原因发生了变化，NFS或网络存储的权限问题尤其突出，重启后挂载顺序变了，权限校验就对不上了。
Linux服务器安全重启的完整操作流程
重启前必须完成的三个步骤
第一步，同步磁盘缓存，虽然现在的文件系统对掉电和数据一致性有了很多保护，但稳妥起见，在重启前执行 sync 命令，把内存中的脏数据强制写回磁盘，这一步极端重要，它是防止文件系统损坏的最后一道防线。
第二步，检查是否有正在执行的关键任务，用 top 看CPU和IO占用，用ps aux 看有没有跑批任务，如果要重启的机器上有正在执行的数据迁移或定时任务，你要么等它跑完，要么明确接受中断的风险。
第三步，通知相关的同事或客户，这一点说多了都是泪，服务器重启后服务起不来，往往不是因为重启本身失败，而是因为重启前没有任何预案。
安全重启的具体操作路径
Linux上有三种常用的重启方式：
reboot：最常用的重启命令，会先调用shutdown，执行完整的关停流程shutdown -r now：语义更明确的重启命令，-r表示重启，now表示立即执行systemctl reboot：systemd系统的标准做法，会先停掉所有单元再重启
建议优先使用 shutdown -r now 或 systemctl reboot，避免直接按电源键或执行 reboot -f 强制重启，强制重启会跳过正常关停流程，极端情况下会导致文件系统元数据不一致，如果你的服务器是云服务器重启，在云厂商控制台操作有额外的配置项，强制重启”和”普通重启”的区别，选普通重启。
在你执行重启命令之前,确认一下服务器上有没有 /etc/rc.local 或 /etc/rc.d/rc.local 里配置了旧的初始化脚本，这些脚本在启动时执行，如果包含过时的挂载指令或已经废弃的服务调用，会在重启后引发一系列连锁问题。
服务器自动重启的日志排查方法与预防措施
从重启痕迹判断是软件还是硬件问题
排查服务器自动重启,核心是回答一个问题：是软件触发的重启，还是硬件掉电导致的重启，这两类问题的排查方向完全不同。
软件触发的重启,系统日志里会留下明确痕迹，执行 last reboot 或 journalctl --list-boots，可以看到所有历史重启记录，如果是内核崩溃，/var/crash 目录下通常会有dump文件，检查/var/log/kern.log 里有没有kernel panic记录。
硬件导致的掉电重启,往往在系统日志里只能看到异常断电的痕迹，比如文件系统在开机时进行了recovery，对于物理机，要检查电源、内存条、CPU温度这些硬件状态，如果是云服务器重启，则需要查看云厂商控制台里的”系统事件”或”操作日志”，看是否因为宿主机维护或迁移导致了自动重启。
预防重启乱象的几个标准化操作
用systemd统一管理服务是近年来的行业共识，它能管理服务间的启动顺序，还能在异常退出时自动拉起，如果你的业务服务还在用SysVinit时代的脚本，建议迁移到systemd上来。
把磁盘挂载做成服务或脚本，特别是NFS、CephFS这类网络文件系统，在/etc/fstab里的挂载时机很难控制，但做成systemd的.mount单元可以明确依赖条件，避免重启后挂载顺序错乱。
配置统一日志服务，用rsyslog或journald把日志持续输出到远程日志服务器，这样即使服务器彻底挂了，日志也不会丢，服务器重启后排查问题，最怕的就是”日志在本地，但系统起不来了”。
服务器重启前后必须检查的事项清单
| 检查项 | 重启前 | 重启后 |
|---|---|---|
| 磁盘挂载 | 确认fstab无僵尸条目 | 检查df -h输出是否完整 |
| 关键服务 | 记录当前服务列表 | 验证各服务状态是否符合预期 |
| 网络配置 | 备份网卡配置 | 检查IP、路由、DNS |
| 数据一致性 | 执行sync并确认无未完成任务 |
检查应用日志有无报错 |
| 防火墙规则 | 确认规则已持久化 | 验证端口连通性 |
记住一个原则：重启前做减法，重启后做加法，重启前把干扰项（临时的环境变量、手动的启动命令、未持久化的iptables规则）全部清理掉，重启后再一项一项验证服务是否就绪，很多服务器重启后的问题，本质上不是因为重启这个动作造成的，而是重启前环境本身就不够干净。
服务器重启后服务起不来,不是靠运气解决的，是靠规范化流程解决的，把上面的检查项固化到你的运维手册里，每次重启都照着走一遍，大部分故障在发生前就能被拦截，从下一次重启开始，试着用这条路径来管理你的服务器，它会配合得很好，毕竟，你也不想每次重启后都对着黑洞洞的终端发呆，对吧。
服务器重启后常见问题Q&A
服务器重启后服务起不来，最应该先查哪个日志？
先查journalctl -b -p err，这是本次开机后的错误级系统日志，如果没有关键信息，再针对具体服务查它的单元日志，journalctl -u 服务名 -b，多数情况下，系统日志会直接指出启动失败的单元及其原因，比如依赖的服务没起来、端口被占用或配置文件语法错误。
云服务器重启一般多久算正常？
云服务器重启的正常时间在1到5分钟区间，物理服务器通常在3到10分钟，如果超过这个范围，可能是文件系统在强制校验或核心服务启动超时，需要持续关注的是重启后服务恢复的时间，而不只是系统起没起来，有些云服务器系统起来了但业务初始化耗时较长，会导致对外表现像”还在重启中”。
首发原创文章，作者：王坚，如若转载，请注明出处：https://test.idctop.com/article/588546.html
