首页 > 网站技巧 > 服务器 > Linux > Linux检查服务是否运行的方法

在Linux系统中检查服务是否运行的三种主要方法

2026-05-20 08:51:16 作者：穆金秋

本文介绍了三种在Linux系统中检查服务是否运行的方法：systemctl status（推荐,适用于现代Linux系统）,ps -ef |grep 服务名（通用,适用于所有Linux系统）和netstat/ss检查端口监听情况（适用于任何Linux系统）,文章详细解释了每种方法的优缺点和使用场景

本文介绍了在Linux系统中检查服务是否运行的三种主要方法：

推荐使用systemctl status命令（适用于现代Linux系统），可查看单个服务状态或列出所有运行/失败的服务，重点关注Active行状态。
通用方法ps -ef | grep 服务名（适用于所有Linux系统），通过检查进程列表判断服务是否运行，建议配合grep -v grep过滤自身进程。
使用netstat/ss检查端口监听情况，确认服务是否在监听指定端口。

文章还通过实际案例演示了如何检查大数据组件和MySQL服务的运行状态，并提供了快速对比表帮助选择合适的方法。

最后指出，当ps -ef输出中只有grep进程时，说明目标服务未运行，建议检查安装情况或尝试启动服务。

在 Linux 中查看服务是否启动

有 3 种主流方法，按推荐顺序排列：

方法一：systemctl status（最推荐，现代 Linux 通用）

# 查看单个服务状态
systemctl status sshd
systemctl status mysql
systemctl status httpd

# 输出关键信息
# ● sshd.service - OpenSSH server daemon
#    Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled)
#    Active: active (running) ... ← 看到 active (running) 表示正在运行

重点关注 Active 行：

状态	含义
`active (running)`	✅ 正在运行
`inactive (dead)`	❌ 未运行
`failed`	❌ 启动失败

# 查看所有正在运行的服务
systemctl list-units --type=service --state=running

# 查看所有失败的服务（排查问题常用）
systemctl list-units --type=service --state=failed

方法二：ps -ef | grep 服务名（最通用，任何 Linux 都支持）

ps -ef | grep mysql

输出示例：

mysql    1234     1  0 10:00 ?        00:00:01 /usr/sbin/mysqld
hadoop   5678  1234  0 10:05 pts/0    00:00:00 grep --color=auto mysql

判断方法：

看到 /usr/sbin/mysqld 这样的进程 → ✅ 服务已启动
只有 grep 那一行 → ❌ 服务未启动

优化写法（去掉 grep 自身那一行）：

ps -ef | grep mysql | grep -v grep

方法三：netstat/ss查端口（验证服务是否在监听）

# 查看指定端口是否被监听
netstat -tlnp | grep 3306
# 或
ss -tlnp | grep 3306

输出示例：

LISTEN 0 128 0.0.0.0:3306 0.0.0.0:* users:(("mysqld",pid=1234,fd=14))

看到 LISTEN 说明服务在监听该端口 → ✅ 服务已启动

常用端口速查：

服务	默认端口
SSH	22
MySQL	3306
Oracle	1521
Tomcat	8080
HDFS NameNode Web UI	9870
YARN ResourceManager	8088

快速对比表

方法	命令	优点	适用场景
systemctl	`systemctl status 服务名`	信息最全、最规范	首选，systemd 系统
ps	`ps -ef \| grep 服务名`	通用、任何 Linux 都能用	老旧系统、快速确认
netstat/ss	`ss -tlnp \| grep 端口`	确认端口是否监听	排查端口占用、服务假死

实战示例：检查大数据组件是否启动

# 检查 HDFS NameNode
systemctl status hadoop-hdfs-namenode
# 或
ps -ef | grep NameNode | grep -v grep

# 检查 YARN ResourceManager
systemctl status hadoop-yarn-resourcemanager
# 或
ps -ef | grep ResourceManager | grep -v grep

# 检查 MySQL
systemctl status mysqld
# 或
ps -ef | grep mysqld | grep -v grep
# 或
ss -tlnp | grep 3306

总结一句话

优先用 systemctl status 服务名

没有 systemctl 的老系统用 ps -ef | grep 服务名

