Linux 新手入门：用 systemctl 和 journalctl 看懂服务为什么起不来

服务起不来时，先别急着重启：先看它到底卡在哪一步

刚接触 Linux 的新手最常遇到的场面是这样的：装好一个服务，敲下启动命令，终端却只回一句失败，或者干脆什么都不说。很多人第一反应是反复重启，或者把配置文件改来改去。其实大多数服务启动失败都有迹可循，关键是先用两个工具把现场固定下来：systemctl 看状态，journalctl 看日志。

第一步：用 systemctl status 看服务的“体检报告”

以常见的 nginx 为例，先不要直接重启，先问一句：

systemctl status nginx

输出里最值得先看的有四处。第一是 Loaded 一行，它告诉你这个服务单元文件来自哪里，以及有没有被禁用；第二是 Active 一行，failed、inactive、activating 各自含义不同，failed 是启动过但失败了，inactive 多半是根本没启动，activating 则可能是还在等依赖；第三是 Main PID 和最近几行日志摘要；第四是 CGroup 里的进程，服务如果已经退出，这里往往是空的。

如果状态是 failed，先不要急着执行 restart。restart 会把现场覆盖掉，你真正需要的第一手信息就在失败那一刻的日志里。更稳妥的顺序是：status 定性，journalctl 定因，最后再决定是改配置、补依赖还是放行端口。

第二步：用 journalctl 追到失败的那一刻

systemctl status 只给摘要，完整的时间线要看 journalctl：

journalctl -u nginx --since "10 minutes ago" -n 100

-u 是只看这个服务，–since 是限定时间，-n 是取最近若干行。刚开始排障时，建议把时间窗口放宽一点，因为服务可能在你动手之前就已经失败过一次。看到报错后，顺着时间线往上找第一条错误，而不是只看最后一条。最后一条常常只是“启动失败”的结论，真正的原因往往藏在它前面几行，比如配置文件语法错误、端口被占用、依赖的目录不存在。

如果想实时观察一次启动过程，可以开两个终端：一个执行 journalctl -u nginx -f 跟踪，另一个执行 systemctl start nginx。这样你能看到从启动到失败的完整顺序，而不是事后拼凑。

三种最常见的“起不来”，对照着查

第一种是端口被占用。日志里会出现 Address already in use 一类的提示。这时先用 ss -tlnp 看看是哪个进程占了这个端口，再决定是停掉旧进程、换端口，还是把重复启动的旧服务关掉。不要直接 kill -9 了事，先确认那个进程是不是你自己的另一个服务。

第二种是配置文件写错。nginx 可以用 nginx -t 先做语法检查，很多服务也有类似的 configtest。日志里如果出现配置文件某一行报错，先去那一行附近检查括号、分号、路径拼写。改完之后再做一次语法检查，通过了再启动，这样可以少走很多弯路。

第三种是权限或路径问题。比如服务要读的证书、数据目录不存在，或者运行用户没有读权限。日志里会出现 Permission denied 或 No such file or directory。这时不要习惯性地用 root 去跑服务，先检查目录是否存在、属主和权限是否与服务运行用户一致。把权限放得过大虽然能“跑起来”，但会埋下安全隐患。

一个可以复用的排障流程

我自己现在遇到服务起不来，基本固定走这四步：第一，systemctl status 看状态和摘要；第二，journalctl -u 服务名 --since 最近一段时间看完整日志；第三，根据报错类型分流到端口、配置、权限这三类去验证；第四，改一处、验证一处，再启动一次，并用 systemctl status 确认 Active 变为 active (running)。

还有两个小习惯很值得养成。一是改配置前先备份原文件，哪怕只是 cp nginx.conf nginx.conf.bak，也能在改坏时立刻回退。二是每次只改一个变量，改完就验证，这样如果问题解决了，你才知道到底是哪一步起的作用；如果没解决，日志里新的报错也会更清晰。

结语

systemctl 和 journalctl 不是什么高深的工具，它们的价值在于把“服务为什么起不来”从猜测变成证据。先看状态、再看日志、再按端口、配置、权限分流，大多数新手阶段的启动失败都能在几分钟内定位。等你把这个流程走熟了，再去学更复杂的排障工具，底子会扎实得多。