在 Linux 系统运维与服务器管理过程中，准确、高效地查看当前运行的服务是保障系统稳定性和排查故障的核心技能，目前主流的 Linux 发行版（如 CentOS 7/8、Ubuntu 16.04 及以上版本、Debian 9 及以上版本）均已默认采用 systemd 作为初始化系统，systemctl 命令是查看和管理服务最权威、最标准的首选工具，为了应对不同的运维场景和遗留系统，掌握传统的 SysVinit 命令以及结合进程与端口监控工具（如 ps、top、ss），能够构建出更全面、更深度的服务监控体系，本文将遵循金字塔原则，从核心命令出发,分层展开详细的专业解决方案。
核心方法：使用 Systemd 查看服务（Systemctl）
作为现代 Linux 系统的标准服务管理器，systemd 提供了比传统方法更强大的并行启动能力和依赖管理，使用 systemctl 查看服务不仅可以看到是否运行，还能看到启动时间、资源消耗等详细元数据。
列出所有服务状态
要获取系统上所有服务单元的概览，最基础的命令是：
systemctl list-units --type=service
该命令会输出一个列表，包含 UNIT（服务名）、LOAD（加载状态）、ACTIVE（激活状态）、SUB（子状态）以及 DESCRIPTION（描述）。重点关注 ACTIVE 字段，显示为 active (running) 的即为正在运行的服务。
仅筛选正在运行的服务
在生产环境中，服务数量可能多达上百个，为了快速定位运行中的关键服务，使用过滤参数至关重要：
systemctl list-units --type=service --state=running
此命令将只输出状态为 running 的服务，极大地提高了排查效率,这是运维人员在日常巡检中最常用的命令之一。
查看特定服务的详细状态
当需要深入分析某个具体服务（nginx 或 mysql）时，单纯知道“正在运行”是不够的，使用以下命令可以获取该服务的详细运行时信息：
systemctl status service_name
输出结果中包含了核心的 Loaded（是否开机自启）、Active（当前运行状态）、Main PID（主进程 ID） 以及最近的 日志输出，通过查看日志输出的最后几行,往往能直接定位服务无法启动或异常退出的原因。
传统方法：SysVinit 兼容命令
尽管 systemd 已成为主流，但在一些老旧的 LTS 版本（如 CentOS 6）或某些轻量级发行版中，SysVinit 依然存在，systemd 为了保持向后兼容,也保留了对部分传统命令的支持。
service 命令
这是最经典的传统命令，用于手动启动或停止服务，同时也可以用来查看状态：
service --status-all
执行后，系统会列出所有服务的状态。注意，输出中带有 [ + ] 号的表示正在运行，[ ] 表示已停止。 这种方式虽然不如 systemctl 直观,但在编写跨版本兼容的脚本时非常有用。
chkconfig 命令
如果不仅想查看当前运行状态，还想查看服务在各个运行级别下的开机自启情况，chkconfig 是最佳工具：
chkconfig --list
该命令会列出每个服务在 0-6 个运行级别下的开关状态。对于运维人员来说，确认关键服务在 runlevel 3（多用户文本模式）和 runlevel 5（图形界面模式）下为开启状态，是保障服务器重启后业务可用的基础。
进程与端口维度：底层监控与验证
服务管理器显示服务正在运行，但业务却无法访问，这可能是因为服务进程僵死、卡死，或者端口被非预期进程占用，必须脱离服务管理器的层面,直接从操作系统内核的进程和端口角度进行验证。
使用 ps 命令查看进程
ps 命令用于查看当前瞬间的进程快照，结合 grep 使用是定位特定服务进程的标准做法：
ps -ef | grep nginx
或者使用更详细的格式化输出：
ps aux | grep mysql
通过输出结果，可以查看 CPU 使用率 (%)、内存使用率 (%) 以及 STAT（进程状态）。STAT 显示为 S (睡眠) 或 R (运行)，则进程正常；如果显示为 Z (僵尸)，则说明父进程没有正确回收子进程，需要重点排查。
使用 ss 或 netstat 查看端口
服务通常通过端口对外提供服务，如果服务运行正常但端口未监听，外部请求将无法到达，ss 是 netstat 的现代替代品，速度更快且更详细。
查看所有监听端口：
ss -tulnp
- -t: 显示 TCP 端口
- -u: 显示 UDP 端口
- -l: 仅显示监听状态的套接字
- -n: 以数字形式显示端口（不解析服务名,速度快）
- -p: 显示监听该端口的进程名和 PID（需要 root 权限）
专业见解：在排查“端口被占用”问题时，使用 ss -tulnp | grep :80 可以迅速确认 80 端口是否由预期的 httpd 或 nginx 进程监听，如果发现 PID 与 systemctl status 显示的 Main PID 不一致,说明存在端口冲突或服务启动了多个实例。
专业解决方案：自动化监控与日志分析
仅仅手动查看是不够的,专业的运维体系需要自动化的监控和深度的日志关联。
实时监控服务日志
systemd 集成了日志管理功能 journalctl，当服务状态异常时，不要只看 status 的简略输出，应深入查看日志：
journalctl -u nginx.service -f
- -u: 指定服务单元
- -f: 类似于 tail -f，实时跟踪日志输出
这能让你在服务发生崩溃或重启的瞬间，第一时间捕捉到错误堆栈或异常请求信息。
编写服务健康检查脚本
为了实现无人值守的运维，可以编写一个简单的 Shell 脚本，结合 systemctl 和 curl（针对 Web 服务）进行深度健康检查。
#!/bin/bash
SERVICE_NAME="nginx"
if systemctl is-active --quiet $SERVICE_NAME; then
echo "[$SERVICE_NAME] is running."
# 进一步检查 HTTP 响应码
if curl -s -o /dev/null -w "%{http_code}" http://localhost | grep -q "200"; then
echo "[$SERVICE_NAME] health check passed."
else
echo "[$SERVICE_NAME] is running but HTTP response error."
# 此处可触发告警
fi
else
echo "[$SERVICE_NAME] is not running! Attempting to restart..."
systemctl restart $SERVICE_NAME
fi
该脚本体现了“独立见解”：服务运行不代表服务健康。 只有结合了协议层面的健康检查,才能确保业务的真实可用性。
在 Linux 下查看运行的服务，systemctl 是当前的标准答案，它提供了从宏观列表到微观状态的全面视图，但在实际故障排查中，必须结合 ps、ss 等底层工具进行交叉验证，并利用 journalctl 深入分析日志，专业的运维不仅仅是执行命令，更是理解服务状态背后的进程模型和网络依赖，通过脚本化的健康检查实现从“被动查看”到“主动治理”的转变。
相关问答
Q1：在 Linux 中，为什么有时候 systemctl 显示服务是 running 的，但实际上无法访问服务？
A1： 这种情况通常由以下原因造成，服务进程可能处于“死锁”状态，进程存在但无法处理新请求；服务可能绑定了错误的 IP 地址（例如绑定了 127.0.0.1 而非 0.0.0.0），导致外部无法连接；防火墙或 SELinux 可能拦截了入站流量，解决方法是使用 ss -tulnp 检查监听地址，使用 curl 在本地测试，并检查 firewall-cmd 或 iptables 规则。
Q2：如何临时禁止一个服务运行，而不删除它？
A2： 如果只是想临时停止服务，可以使用 systemctl stop service_name，如果想禁止其开机自启，但保留当前运行状态，使用 systemctl disable service_name，如果想彻底屏蔽服务（防止任何手动或依赖启动），可以使用 systemctl mask service_name，Mask 是最强的禁用手段，它会将服务单元文件链接到 /dev/null，直到执行 unmask 才能恢复。
互动环节：
如果您在查看 Linux 服务时遇到过特殊的报错，或者有自己独到的服务监控技巧，欢迎在评论区分享您的经验和问题,我们一起探讨更高效的运维之道。
