Linux 日志排查入门：用 journalctl 三步定位一次服务起不来的问题

昨天同事在群里喊："服务器重启之后，应用起不来了，控制台一片红，怎么办？"其实对 Linux 新手来说，服务起不来并不可怕，可怕的是无从下手。今天就用 systemd 自带的 journalctl，分三个步骤把问题定位出来。

第一步：看服务状态，先确认"病在哪里"。

大多数现代 Linux 发行版（Ubuntu 16.04+、CentOS 7+，以及华为云常用的 openEuler）都用 systemd 管理服务。服务起不来，先看它的状态：

sudo systemctl status myapp --no-pager -l

输出里重点看两行：Active 字段（是 failed 还是 inactive），以及末尾几行日志片段。如果看到"failed (Result: exit-code)"之类的提示，说明进程自己退出了。这时候别急着重启，先往下查日志，重启只会把现场冲掉。

第二步：用 journalctl 看完整日志，找到报错行。

systemctl status 只显示最近几行，要看完整的用 journalctl：

sudo journalctl -u myapp --since "1 hour ago" --no-pager

加上 --since 限制时间范围，避免被几天前的日志淹没。再分享两个小技巧：用 -p err 只看错误级别以上的日志；用 grep 按关键字过滤，比如：

sudo journalctl -u myapp -p err --since today --no-pager | grep -i "error\|fail\|denied"

真实案例里，我曾经在日志里看到这样一行：Error: listen EADDRINUSE: address already in use :::3000。端口被占用——原来是旧进程没杀掉，新实例抢不到端口，一眼就定位到了。

第三步：根据报错对症处理，然后验证。

最常见的三类问题和处理办法：

1. 端口冲突：用 ss -tlnp | grep 3000 找到占用进程，确认无用后 kill 掉，再 systemctl restart myapp。
2. 配置文件写错：报错通常带行号，比如 line 42: unexpected token。改完后先用应用自带的测试模式（如 nginx -t）验证一遍再重启。
3. 权限不足：看到 Permission denied 就检查文件属主，必要时 chown 给运行服务的用户，别图省事直接 chmod 777。

处理完别忘了验证：systemctl is-active myapp 返回 active，再看 journalctl -u myapp -n 20 确认没有新的报错。最后加个保险：systemctl enable myapp，让服务开机自启，下次重启机器就不用半夜爬起来了。

总结一下排查口诀：status 看状态、journalctl 看日志、报错行定方向。把这三步练熟，八成的"服务起不来"都能在十分钟内搞定，不用再对着满屏红色干着急。