答案：查看Linux服务状态首选systemctl status命令，可获取运行状态、PID及日志；配合journalctl -u查看详细日志，排查服务异常。
在Linux系统上，查看服务当前状态最直接且普遍的方式，通常是利用
systemctl status
命令，它会给你一个关于服务是否正在运行、启动时间、PID等详细信息。对于一些老旧或特定配置的系统，你可能还会用到
service status
。而更底层的检查，比如
ps aux | grep
或者通过端口监听来判断，也都是我个人在排查问题时常用的辅助手段。
解决方案
要查看Linux服务的当前状态，我们需要根据系统所使用的初始化系统来选择合适的命令。目前主流的Linux发行版大多采用
systemd
作为其初始化系统，但也有一些系统可能还在使用
SysVinit
或
Upstart
。
1. 使用
systemctl
(适用于
systemd
系统)
这是现代Linux系统（如CentOS 7/8/9, Ubuntu 16.04+, Debian 8+等）最推荐的方法。
查看服务的详细状态：
systemctl status
例如，查看Nginx服务的状态：
systemctl status nginx
这条命令会返回服务的加载状态（Loaded）、是否激活（Active）、进程ID（PID）、内存使用、CGroup信息，以及最近的几行日志输出。通过
Active: active (running)
这样的字样，你可以直观地判断服务是否正在运行。如果显示
Active: inactive (dead)
，那服务就是停止的。
快速判断服务是否正在运行：
systemctl is-active
这条命令只会输出
active
（运行中）或
inactive
（停止），非常适合脚本中进行判断。
快速判断服务是否已启用（开机自启动）：
systemctl is-enabled
它会输出
enabled
（已启用）、
disabled
（已禁用）或
static
（静态服务，通常不能被启用/禁用）。
2. 使用
service
(适用于
SysVinit
或
Upstart
系统，或兼容模式)
对于一些较老的Linux发行版（如CentOS 6, Ubuntu 14.04-），或者在
systemd
系统上为了兼容性，也可以尝试使用
service
命令。
service status
例如，查看Apache服务的状态：
service apache2 status
输出通常会告诉你服务是否正在运行，以及它的PID。不过，其输出的详细程度和格式可能不如
systemctl
统一和丰富。
3. 通过进程列表检查 (通用方法)
这是一种更底层、更通用的检查方法，不依赖于特定的初始化系统，但需要你知道服务对应的进程名。
ps aux | grep
例如，查看Nginx进程：
ps aux | grep nginx
或者，如果你想排除
grep
命令本身的进程：
ps aux | grep -v grep | grep nginx
如果能看到对应的进程列表，通常意味着服务正在运行。但请注意，这只能说明进程存在，不代表服务功能完全正常。
4. 检查端口监听 (针对网络服务)
对于提供网络服务的应用（如Web服务器、数据库），检查其监听的端口也是判断服务是否正常运行的有效手段。
麦当秀MindShow AiPPT
麦当秀｜MINDSHOW是一款百万用户正在使用的三分钟生成一份PPT的AI应用系统。它利用引领前沿的人工智能技术，能够自动完成演示内容的设计。
224 查看详情
netstat -tuln | grep
例如，检查80端口（HTTP）是否被监听：
netstat -tuln | grep 80
如果能看到
LISTEN
状态的条目，说明有进程正在监听该端口，通常意味着对应的网络服务正在运行并对外提供服务。
为什么
systemctl status
显示运行中，但服务却不工作？
这其实是个很常见的“陷阱”，我个人在排查问题时也遇到过不少次。
systemctl status
告诉你的是服务的主进程（或其监控的进程组）还在运行，系统认为它“活”着。但服务不工作，往往意味着虽然进程还在，但它内部出现了问题，无法正常提供功能。
造成这种情况的原因多种多样：
配置错误： 服务启动了，但加载了错误的配置文件，导致内部逻辑无法执行或初始化失败。比如Nginx配置文件语法没错，但指向的静态文件路径不对，或者上游服务器地址写错了，服务本身会跑起来，但用户访问会404或502。依赖缺失或故障： 服务依赖的数据库连接失败、外部API不可达、文件系统权限问题、内存不足等。服务进程可能还在尝试重连或等待，但对外表现就是不响应。内部逻辑崩溃： 服务自身的代码逻辑可能存在bug，导致某个关键线程或模块崩溃，但主进程可能设计成不会立即退出，而是尝试恢复或进入某种“僵尸”状态。资源耗尽： 服务可能耗尽了文件句柄、内存、CPU等资源，导致无法处理新的请求。进程还在，但已经“卡死”了。
遇到这种情况，光看
systemctl status
是不够的。最关键的一步是查看服务的日志。
systemctl status
的输出底部通常会显示最近几行日志，但更全面、更深入的排查需要使用
journalctl
命令。通过分析日志，我们才能找到服务内部到底发生了什么，是哪个环节出了错。
如何快速判断一个服务是否开机自启动？
判断一个服务是否开机自启动，在
systemd
系统中非常直接和方便，我通常会用一个命令：
systemctl is-enabled
这条命令会给你一个明确的答案：
enabled
： 这表示服务已经被配置为开机自启动。当系统启动时，
systemd
会尝试启动这个服务。这是最常见的状态，也是我们希望服务能自动启动时的目标。
disabled
： 服务不会在系统启动时自动启动。你需要手动运行
systemctl start
来启动它。
static
： 这种服务通常不包含
[Install]
部分，意味着它不能直接被
systemctl enable
或
disable
。它通常是一个依赖项，由其他服务在启动时隐式地拉起。比如
systemd-journald.service
就是个典型的
static
服务。
masked
： 这是一个比较特殊且“强制”的状态。如果一个服务被
masked
了，它不仅不会开机自启动，甚至你手动去
start
它都会失败。这通常用于彻底阻止某个服务运行，即使有其他服务依赖它，也会被阻止。解除
masked
状态需要使用
systemctl unmask
。
理解这些状态对于系统管理员来说非常重要，它决定了你对服务生命周期的控制能力。我个人在部署新服务时，总会习惯性地检查一下它的
enabled
状态，以确保其行为符合预期。
查看服务状态时，
journalctl
命令有什么用，如何结合使用？
journalctl
命令是
systemd
生态系统中的一个核心工具，用于查询和显示
systemd
日志守护进程（
journald
）收集的日志。在查看服务状态时，它与
systemctl status
是完美的搭档，甚至可以说是排查服务问题的“杀手锏”。
当
systemctl status
告诉你服务正在运行或已停止时，
journalctl
则能深入揭示为什么它会是这个状态，以及它在运行过程中都做了什么。
如何结合使用：
初步判断： 先用
systemctl status
快速了解服务的整体状态。如果服务有问题（例如
Active: failed
或
Active: active (running)
但功能不正常），那么下一步就是查看日志。
查看特定服务的日志：
journalctl -u
这条命令会显示指定服务的所有历史日志。这对于理解服务的启动过程、运行时错误、警告或任何异常行为至关重要。比如，当Nginx服务启动失败时，
journalctl -u nginx
会告诉你具体的配置错误行号，或者权限问题。
实时跟踪日志：
journalctl -u -f
f
是
follow
的缩写，这条命令会实时输出指定服务的新日志条目，类似于
tail -f
。这在调试服务时特别有用，你可以尝试操作服务（比如重启、发送请求），然后实时观察日志输出，看服务如何响应，是否有新的错误或警告出现。
按时间过滤日志：当服务运行了很长时间，日志量可能非常大。为了聚焦问题，我们可以按时间段过滤日志。
journalctl -u --since "2 hours ago"journalctl -u --since "YYYY-MM-DD HH:MM:SS" --until "YYYY-MM-DD HH:MM:SS"
例如，查看Nginx服务从一个小时前到现在的所有日志：
journalctl -u nginx --since "1 hour ago"
这能帮助我们快速定位到问题发生时间点附近的日志。
查看错误和警告：虽然
journalctl
没有直接的错误级别过滤参数，但你可以结合
grep
来查找特定的关键词，例如：
journalctl -u | grep -i "error|fail|warning"
这可以帮助你快速筛选出可能导致服务异常的关键信息。
在我个人的经验中，
journalctl
是Linux系统故障排查中不可或缺的工具。很多时候，服务看起来“活着”，但实际上已经“病了”，而
journalctl
就是那个能告诉你病因的“诊断报告”。没有它，排查复杂的服务问题几乎是不可能完成的任务。
以上就是Linux如何查看服务当前的状态的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/435140.html
微信扫一扫 
支付宝扫一扫 
