在Linux服务器上排查故障时，第一步通常是确认目标服务的运行状态。服务的状态查看方式并不是只有一种，systemd、SysVinit、进程表、网络端口都可能反映出服务当前的真实情况。本文从不同层次介绍查看服务状态的常用手段，帮助你在命令行环境中快速做出判断。
一、systemctl：现代Linux发行版的标准答案
systemd作为当前绝大多数Linux发行版的初始化系统，提供了systemctl命令来统一管理服务。最基本的用法是systemctl status 服务名，该命令会一次性展示服务是否在运行、是否开机自启、主进程ID、CPU与内存占用以及最新的日志信息。相比直接去进程表里查找，systemctl给出的信息更结构化，也更容易读懂。
除了status之外，systemctl还提供了一些细分查询命令。在脚本中判断服务状态时，systemctl is-active和systemctl is-enabled比status更方便，因为它们的返回值是明确的状态字符串，可以直接参与条件判断。
systemctl status nginx systemctl is-active nginx systemctl is-enabled nginx systemctl list-units --type=service --state running systemctl list-units --type=service --state failed
systemctl输出的状态值有几种常见情况：active (running)表示服务正在运行，active (exited)表示一次性任务已经成功执行完毕，inactive表示服务当前未运行，failed则说明服务启动或运行过程中出现了异常。使用list-units命令时，可以配合grep过滤关键字，也可以直接通过--state参数指定要查询的状态，例如列出所有启动失败的单元，在故障排查时非常实用。
systemctl还可以查看服务的依赖关系，执行systemctl list-dependencies nginx就能看到nginx服务依赖哪些其他单元。这在服务无法启动时尤其有价值，很多情况下问题并不出在服务本身，而是它所依赖的某个挂载点或网络设备没有就绪。下表整理了最重要的几个状态值，便于对比记忆。
| 状态值 | 含义 | 常见场景 |
|---|---|---|
| active (running) | 服务正在运行 | 正常运行的守护进程 |
| active (exited) | 服务已成功退出 | 一次性脚本或oneshot服务 |
| inactive | 服务未运行 | 服务被停止或从未启动 |
| failed | 服务启动失败 | 配置错误、端口冲突、依赖缺失 |
二、service与init脚本：SysVinit时代的兼容方案
虽然systemd已经成为主流，但生产环境中依然存在使用SysVinit的旧系统，某些精简容器镜像也并未引入systemd。在这种情况下，需要回到service 服务名 status的查看方式。service命令会去/etc/init.d/目录下寻找对应的初始化脚本，靠脚本自身的逻辑来决定返回什么信息。不同发行版、不同服务脚本的输出格式差异较大，有的会显示进程号，有的只显示一句简单的判断结果。
service nginx status service mysql status /etc/init.d/nginx status chkconfig --list
在SysVinit环境下，查看某个服务是否开机自启可以使用chkconfig，它会列出服务在各个运行级别下的启动设置。需要注意的是，chkconfig的显示结果在不同发行版上格式并不统一，CentOS 6和Debian 7的输出风格就不太一样，但核心信息都是每个运行级别对应的开关状态。
还有一点值得留意：某些容器镜像虽然提供了service命令，但背后并不是真正的SysVinit脚本，而是一个兼容性封装。比如在基于Debian的容器中使用service命令时，它可能只是调用了systemctl，也可能直接读取/etc/init.d下的脚本。因此，在容器环境中不要盲目信任service的输出，最好结合进程和端口信息来确认服务的真实状态。
三、从进程和端口反向验证服务状态
有些服务并不由systemd或init管理，例如通过nohup启动的Java进程、通过docker run启动的容器内部进程。还有一类情况是systemctl查询结果显示服务已经停止，但业务进程仍然残留。此时可以通过ps命令查看进程是否存在，进而判断服务是否真的在运行。
ps -ef | grep nginx pgrep -fa nginx ss -tlnp | grep :80 netstat -tlnp | grep :80
ps命令配合grep使用是最直观的进程查找方式。观察nginx进程时，输出中通常会有一个master进程和多个worker进程，这是正常的架构设计，不要误判为多个服务实例。使用grep过滤进程时，建议写成grep [n]ginx的形式，这样可以避免grep自身进程出现在结果中。如果使用pgrep，则直接用pgrep -fa nginx即可，-f参数表示匹配完整命令行，-a参数会显示进程的完整启动命令。
端口监听状态是另一个重要维度。ss命令是iproute2套件提供的工具，执行ss -tlnp可以查看所有TCP监听端口及其对应的进程信息。netstat在部分新版系统中需要额外安装net-tools包，功能上与ss类似。如果一个服务显示运行中，但ss却看不到它要监听的端口，说明服务可能在启动后崩溃并重启失败，或者因为配置错误没有绑定到预期的网络接口。反过来，如果端口已经被其他进程占用，新启动的服务就会报Address already in use的错误，这种情况下用systemctl查看服务状态，往往会看到最上方的Active行确实变成了failed。
四、常见问题与注意事项
第一种常见情况是服务状态显示active (running)，但业务却完全不可用。可能的原因有三个：服务监听在127.0.0.1上导致外部无法访问，防火墙规则放行的端口与实际监听端口不一致，或者服务本身虽然还活着但内部线程已经死锁。排查时先执行ss -tlnp确认监听地址，再通过curl测试本机回环地址的连通性，最后结合日志判断是否存在异常堆栈。
第二种情况是遇到active (exited)状态。很多新手会误以为服务崩溃了，其实对于Type=oneshot类型的服务来说，执行完一次性任务后主动退出是正常行为。判断的关键在于查看子状态或其他字段，如果进程结束后没有留下异常记录，并且业务侧确认任务已经完成，那就不需要干预。如果exited状态伴随非零退出码，则需要检查脚本中的错误输出。
第三种情况是在容器中执行systemctl命令时提示System has not been booted with systemd as init system。这是常见误区，容器内通常没有完整的systemd进程，自然也就无法使用systemctl。此时应该改用ps、ss、/proc文件系统等方式来确认进程和端口状态。某些容器镜像为了兼容性安装了systemctl命令，但运行时依然会受到dbus未启动或权限限制的阻碍，不要因为命令存在就认为它一定能工作。
第四种情况涉及日志的配合使用。服务状态只是结果，导致结果的原因往往藏在日志中。使用journalctl -u nginx -e可以直接查看服务最近的日志记录，-e参数表示从末尾开始显示。如果服务反复重启，可以先记录下当前状态值，然后执行journalctl -u nginx --since "5 minutes ago"查看最近五分钟内的日志，这样比较容易定位到崩溃的直接原因。
另外需要特别提醒的是，服务状态正常并不等于业务可用。systemd从初始化系统角度判断服务进程存活，而业务是否真正可用，还要看端口能否连通、接口返回是否合理、数据库连接是否建立成功。一个科学的状态检查脚本应当结合systemctl is-active、ss -tlnp和业务健康检查接口三方面信息，避免误判。掌握这些命令的适用边界，遇到问题时才能快速挑出正确的工具。
Linux服务状态systemctl命令ps命令修改时间：2026-08-30 17:54:07