查看Linux服务器上有哪些服务，核心就三条路：systemctl看服务单元、ps看进程、ss/netstat看端口监听。分别对应“装了什么、正在跑什么、对外开了什么”，三者交叉验证才能还原完整服务全景，下文按实操优先级逐步拆解。
先搞清一个误区：服务≠进程≠端口
很多新手把ps -ef列出来的几十行当成全部服务，这是常见的理解偏差，服务是系统通过systemd或init管理的单元，具备开机自启、依赖关系、重启策略等属性，进程是服务运行后产生的实际执行实体，端口则是进程对外通信的入口，一个服务可能对应多个进程，一个进程也可能监听多个端口，而有些进程根本没监听任何端口只做内部计算，所以linux服务器查看服务命令要按视角分开看，下面逐个说明。
linux服务器查看服务命令有哪些？常用三条路径
用systemctl精确枚举服务单元
现代主流发行版（CentOS 7+、Ubuntu 16+、Debian 8+）都用systemd管理服务，这是最权威的查看入口。
- 查看正在运行的服务：
systemctl list-units --type=service --state=running - 查看所有已加载的服务（含未运行）：
systemctl list-units --type=service --all - 查看所有服务单元文件（含被禁用、静态的）：
systemctl list-unit-files --type=service
输出中loaded表示单元已加载，active running表示服务正在运行，enabled表示开机自启，实操时先跑第一条，立刻能看到当前活跃服务清单，比慢慢翻ps输出直观得多，想看某个服务细节，直接systemctl status 服务名，能同时拿到主进程PID、最近日志、内存占用、监听地址等信息，省去手动拼接多个命令。
用ps从进程视角反向发现服务
systemctl只能看到受systemd托管的服务,某些老程序、临时启动的脚本、编译安装的守护进程不在其中，这时ps就派上用场。
- 全量进程：
ps -ef - 带资源占用：
ps aux --sort=-%mem - 按关键词过滤：
ps -ef | grep java或pgrep -a java
判断一个进程是不是服务,看它的父进程，PID为1的进程叫systemd，所有正常初始化的服务子进程都挂在它下面进程树里如果看到一个常驻进程的父PID是1，基本可以判定它是被systemd拉起的服务，如果父进程PID是其他值，可能是被命令行手动启动的一次性任务或子进程，配合pstree -p查看进程树，能快速理清服务间的父子依赖关系。
用ss结合netstat确认端口归属
系统跑着服务,但看不到监听端口，通常配置或网络隔离有问题，反之，有端口监听却查不到服务，可能是非托管进程或容器映射，端口审计必须单独做。
- 查看所有监听端口：
ss -tlnp - 只看TCP监听：
ss -tln - 只看UDP监听：
ss -uln - 老系统用：
netstat -tlnp
ss输出比netstat更简洁，且不依赖net-tools包。-p参数能把进程名和PID一并列出来，实践中最常用，若发现端口被-p显示为，说明当前用户无权查看进程信息，需要sudo重试，想确认某个端口归属，直接lsof -i:8080或ss -tlnp | grep 8080。
服务自启状态怎么查
服务正在跑不代表重启后还会跑,需要配合开机自启状态判断。
- 查看所有服务的自启设置：
systemctl list-unit-files --type=service | grep enabled - 查看单个服务自启状态：
systemctl is-enabled 服务名 - 临时关闭服务但保留自启：
systemctl stop 服务名 - 永久关闭：
systemctl disable --now 服务名
行业共识认为,运维巡检时应把“运行中”和“自启动”分开审计，因为很多安全事件就发生在服务未运行但自启状态仍旧保留的情况下，下次重启自动拉起，入侵痕迹就藏在这条缝隙中。
systemctl和service命令对比，怎么选
老系统管理员习惯次用service或chkconfig，这两个在SysV时代是主力，新系统上service虽然还可用，但只是个转发壳，实际调用systemctl逻辑，查看信息不完整，对比表格如下：
| 对比项 | systemctl | service/chkconfig |
|---|---|---|
| 适用系统 | CentOS 7+、Ubuntu 16+ | CentOS 6、Debian 7及更早 |
| 查看运行状态 | 支持，信息全面 | 仅返回简单状态 |
| 查看自启配置 | 支持enabled/disabled/static | chkconfig –list查看 |
| 列出全部服务 | 支持list-unit-files | 不支持 |
| 查看依赖关系 | 支持 | 不支持 |
| 统一管理接口 | 同时启动/停止/重载 | 仅启动/停止 |
业内专家指出,还在生产环境用CentOS 6的单位，应当优先考虑迁移，毕竟SysV时代连服务的崩溃自动恢复能力都是缺席的，如果必须在老系统上排查，用service --status-all能看到所有SysV服务状态，但粒度很粗，只能区分“运行中”和“已停止”。
linux服务器怎么查看端口占用和开放端口，实战组合拳
新部署的Web应用起不来
先跑systemctl status 应用名看日志，再跑ss -tlnp | grep 端口号确认监听是否生效，如果应用配置监听8080，但ss输出显示8080已被其他进程占用，用
lsof -i:8080直接查出占用进程PID，再ps -fp PID确认身份，多数情况下这是端口冲突，解决思路是改应用端口或者停掉旧进程，不是硬杀PID了事。
怀疑服务器被植入隐藏服务
安全审计时,优先核对开放端口与预期业务端口清单的差异，跑完ss -tlnp后，把所有监听端口整理成列表，逐一确认归属业务，对不上号的端口用ss -tlnp | awk '{print $7}' | sort -u提取进程信息批量排查，对外暴露的端口越少面越小，这里遵循最小化原则。
容器环境下的服务定位
Docker容器内部跑的服务,宿主机的systemctl查不到单元，但ss -tlnp能看到进程信息，容器进程通常在宿主机上以docker-proxy或containerd-shim形态存在，排查流程：ss -tlnp看到监听端口 → 进程名指向docker-proxy → docker ps按端口映射反查容器 → docker logs看容器内服务日志，记住这条链路，排查容器化服务能少走弯路。
服务运行等级和状态枚举
systemd定义了几种关键状态,理解它们有助于快速判断服务健康度：
active (running)：主要进程在运行，正常态active (exited)：一次性服务任务完成，进程退出，但服务状态保留active (waiting)：进程常驻，但正在等待事件触发inactive (dead)：服务未运行failed：启动过程出错，需要看journal日志
看到failed不要盲目restart，先journalctl -u 服务名 --no-pager | tail -50看清失败原因，修复配置后再启动，否则会陷入restart循环的坑。
服务日志怎么关联服务状态
排查服务时,命令输出只能告诉你“服务当时是什么状态”，日志才能回答“为什么变到这个状态”，systemd在主流发行版上接管了日志收集，统一用journalctl查询：
- 查单个服务日志：
journalctl -u 服务名 - 查看最近50行：
journalctl -u 服务名 -n 50 - 实时跟踪：
journalctl -u 服务名 -f - 找错误级别日志：
journalctl -u 服务名 -p err
普通应用的日志文件还在/var/log/下，常见的有/var/log/messages（系统全局日志，CentOS的老传统）、/var/log/syslog（Debian系）、/var/log/nginx/access.log（Web访问日志），日志文件时常被logrotate轮转，排查历史问题时留意一下压缩包归档，别只看当前文件。
服务自启管理的完整操作路径
从查看状态到管理状态,完整路径如下：
- 枚举服务：
systemctl list-unit-files --type=service得到全量清单 - 过滤自启项：
systemctl list-unit-files --type=service | grep enabled
- 交叉核对进程：
ps -ef | grep 服务名 - 核对端口：
ss -tlnp | grep 服务名或ss -tlnp | grep PID - 检查日志：
journalctl -u 服务名 --no-pager - 停用异常服务：
systemctl disable --now 服务名 - 重载配置：
systemctl daemon-reload（改过unit文件后必须执行）
这套流程既能在日常巡检中快速摸底,也能在可疑行为出现时做深度取证，没有多余操作，每条命令都指向明确事实。
一台服务器上常见服务类型速查
结合多年运维场景,多数Linux服务器上的服务大致分为以下几类，知道它们长什么样，排查时能先画个轮廓：
- Web服务：nginx、httpd、apache2，监听80/443
- 数据库服务：mysqld、mariadb、postgresql、redis-server，监听3306/5432/6379
- 容器相关：docker、containerd、kubelet，监听2375/10250（注意2375别裸奔到公网）
- 远程管理：sshd，监听22
- 定时任务：crond、atd，一般不监听端口
- 日志采集：rsyslog、filebeat、logstash，端口取决于配置
- 监控类：node_exporter、zabbix_agentd，监听9100/10050
- 消息队列：rabbitmq、kafka，监听5672/9092
熟悉这份清单,实施排查时能迅速判断陌生服务是常见组件还是可疑程序，再决定是继续追查还是直接封禁。
Q&A：linux服务器服务查看常见问题
systemctl查不到服务但进程存在，可能是什么原因？
三种常见情况：服务以独立脚本方式启动，没有编写systemd单元文件；服务运行在容器或虚拟化隔离环境中，宿主机systemctl不感知；服务由supervisor或pm2等第三方守护工具拉起，用ps -ef查父进程即可区分，若父进程是PID 1但systemctl无单元，多半是脚本直接托管；父进程是node或python，则是被上层工具拉起。
怎么看一个端口有没有对外开放？
先ss -tln确认监听状态，重点看Local Address列，监听0.0.0或表示绑定所有网卡，公网卡激活时就等于对外暴露，监听0.0.1表示只本机可访问，想更严谨，在服务器外或安全组放行后用telnet 服务器IP 端口做连通性测试，结果以外部视角为准，防止被本机防火墙策略干扰判断。
服务状态显示active (exited)是不是坏事？
不一定是。active (exited)代表服务主体任务已经完成，进程退场，但服务保持托管状态，常见的cron、dbus等一次性任务服务都会这样，属正常现象，关键判断依据是业务是否依赖常驻进程，如果预期该常驻进程却不在了，优先排查崩溃原因，用journalctl -u 服务名 -n 50看退出码和报错信息，结合日志下结论。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/736661.html
