服务器重启后业务服务没有自动启动，这个坑几乎每个运维都踩过。开发同事执行了reboot命令，结果发现重启后网站打不开、数据库连不上，紧急程度直接飙升到P0级。了解服务管理器的启动机制才能从根本解决这类问题。
检查自启动配置是否正确
先使用systemctl list-unit-files查看已启用自启动的服务列表，确认需要的服务是否在其中。如果显示disabled，用systemctl enable设为自启动。但即使服务状态是enabled，也不代表能成功启动。检查service单元文件的ExecStart字段，确认可执行文件路径在重启后是否仍然有效。有些软件安装在临时挂载的磁盘上，重启后挂载顺序变化会导致路径不可用。修改完配置后执行systemctl daemon-reload重新加载单元文件。旧版本系统也要检查/etc/init.d下是否有对应脚本以及rc级别的软链接。如果仍然无法自启动，用journalctl -u查看详细启动日志，报错信息通常直接指出问题所在。
处理启动顺序和依赖关系
服务启动失败很多时候不是自身配置问题，而是上游服务还没准备好。最多见的场景是Web应用在数据库之前启动，应用检测不到数据库连接直接就退出了。在service文件中通过After和Requires参数声明启动顺序。After只保证顺序但不等待，Requires声明依赖关系，如果依赖的服务启动失败本服务也会被取消。需要网络完全就绪才能启动的服务，添加After=network-online.target和Wants=network-online.target。容器化环境要检查docker运行容器是否加了restart=always参数，或docker-compose中restart策略是否设为unless-stopped。
排查启动脚本中的隐蔽问题
很多服务的启动脚本有潜在Bug。脚本中引用的环境变量是用户变量而不是系统变量，手动执行时能获取到，但systemd启动时因没有加载bashrc导致变量为空。脚本用了相对路径而不是绝对路径，手动执行时当前目录正好是脚本目录所以成功，系统启动时工作目录不同直接报错。解决办法是在service文件的Environment字段传入所需变量，或在启动脚本开头用export声明。所有路径写成绝对路径形式。把启动脚本的标准输出和错误重定向到日志文件，重启后查看日志能快速找到失败原因。建议在测试环境反复模拟重启来验证自启动脚本的可靠性。
建立重启验证标准流程
重启之后不能只看服务进程是否出现，要实际验证业务功能是否正常。建议编写自检脚本，重启后自动检查关键端口监听状态、HTTP接口是否返回两百状态码、数据库能否正常建立连接。上线新服务时把自启动配置作为验收必检项，测试环境先通过重启验证才允许上生产。把这个流程固化到变更管理规范中，每次重启前先检查自启动状态，操作后执行一遍自检。这套习惯坚持下去，服务无法自启动的问题基本不会再出现。