29.2 服务启动失败：端口占用、权限不足、依赖缺失排查

服务启动失败是运维中最常遇到的故障类型之一。大多数情况下，问题集中在三类原因：端口被占用、权限不足和依赖缺失。掌握下面这些排查思路和命令，你可以快速定位问题，而不是盲目重启。

端口占用：想要监听的端口已经被别人用了

典型现象是服务启动后立即退出，日志中常出现类似 bind: address already in use 或 cannot bind to port 80 的错误。

1. 确认端口占用情况

使用 ss（推荐）或 netstat 查看正在监听的套接字。下面这条命令列出所有 TCP 监听端口，并显示对应进程：

ss -tlnp

输出示例：

State     Recv-Q    Send-Q    Local Address:Port    Peer Address:Port    Process
LISTEN    0         128       0.0.0.0:80           0.0.0.0:*            users:(("nginx",pid=1234,fd=6))

这里可以看到 80 端口被 nginx (PID 1234) 占用。如果已经知道冲突端口，可以直接过滤：

ss -tlnp | grep ':80 '

2. 进一步排查占用进程

如果你看到占用端口的进程是一个完全不认识的程序，可以先看看它的详细信息：

ps -fp 1234
cat /proc/1234/cmdline | tr '\0' ' '    # 更精确地看到启动命令和参数
ls -l /proc/1234/exe                    # 查看可执行文件路径

3. 解决冲突

停止占用进程：如果确认该进程可以停止，使用 kill 1234（先尝试正常终止），无效再用 kill -9 1234。
换个端口：如果你无法停止占用端口的服务，修改当前服务配置，让它监听其他端口，例如将 Listen 80 改为 Listen 8080。
找到隐藏的占用：有时服务已经退出但端口仍处于 TIME_WAIT 状态，需要等待几十秒才能释放。如果必须立刻重用，可以调整内核参数（如设置 SO_REUSEADDR），但这通常需要修改服务代码或配置。

注意：如果你使用 systemd 管理服务，有时服务被屏蔽或处于失败状态后，systemd 本身会持有套接字（例如通过 socket activation）。检查 systemctl status <service> 的输出是否有相关提示。

权限不足：服务没有访问它所需资源的权限

典型错误日志中包含 Permission denied、cannot open file、operation not permitted。

1. 检查服务运行身份

先用 systemctl show <service> -p User,Group 或直接看进程列表，确认服务以哪个用户身份运行：

ps aux | grep nginx

有些服务配置里可以指定用户，如 nginx 的 user www-data;，apache 的 User www-data。如果配置中写的是 root，服务启动后会降权为普通用户，也可能因降权失败而退出。

2. 验证文件和目录权限

服务经常需要读取配置文件、写入日志或访问数据目录。你需要确认运行账户是否有对应的读（r）、写（w）、执行（x）权限：

查看文件权限：ls -l /etc/myapp/config.yml
查看目录权限：ls -ld /var/log/myapp

常见坑点：

配置文件具有敏感信息，权限被设为 600 且属主为 root，但服务以 myapp 用户运行，导致无法读取。
日志目录的父目录没有执行权限（x），导致服务无法进入该目录创建日志文件。
服务要求写入的目录属于 root，且其他用户无写权限。

3. 检查特殊权限与安全模块

即使标准 Unix 权限看起来没问题，SELinux 或 AppArmor 可能仍然会阻断访问。

查看审计日志：ausearch -m avc -ts recent 或 journalctl -t setroubleshoot（SELinux）
临时测试是否是 SELinux 导致：setenforce 0 将 SELinux 置于宽容模式，重启服务看是否正常。如果正常，再用 audit2allow 生成自定义策略，而不是长期关闭 SELinux。

4. 端口绑定特权

在 Linux 上，监听 1024 以下的端口（例如 80、443）需要 root 权限。但出于安全，许多服务会先以 root 启动，绑定端口后再切换到非特权用户。如果配置错误（如忘写 user 指令），服务可能始终以 root 运行，带来安全风险；或者因权限不足绑定失败。可以在配置中让服务监听高位端口（如 8080），再使用 iptables 重定向或反向代理实现端口映射，避免直接给服务 root 权限。

依赖缺失：服务找不到它需要的库、文件或其他服务

错误信息常常是明显的 library not found、cannot open shared object file，或者不明显的 No such file or directory（执行二进制文件时），也可能是服务启动超时。

1. 找不到动态链接库

用 ldd 检查二进制文件所需的所有动态库是否就位：

ldd /usr/bin/myapp

输出会列出每个库的路径。如果某项显示 not found，说明该库缺失。解决方案通常是安装对应的软件包，例如在 Debian/Ubuntu 上用 apt install libsomething，在 RHEL/CentOS 上用 dnf install libsomething。有时库文件存在但版本不匹配，也会导致服务无法启动，此时需要升级或降级库。

2. 命令行找不到可执行文件或脚本依赖

当通过绝对路径或 systemd 启动服务时，需要确保可执行文件本身存在且具备执行权限。systemd 的 ExecStart= 中如果路径写错，或脚本没有 #!/bin/bash 且缺乏执行位，都会导致启动失败。排查时直接在终端尝试以同一用户身份执行该命令：

sudo -u serviceuser /usr/bin/myapp --config=/etc/myapp.conf

观察是否会报错。如果提示 No such file or directory，用 file /usr/bin/myapp 检查文件类型；如果是 32 位程序却运行在纯 64 位系统上，可能会缺少 32 位运行时环境。

3. 依赖的后端服务未就绪

很多服务启动时需要连接数据库、消息队列或缓存。如果这些后端没有运行，或网络不通，服务可能立即退出或卡在“正在连接”阶段，直到 systemd 超时将其杀死。检查方法：

查看日志：journalctl -u myapp -n 50 --no-pager
手动测试连接：使用 nc -zv db.example.com 3306 检查数据库端口是否可达。
systemd 单元文件中可以配置 After=network.target mysql.service 和 Requires=mysql.service 来确保依赖服务先启动。

4. 依赖的文件路径硬编码错误

有些服务在编译时写死了配置文件或数据目录的绝对路径。如果将二进制复制到其他系统，或移动了目录位置，就会因找不到路径而启动失败。此时用 strace 跟踪系统调用往往能直接看到它尝试打开哪个文件却失败了（例如返回 ENOENT）：

strace -f -e openat /usr/bin/myapp  2>&1 | grep ENOENT

根据输出找到缺失的文件或路径，通过创建软链接或修改配置解决。

系统化的排查习惯

第一时间看日志：总是先执行 journalctl -u <service> 或查看服务自己的日志文件（通常在 /var/log/ 下），错误信息往往直接指明了原因。
对比启动命令：手动执行与 systemd 单元完全相同的命令，并用 echo $? 查看退出码，有时能绕过 systemd 的内部限制直接看到真实错误。
最小化环境测试：暂时移动配置文件，让服务以默认配置启动，如果能启动，就说明问题出在配置文件上，可以二分注释法定位具体配置项。
保持记录：任何修改过系统库、升级过内核或调整过权限的操作，都可能成为事后排查的线索。养成记录变更的习惯，能极大缩短定位时间。

端口占用、权限不足和依赖缺失这三类问题涵盖了绝大多数服务启动失败的情形。熟练使用 ss、ps、ls -l、ldd 和日志分析，能让你在几分钟内锁定根源，而不是反复重启碰运气。