在Linux系统中查看服务状态的核心命令是systemctl，它能统一管理systemd服务，通过status、list-units等子命令即可快速获取服务的运行状态、日志及配置信息。
在现代Linux运维体系中,传统的SysVinit脚本已被systemd全面取代，对于绝大多数现代发行版，如CentOS 7+、Ubuntu 16.04+、Debian 8+，systemd是初始化系统和系统服务的管理器，理解如何高效查询服务状态，是排查故障、监控健康度的基础技能。
systemctl基础查询指令详解
掌握systemctl的基本语法是第一步,该命令提供了丰富的子命令，针对不同场景有专门的用法。
查看单个服务的详细状态
当我们需要确认某个特定服务（如nginx、mysql）是否正在运行，或者最近一次启动是否成功时，使用status子命令是最直接的方式。
- 命令格式：
systemctl status [服务名] - 关键信息解读：
- Active行：显示服务当前状态，绿色表示active (running)，红色表示failed，灰色表示inactive (dead)。
- Main PID：显示主进程ID，便于后续使用top或ps命令追踪资源占用。
- Tasks：显示该服务当前占用的线程或进程数。
- CGroup：显示控制组路径，用于资源限制管理。
- 日志片段：命令输出末尾通常包含最近几行的journal日志，能快速定位启动报错原因。
执行systemctl status sshd，若看到Active: active (running)，说明SSH服务正常，若显示Active: failed，则需重点查看下方的日志错误信息。
批量列出所有服务状态
在服务器负载较高或需要审计所有后台进程时,逐个查询效率极低，此时应使用list-units命令进行全局扫描。
- 命令格式：
systemctl list-units --type=service --all - 筛选技巧：
- 仅查看活跃服务：
systemctl list-units --type=service - 查看已停止的服务：
systemctl list-units --type=service --state=inactive - 查看失败的服务：
systemctl list-units --type=service --state=failed
- 仅查看活跃服务：
这种批量查看方式能迅速暴露异常节点,业内专家指出，定期巡检failed状态的服务是预防服务器宕机的重要手段。
服务依赖与启动顺序分析
服务之间往往存在复杂的依赖关系,Web服务通常依赖网络服务，数据库服务可能依赖文件系统挂载，理解这些依赖有助于解决“服务启动失败”或“启动顺序错误”的问题。
查看服务依赖树
systemd允许我们可视化地查看服务的依赖关系。
- 查看前置依赖：
systemctl list-dependencies --reverse [服务名]此命令显示哪些服务依赖于当前服务,如果当前服务停止，哪些服务会受到影响？
- 查看后置依赖：
systemctl list-dependencies [服务名]此命令显示当前服务依赖哪些其他服务,如果依赖项未就绪，当前服务可能无法启动。
通过依赖树分析,可以清晰定位服务启动失败的根源，若Nginx启动失败，检查依赖树发现依赖的NetworkManager未启动，则应先解决网络问题。
管理服务开机自启
除了查看状态,管理服务是否随系统启动同样重要。
- 启用自启：
systemctl enable [服务名]创建符号链接,使服务在指定运行级别下自动启动。
- 禁用自启：
systemctl disable [服务名]移除符号链接,防止服务开机自动运行。
- 检查自启状态：
systemctl is-enabled [服务名]返回enabled、disabled或static，明确告知当前配置状态。
需要注意的是,enable仅配置自启，不立即启动服务，若需立即生效，需配合start命令使用。
高级故障排查与日志关联
当服务状态异常时,仅看status输出往往不够，需要结合journalctl深入分析日志，或使用其他辅助命令获取更多信息。
实时跟踪服务日志
journalctl是systemd的日志管理工具,与systemd服务紧密集成。
- 实时查看：
journalctl -u [服务名] -f类似tail -f，实时滚动显示服务日志，适合监控启动过程或运行时错误。
- 查看特定时间范围：
journalctl -u [服务名] --since "2026-01-01 00:00:00"
精准定位故障发生时间段内的日志。
- 查看错误级别日志：
journalctl -u [服务名] -p err仅显示error及以上级别的日志,过滤噪音，快速定位严重问题。
检查服务配置与单元文件
有时服务启动失败是因为配置文件错误,systemctl允许直接查看服务的单元文件。
- 查看单元文件路径：
systemctl show [服务名] --property=FragmentPath - 查看完整配置：
systemctl cat [服务名]输出服务的.service文件内容，包括ExecStart、Environment等关键指令。
- 重载配置：
systemctl daemon-reload修改配置文件后,必须执行此命令使systemd重新加载配置，否则更改不生效。
常见服务管理场景对比
不同场景下,查看服务的方式略有差异，下表对比了常见操作场景及推荐命令。
| 场景 | 推荐命令 | 说明 |
|---|---|---|
| 快速确认服务是否运行 | systemctl status [服务] |
显示状态、PID、简要日志 |
| 查找特定服务是否存在 | systemctl list-units | grep [服务名] |
模糊匹配服务名称 |
| 检查服务是否开机自启 | systemctl is-enabled [服务] |
返回enabled/disabled |
| 查看服务依赖关系 | systemctl list-dependencies [服务] |
树状图展示依赖链 |
| 实时调试启动失败 | journalctl -u [服务] -f -n 50 |
实时显示最后50行日志 |
| 查看服务资源占用 |
| 输出中包含Tasks和Memory信息 |
行业共识认为,熟练掌握上述命令组合，能解决90%以上的服务管理问题，对于更复杂的资源监控，可结合htop、nmon等工具进一步分析。
历史版本与兼容性问题
尽管systemd已成为主流,但在部分老旧系统或特殊环境中，仍可能遇到SysVinit或Upstart。
SysVinit兼容模式
在CentOS 6或更早版本中，使用service命令管理服务。
- 查看状态：
service [服务名] status - 重启服务：
service [服务名] restart
systemctl通常兼容SysVinit脚本,但功能受限，若系统支持systemd，建议优先使用systemctl，以获得更强大的依赖管理和日志集成能力。
Upstart系统
在Ubuntu 14.04及更早版本中，使用Upstart。
- 查看状态：
status [服务名] - 重启服务：
restart [服务名]
Upstart正在被systemd取代,新项目应直接采用systemd，若维护旧系统，需熟悉Upstart的配置文件格式（/etc/init/目录）。
Linux查看service常见问题解答
systemctl status显示inactive但服务实际在运行？
这种情况通常发生在服务被手动kill进程后,systemd未感知到进程退出，解决方法是执行systemctl restart [服务名]，强制systemd重新接管进程，若问题持续，检查服务配置文件中的Type设置，确保与进程行为匹配（如forking或simple）。
如何查看服务启动失败的具体原因？
首先执行systemctl status [服务名]，查看Active行是否为failed，然后使用journalctl -u [服务名] -p err查看错误日志，常见原因包括配置文件语法错误、端口冲突、权限不足或依赖服务未启动，根据日志提示逐一排查。
systemctl list-units和ps aux的区别？
ps aux显示当前所有进程，包括非systemd管理的进程，systemctl list-units仅显示由systemd管理的服务单元，若服务由脚本手动启动且未注册到systemd，ps aux能看到，但systemctl看不到，查看systemd管理服务时，应以systemctl为准。
首发原创文章，作者：王坚，如若转载，请注明出处：https://test.idctop.com/article/470650.html