再配合 ss -tlnp | grep 端口 确认端口监听

mumu@MuJinqiu:~/bigdata/2026/test$ ps -ef | grep mysql
mumu      487546  270201  0 14:02 pts/3    00:00:00 grep --color=auto mysql
mumu@MuJinqiu:~/bigdata/2026/test$

从这个输出可以判断：当前系统中没有运行的 MySQL 进程。

一、输出解读

mumu 487546 270201 0 14:02 pts/3 00:00:00 grep --color=auto mysql

列	值	含义
用户名	`mumu`	进程属于 mumu 用户
PID	`487546`	进程 ID
命令	`grep --color=auto mysql`	这是你刚敲的 `grep` 命令本身

关键点：只有 grep 自己的进程，没有 mysqld 或其他 MySQL 相关进程。

结论：MySQL 没有运行

二、为什么会出现这种情况？

可能性	说明
MySQL 未安装	根本没装 MySQL
MySQL 已安装但未启动	装了一直没启动
MySQL 已安装且之前启动了，但挂了	运行过但崩溃或被 kill 了
当前用户权限不足	`ps -ef` 能看到所有进程，跟权限无关

三、下一步排查建议

1. 检查 MySQL 是否安装

# 检查是否安装了 mysql 包
dpkg -l | grep mysql        # Ubuntu/Debian
rpm -qa | grep mysql        # CentOS/RHEL

# 或者找 mysql 相关文件
which mysql
ls /usr/sbin/mysqld

2. 尝试启动 MySQL（如果已安装）

# 方式1：systemctl（现代 Linux）
sudo systemctl start mysql
# 或
sudo systemctl start mysqld

# 方式2：直接启动（某些旧版本）
sudo service mysql start

# 启动后再次检查
ps -ef | grep mysql | grep -v grep

3. 如果提示command not found

说明 MySQL 根本没装，需要先安装：

# Ubuntu/Debian
sudo apt update && sudo apt install mysql-server -y

# CentOS/RHEL
sudo yum install mysql-server -y

四、附：grep -v grep的作用

你之前的命令没有加 grep -v grep，所以 grep 自己也被列出来了。

# 会包含 grep 自己
ps -ef | grep mysql

# 排除 grep 自己，结果更干净
ps -ef | grep mysql | grep -v grep

对比：

# 不加 -v grep：看到一行（grep 自身）
ps -ef | grep mysql
# mumu  487546  ... grep --color=auto mysql

# 加 -v grep：完全没输出 → 说明真的没有 mysql 进程
ps -ef | grep mysql | grep -v grep
# （无输出）

总结一句话

你的输出里只有 grep 自己，说明 MySQL 没有运行。

用 systemctl start mysql 启动，或用 which mysql 检查是否安装。

PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
      1 root      20   0   22104  12880   9168 S   0.0   0.1   0:48.44 systemd
      2 root      20   0    3120   1920   1920 S   0.0   0.0   0:00.28 init-systemd(Ub
      7 root      20   0    3168   1952   1792 S   0.0   0.0   0:00.13 init
     40 root      19  -1   66824  15132  14236 S   0.0   0.1   6:03.07 systemd-journal
     86 root      20   0   25412   6400   4864 S   0.0   0.0   1:05.71 systemd-udevd
    148 systemd+  20   0   21460  12672  10496 S   0.0   0.1   0:08.82 systemd-resolve
    149 systemd+  20   0   91028   7552   6656 S   0.0   0.0   0:23.68 systemd-timesyn
    155 root      20   0    4236   2560   2432 S   0.0   0.0   0:01.82 cron
    156 message+  20   0    9824   4992   4480 S   0.0   0.0   0:30.69 dbus-daemon
    163 root      20   0   18036   8320   7424 S   0.0   0.1   0:10.61 systemd-logind
    171 root      20   0    3160   1920   1792 S   0.0   0.0   0:00.00 agetty
    174 syslog    20   0  222508   5120   4224 S   0.0   0.0   0:05.57 rsyslogd
    187 root      20   0    3116   1792   1664 S   0.0   0.0   0:00.00 agetty
    201 root      20   0  107008  22272  13184 S   0.0   0.1   0:00.04 unattended-upgr
    280 root      20   0    3156   1300   1152 S   0.0   0.0   0:00.00 Relay(281)
    282 root      20   0    6820   4480   3712 S   0.0   0.0   0:00.00 login
    325 mumu      20   0   20312  10880   8960 S   0.0   0.1   0:06.69 systemd
    326 mumu      20   0   21156   3520   1792 S   0.0   0.0   0:00.00 (sd-pam)
    348 mumu      20   0    9768   8448   3328 S   0.0   0.1   0:00.02 bash
    587 mumu      20   0    2800   1664   1664 S   0.0   0.0   0:00.00 sh
    599 mumu      20   0   11.3g 135336  47488 S   0.0   0.8   7:39.32 node
    851 mumu      20   0   11.1g  70200  43136 S   0.0   0.4   0:55.84 node
 196242 polkitd   20   0  308164   7808   7040 S   0.0   0.0   0:14.26 polkitd
 270068 root      20   0   12024   7936   6912 S   0.0   0.0   0:00.00 sshd
 270086 root      20   0   14964  10344   8704 S   0.0   0.1   0:00.04 sshd
 270089 root      20   0   14976  10344   8704 S   0.0   0.1   0:00.03 sshd
mumu@MuJinqiu:~/bigdata/2026/test$

这张 top 进程列表信息量很大！

你已经成功在 Linux 环境里跑起了前端开发相关的服务

针对你之前关注的“MySQL 启动问题”，结合这张表，分析如下：

1. 核心结论：确实没有 MySQL

在这份完整的进程列表里（从 PID 1 到 27 万），完全没有 mysqld（MySQL 服务进程）。

这证实了之前的判断：你的 WSL 子系统里确实没有安装 MySQL，或者安装了但从未启动成功。

2. 惊喜发现：你已经在跑 Node.js 服务！

列表中出现了两个非常熟悉的进程，说明你作为前端开发者的身份已经暴露了

PID	用户	内存占用	说明
599	mumu	0.8%	Node.js 主进程（运行了 7 个多小时）
851	mumu	0.4%	另一个 Node.js 进程（运行了近 1 小时）

这意味着：你的 Ubuntu 环境是正常的，并且你已经成功运行了 JavaScript/Node.js 项目。既然 Node 能跑，装 MySQL 也完全没问题。

这两个node进程说明：

你正在运行 Node.js 应用程序
可能是前端开发服务器（Vite / Webpack Dev Server）、后端 API 服务（Express / Nest）、或者 Hexo 博客等

如何查看具体是哪个项目/命令？

方法1：查看完整命令行（推荐）

ps -ef | grep node | grep -v grep

输出会显示完整的启动命令，比如：

mumu   599  ...  node /home/mumu/my-project/node_modules/.bin/vite
mumu   851  ...  node /home/mumu/backend/server.js

方法2：用 top 按 c 键

在 top 界面里按 c，COMMAND 列会显示完整命令路径
再按一次 c 恢复

方法3：查看进程的工作目录

# 查看 PID 599 的启动目录

ls -l /proc/599/cwd

方法4：查看进程打开的端口（判断是什么服务）

# 查看 node 进程监听了哪些端口
sudo netstat -tlnp | grep node
# 或
sudo ss -tlnp | grep node

常见 Node 端口：

端口	常见用途
3000	Express / React dev server
5173	Vite dev server
8080	Webpack / http-server
9229	Node inspector 调试端口

mumu@MuJinqiu:~/bigdata/2026/test$ ps -ef | grep node | grep -v grep
mumu         599     587  0 May04 ?        00:07:40 /home/mumu/.cursor-server/bin/93e276db8a03af947eafb2d10241e2de17806c20/node /home/mumu/.cursor-server/bin/93e276db8a03af947eafb2d10241e2de17806c20/out/server-main.js --start-server --host=127.0.0.1 --port=0 --connection-token-file /home/mumu/.cursor-server/.93e276db8a03af947eafb2d10241e2de17806c20.token --telemetry-level off --use-host-proxy --disable-websocket-compression --without-browser-env-var --accept-server-license-terms
mumu         851     599  0 May04 ?        00:00:55 /home/mumu/.cursor-server/bin/93e276db8a03af947eafb2d10241e2de17806c20/node /home/mumu/.cursor-server/bin/93e276db8a03af947eafb2d10241e2de17806c20/out/bootstrap-fork --type=ptyHost --logsPath /home/mumu/.cursor-server/data/logs/20260403T190048
mumu@MuJinqiu:~/bigdata/2026/test$

用 Cursor 连接到了 WSL（或者直接打开了 WSL 里的文件夹）。Cursor 会自动在 WSL 里部署一个“远程服务器”来实现：

代码补全
终端集成
文件浏览
调试

这就是为什么你看到它们一直在运行，而且 COMMAND 里很多 cursor-server 相关的路径。

Cursor 编辑器没有打开，但后台却有 Cursor 的进程在运行，这其实很正常。

验证 Cursor 进程是否还被使用

# 查看这些进程的启动时间
ps -p 599,851 -o pid,lstart,cmd

如果启动时间是几个月前，说明是旧残留；
如果是今天或最近，说明某个工具还在用。

PID                  STARTED CMD
    599 Mon May  4 21:10:53 2026 /home/mumu/.cursor-server/bin/93e276db8a03af947eafb2d10241e2de1
    851 Mon May  4 21:10:58 2026 /home/mumu/.cursor-server/bin/93e276db8a03af947eafb2d10241e2de1
mumu@MuJinqiu:~/bigdata/2026/test$

这两个进程是2026年5月4日启动的，距离现在已经10 天了。

项目	结论
启动时间	2026年5月4日（已运行10天）
当前状态	Cursor 编辑器早已关闭，但后台服务还在运行
是否正常	✅ 正常，这是远程开发工具的设计行为
是否影响工作	❌ 不影响，内存占用很小
你的其他软件	PyCharm、SQL Developer、VSCode、MobaXterm 都与此无关

一、为什么过了 10 天还在？

Cursor（以及 VS Code）的远程服务器设计为持久运行：

第一次连接 WSL 时自动部署
之后即使关闭本地编辑器，WSL 里的服务不会自动退出
下次打开 Cursor 连接 WSL 时，直接复用现有服务，速度更快

相当于：Cursor 在你 WSL 里"安家"了，除非你主动让它搬走。

二、要不要清理？

选择	做法	影响
留着不管	什么都不做	下次用 Cursor 打开 WSL 更快，内存占用忽略不计
手动清理	`kill -9 599 851`	释放几十 MB 内存，下次 Cursor 连接时会重新部署

建议：留着。反正你 WSL 内存充足（之前 top 显示 15.6G 总内存，只用了一小部分）。

三、如何防止以后再自动部署？

如果你确定再也不需要用 Cursor 编辑 WSL 里的文件，可以删除它的服务器文件：

# 删除 Cursor 在 WSL 里部署的服务端
rm -rf ~/.cursor-server

# 杀掉当前进程
kill -9 599 851

# 验证
ps -ef | grep cursor | grep -v grep

下次 Cursor 连接 WSL 时会重新部署，但至少现在清干净了。

如何管理这些 Node 进程？

# 查看所有 node 进程详情
ps aux | grep node

# 查看某个端口被哪个 node 进程占用
sudo lsof -i :3000

# 重启/停止进程（如果知道进程管理器）
pm2 list           # 如果用了 pm2
pm2 stop 0         # 停止某个

# 直接 kill 进程（不推荐，除非卡死）
kill -15 599       # 优雅关闭

3. 其他环境观察（对你后续工作有帮助）

组件	状态	说明
SSH 服务 (`sshd`)	✅ 正常	有 root 进程在监听
定时任务 (`cron`)	✅ 正常	后台运行中
系统日志 (`rsyslog`)	✅ 正常	日志记录正常
你的 Shell (`bash`)	✅ 正常	PID 348，正是你当前的操作界面

结论：你的 Linux 环境本身是非常健康的，只是缺少 MySQL 服务。

4. 接下来可以这样操作

第一步：确认你是否需要 MySQL

如果你的项目用 MongoDB 或 其他云数据库，那就不需要装 MySQL。
如果是全栈项目，需要 MySQL，那么确实还没装。

第二步：检查软件源并安装 MySQL

# 1. 更新软件源（确保能装最新版）
sudo apt update

# 2. 安装 MySQL 服务端
sudo apt install mysql-server -y

# 3. 查看 MySQL 是否启动
sudo systemctl status mysql
# 如果没启动，手动启动
sudo systemctl start mysql

第三步：安装后验证

# 查看进程（应该能看到 mysqld）
ps -ef | grep mysql | grep -v grep

# 尝试登录
sudo mysql
# 或者（如果设置了密码）
mysql -u root -p

5. 一个小建议

从 top 输出能看到：

%Cpu(s): 0.0 us → CPU 几乎空闲
Mem: 15.6G total, 13.5G free → 内存非常充足

你的电脑配置很好，跑几个 MySQL、Node、Redis 同时运行都没问题。

总结

当前没有 MySQL ✅ 确认
你的 WSL Ubuntu 环境正常 ✅ 确认
你已经成功运行了 Node.js ✅ 意外收获
下一步：sudo apt install mysql-server 即可

Ubuntu = 一个开箱即用的 Linux 系统，适合新手和服务器

特点	说明
基于 Debian	最稳定的 Linux 基础系统之一
易上手	图形界面友好，新手友好
免费开源	完全免费，代码开放
软件丰富	`apt` 命令一键安装软件
社区庞大	遇到问题容易搜到解决方案
企业支持	腾讯云、阿里云默认镜像之一

常见版本

版本	说明
Ubuntu Desktop	桌面版，有图形界面，适合日常使用
Ubuntu Server	服务器版，无桌面，适合做服务器
WSL Ubuntu	Windows 子系统里的 Ubuntu（你现在用的就是这个）

mumu@MuJinqiu:~$   # @后面的 MuJinqiu 是主机名，这就是 Ubuntu 系统
sudo apt update    # apt 是 Ubuntu 的包管理命令

ps -ef 和 top 的区别

ps -ef 和 top 是 Linux 里最常用的两个查看进程的命令，但它们的设计目的和使用场景完全不同。

简单来说：ps -ef 是给系统拍一张"照片"，top 是给系统放一段"视频"。

一、核心区别一句话

命令	比喻	特点
`ps -ef`	拍照	显示某一瞬间的进程状态，执行完就结束
`top`	录像	实时持续刷新，动态显示进程变化，按 `q` 退出

二、详细对比表

对比维度	ps -ef	top
更新方式	一次性输出，执行完就结束	实时刷新（默认每 3 秒）
适用场景	脚本、管道、快速查看	交互式监控、实时观察
CPU/内存占用	低（只跑一次）	相对较高（持续刷新）
是否交互	❌ 非交互	✅ 可交互（排序、杀进程等）
输出格式	固定列，简洁	分两屏：摘要区 + 进程列表
历史数据	只看当前瞬间	可看到 CPU/内存的变化趋势
常用参数	`-ef`、`-aux`	进入后按 `P`/`M` 排序

三、输出对比

ps -ef输出示例

UID          PID    PPID  C STIME TTY          TIME CMD
root           1       0  0 10:00 ?        00:00:01 /sbin/init
root         123       1  0 10:00 ?        00:00:00 /usr/sbin/sshd
mumu        4567    1234  0 14:30 pts/0    00:00:00 bash
mumu        4789    4567  0 15:00 pts/0    00:00:00 ps -ef

只有一屏，执行完就结束
列固定：PID、PPID、CPU 使用率（C 列）、启动时间、命令

top输出示例

top - 15:01:23 up 5:01,  2 users,  load average: 0.00, 0.01, 0.05
Tasks: 112 total,   1 running, 111 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.3 us,  0.2 sy,  0.0 ni, 99.5 id,  0.0 wa,  0.0 hi,  0.0 si
MiB Mem :  15985.0 total,  10234.5 free,   3210.1 used,   2540.4 buff/cache
MiB Swap:   2048.0 total,   2048.0 free,      0.0 used.  12000.3 avail Mem
    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
    599 mumu      20   0   11.3g 135336  47488 S   0.0   0.8   7:39.32 node
    851 mumu      20   0   11.1g  70200  43136 S   0.0   0.4   0:55.84 node
      1 root      20   0   22104  12880   9168 S   0.0   0.1   0:48.44 systemd

分两屏：顶部是系统摘要（负载、CPU、内存），下面是进程列表
自动刷新（每 3 秒）
按 q 退出

四、使用场景指南

什么时候用ps -ef？

场景	说明	示例
脚本中检查进程	一次性判断服务是否在跑	`ps -ef \| grep mysql`
获取某个 PID	快速拿到进程 ID	`ps -ef \| grep java \| awk '{print $2}'`
查看父子进程关系	PPID 列显示父进程	`ps -ef \| grep 1234`
管道组合处理	输出是纯文本，方便 grep/awk	`ps -ef \| sort -k4`

什么时候用top？

场景	说明	操作方法
实时监控 CPU/内存	观察哪个进程在"偷吃"资源	直接运行 `top`
找出最耗 CPU 的进程	按 CPU 使用率排序	按 `P` 键（大写）
找出最耗内存的进程	按内存使用率排序	按 `M` 键（大写）
实时观察负载变化	看 load average 的 1/5/15 分钟值	看顶部第一行
杀死一个进程	在 top 里直接杀	按 `k` 再输入 PID
监控特定用户	只看某个用户的进程	按 `u` 再输入用户名

五、一个内存小技巧

很多面试官会问：如何实时查看 CPU 占用最高的进程？

# 方法1：top + 按 P（推荐）
top   # 进入后按大写的 P

# 方法2：ps 拍一次照（不实时）
ps -aux --sort=-%cpu | head -10

# 方法3：htop（更美观的 top，需要安装）
sudo apt install htop && htop

六、与前端开发的类比

Linux	前端类比
`ps -ef`	`console.log(process)` — 打印当前状态的快照
`top`	Chrome 任务管理器（`Shift+Esc`） — 实时刷新，显示 CPU/内存变化
`htop`	更现代的 Chrome 任务管理器，颜色更丰富，可交互

理解要点：

你需要确认某个服务是否在跑 → 用 ps -ef | grep 服务名（拍照）
你需要排查为什么电脑突然卡了 → 用 top（看视频，找元凶）

总结

命令	一句话总结
`ps -ef`	静态快照：看一眼就走，适合脚本和快速查询
`top`	动态监控：一直盯着看，适合排查性能问题

记住：ps 是照片，top 是视频。照片用来看"有没有"，视频用来看"在干嘛"。

以上就是在Linux系统中检查服务是否运行的三种主要方法的详细内容，更多关于Linux检查服务是否运行的方法的资料请关注脚本之家其它相关文章！

在Linux系统中检查服务是否运行的三种主要方法

在 Linux 中查看服务是否启动

方法一：systemctl status（最推荐，现代 Linux 通用）

方法二：ps -ef | grep 服务名（最通用，任何 Linux 都支持）

方法三：netstat/ss查端口（验证服务是否在监听）

快速对比表

实战示例：检查大数据组件是否启动

总结一句话

从这个输出可以判断：当前系统中没有运行的 MySQL 进程。

一、输出解读

二、为什么会出现这种情况？

三、下一步排查建议

1. 检查 MySQL 是否安装

2. 尝试启动 MySQL（如果已安装）

3. 如果提示command not found

四、附：grep -v grep的作用

总结一句话

你已经成功在 Linux 环境里跑起了前端开发相关的服务

1. 核心结论：确实没有 MySQL

2. 惊喜发现：你已经在跑 Node.js 服务！

3. 其他环境观察（对你后续工作有帮助）

4. 接下来可以这样操作

5. 一个小建议

总结

ps -ef 和 top 的区别

一、核心区别一句话

二、详细对比表

三、输出对比

ps -ef输出示例

top输出示例

四、使用场景指南

什么时候用ps -ef？

什么时候用top？

五、一个内存小技巧

六、与前端开发的类比

总结

您可能感兴趣的文章: