Linux运维三剑客：ps、ss、lsof搞定进程与端口排查

深夜两点业务群里一条消息炸开了锅“后台服务是不是挂了端口怎么连不上”运维人碰到这种场景第一反应往往不是猜而是“看”。看什么看进程看端口。进程决定服务活着没有端口决定服务能不能被外面访问到。这两件事一旦掌握清楚大部分故障都能在三分钟内摸出脉络。这套手艺的核心就是我下面要讲的Linux进程与端口“三剑客”ps、ss、lsof。它们不是三个孤立命令而是一套完整的排查体系。这篇文章我会结合真实跑过的现网环境把每个命令的关键参数、使用场景、组合方式以及教科书里不会写的刁钻情况拆开揉碎讲给大家。不管是刚入行的朋友想建立排查思路还是干了几年想查漏补缺这篇文章都值得收藏后照着敲一遍。1. 内容整体设计与思路拆解1.1 为什么进程与端口是运维的第一道关卡无论你管十台机器还是上千个节点的集群日常报警里占比最高的其实就两类一类是“进程挂了”“进程状态异常”“CPU飙升”另一类是“端口不通”“连接失败”“地址被占用”。回头想想你半夜被叫起来的次数是不是大多逃不出这两个范畴原因不复杂。一个服务能不能对外提供能力前提是进程还活着、状态不是僵死并且端口正常监听外界能不能访问它端口又决定了一切。端口就像一扇门门开着、门口没堵服务才算在线。所以排查系统问题第一件事永远是先确认进程和端口的状态。这时候ps、ss、lsof就是你的手电筒和放大镜。有人可能会说“我有监控系统啊告警很全。”但监控只能告诉你出了问题告诉你这个服务端口断开、进程消失却很难告诉你为什么。真正动手解决问题的还是命令行。这也是为什么老运维很少慌——不是胆子大是我能快速看清系统的真实状态。1.2 “三剑客”的选型逻辑为什么偏偏是它们三个我先说为什么不是其他工具。top和htop更适合看资源趋势不如ps在脚本和快照里方便netstat是很多人以前的习惯但新系统上不一定默认安装功能也被替代品覆盖grep、awk、sed是文本处理工具不是系统状态工具。真正能覆盖“进程本身、端口本身、进程和端口关系”这三个维度的就是ps、ss、lsof。一张表说清楚它们各自看什么工具核心回答的问题关键输出最常用场景ps进程在不在、状态如何、是谁的子进程PID、PPID、STAT、START、%CPU、%MEM进程存活检查、状态异常定位、CPU内存观察ss哪些端口开着、连接在什么状态本地地址、远程地址、TCP状态、进程PID端口监听检查、连接数统计、网络故障初判lsof打开这个端口的进程是谁进程名、PID、用户、文件描述符、工作目录端口被占用定位、进程文件句柄检查这三个工具各有侧重组合起来信息就完整了。比如你先用ss发现8080端口正在监听拿到PID再用ps看这个PID的主进程状态和启动时间接着用lsof看这个进程还有哪些文件句柄。这样你不仅知道端口活着还知道它是谁、活了多久、有没有异常。1.3 管道和组合的威力单独使用这些工具回答的是“有/没有”把它们串成管道回答的是“为什么”。这是运维思维的一个关键分水岭。举个例子ss -tlnp | grep 8080输出里有一行带PID和进程名。只要知道端口号就能顺着管道拿到PID。ps -fp $(ss -tlnp | awk /:8080/{print $NF} | awk -F {print $2})这一条看起来复杂但实际就是“先找端口对应的PID再ps查看进程详情”。写熟练了排查速度会快很多。我见过不少同事还在一条条输入命令然后截着屏幕来回切换。其实等你接受了“命令链”的思想一次性能拿到更多信息故障定位速度至少翻一倍。这也是为什么我在这篇文章里不只是给你列命令还会教你怎么把它们串起来用。2. 核心细节解析与实操要点2.1 ps读懂进程状态与血缘关系ps命令家族很老但参数从Unix时代传下来基本没怎么变。主流Linux发行版里常用ps -ef和ps aux两者的区别并不大一般情况下看启动方式和个人偏好。你要习惯的不是命令本身而是那些字段背后的含义。先看STAT列这是进程状态字母缩写足以透露大量信息状态码状态含义现场意义RRunning或可运行正在消耗CPU或排队等待CPU频繁出现很正常长时间高占比需排查S可中断睡眠大多数进程的休息态等待事件或IO正常状态D不可中断睡眠等待IO完成磁盘/网络异常时高发kill不掉需重点排查T停止运行被CtrlZ或者kill -STOP暂停Z僵尸进程死掉但没被父进程回收异常信号的一种I空闲内核线程一般无害不用太紧张看到Z就说明进程已经结束但父进程还没有调用wait回收它遇到D则要格外小心说明进程正在等一个很难中断的IO操作常见于NFS挂载不可达、底层磁盘卡住等情况。ps还能看到进程的血缘关系PPID这一列告诉你父进程是谁。比如一个服务由systemd拉起PPID通常就是1如果是手工启动PPID是当前shell的PID。排查问题时如果你看到一个进程的父进程莫名其妙变成了1说明你已经无法正常追踪它的生命周期这往往是孤儿进程或者被某些工具守护托管的结果。想更细地看线程可以用ps -eLfL列显示线程IDNLWP显示线程数量。进程和线程的关系简单理解就是一个进程是“公司的办公室”线程则是“办公室里的工位”同一个进程的多线程共享内存和资源但PID不同、线程ID不同。排查Java这类多线程应用时ps -eLf top -Hp的组合能帮你快速定位到底哪个线程在消耗CPU。实操示例查看所有Java进程并按内存排序ps aux --sort-%mem | grep java | grep -v grep注意我把grep -v grep也写上了不然你自己那行grep命令会混进结果里新手经常在这里踩坑。如果担心grep匹配到无关进程还可以用pgrep或pgrep -fpgrep -l java pgrep -f spring-boot-app.jarpgrep -f的作用是匹配完整命令行这对那些启动参数长的Java程序尤其好用。2.2 ss用端口状态判断网络健康程度先说为什么用ss。ss是Socket Statistics的缩写它通过读取内核socket信息来获取数据比netstat更快、更完整而且新版系统基本都会自带。netstat以后会慢慢退役我建议新人直接学ss旧脚本里如果还有netstat可以再装个net-tools包来兼容。最常用的组合是ss -tlnp-t 只看TCP-l 只看监听listening状态-n 不做反向域名解析直接显示IP和端口速度快且不烦人-p 显示进程PID和名称需要root权限普通用户只能看到自己的进程想看所有连接而不仅仅是监听把-l去掉改成-ass -tunap其中-u是UDP。网络排障时我习惯先看状态分布ss -s这条命令直接给出当前TCP各状态的汇总比如LISTEN多少个、ESTABLISHED多少个、TIME_WAIT多少个。如果你发现TIME_WAIT数量成千上万那就要关注是否有大量短链接在建立和关闭或者连接池配置出了问题。判断一个端口是否监听常见做法是ss -tlnp | grep :22如果输出里有LISTEN行就说明sshd在跑没有就说明事情大了。端口监听信息里要记住一个大坑0.0.0.0:22表示所有网卡都监听127.0.0.1:8080只表示本机回环地址监听。后者意味着外网根本访问不了被防火墙挡之前你已经先把自己挡在门里了。这也是很多服务“内网通、外网不通”的原因之一。TCP状态对应的含义也很重要。ESTABLISHED表示已经建立连接LISTEN是正在等待连接TIME_WAIT是主动关闭连接的一方等待最后确认CLOSE_WAIT则是对方关闭但本地还没有关闭半开关。实际运维中CLOSE_WAIT堆积很可能说明应用程序没正确调用close方法造成连接泄漏。看到这种状态你的定位方向就变成了程序代码而不是系统性故障了。2.3 lsof以端口反查进程的终极定位lsof的全称是List Open Files在Linux的世界里“一切皆文件”这句话不是白说的。socket、管道、设备节点、普通文件、工作目录统统都可以被lsof看到。所以lsof -i :8080可以找出到底谁占用了8080端口这是排查“Address already in use”最好的命令。先看三种最常用的场景sudo lsof -i :8080 sudo lsof -p 12345 sudo lsof -c java-i :8080查找占用8080端口的进程-p 12345列出PID 12345进程打开的所有文件-c java按进程名匹配一般不适合只输入“java”因为会通配匹配所有Java进程最爽的是lsof -i :8080的输出里有一列叫COMMAND这一列直接显示进程名PID列给出进程号USER列给出运行用户。拿这个信息去ps里一查进程的启动时间和状态就全出来了整个链路就通了。注意lsof部分信息需要root权限。普通用户运行lsof -i时往往只会看到自己进程的信息看不到别人进程到底开了什么文件这样容易误判。所以线上环境排查只要权限允许我都会在命令前面加sudo。这里再强调一个小细节lsof -i :8080和ss -tlnp | grep 8080的结果不一定一样。ss显示的是内核socket信息lsof更倾向从文件描述符角度反查两者配合能让结果更全面。有些端口被多进程共享比如SO_REUSEPORT场景或者被一个不常规的进程持有只看一个工具可能漏掉两个工具一对比就明白了。进阶用法如果想看一个进程的网络连接而不是端口信息可以组合sudo lsof -p 12345 | grep TCP还有一个很少人知道的场景lsof -iTCP:80可以列出所有IPv4和IPv6 TCP连接中80端口相关的socket这对分析Web服务的连接来源很有帮助。2.4 三命令之间的协作模式回到这套系统的核心用管道把三个工具连起来形成一条完整排查链。我来写几个典型组合你可以直接拿去用# 从端口找PID ss -tlnp | grep 8080 # 从PID看进程详情 ps -fp 12345 # 从PID看端口 sudo lsof -p 12345 | grep LISTEN # 从端口找进程再杀掉 sudo fuser -k 8080/tcp最后一条fuser可能不在基础工具箱里但它是一个经典直接向占用端口的进程发送SIGKILL。使用条件必须严格别在关键生产环境乱kill后果很严重。这些组合一旦熟悉你看到报警时大脑会自动生成命令链不会再去翻文档。这也是“火眼金睛”背后真正的功夫——不是看了多少文档而是把工具缝成了体系。3. 实操过程与核心环节实现3.1 场景一服务启动失败报“Address already in use”这个场景我敢说是新人提问排行榜第一启动Spring Boot项目报错bind: address already in use或者启动Nginx时报bind() to 0.0.0.0:80 failed。排查过程我建议按这个顺序走。第一步确认端口到底被谁监听了sudo ss -tlnp | grep 8080如果看到类似这样的输出LISTEN 0 100 0.0.0.0:8080 0.0.0.0:* users:((java,pid12345,fd13))那说明8080端口被一个java进程PID 12345占着。第二步查看这个进程的全貌ps -fp 12345这一步可以看到进程的启动命令、启动时间、运行时长。观察启动时间是不是很久之前的“旧进程”如果是那多半是之前服务的某个残影没关干净。第三步决定杀掉还是留着。杀进程我用两种方式先温柔的SIGTERM让它做好清理工作然后退出如果过了几秒钟还没退出再升级SIGKILL。kill -TERM 12345 sleep 5 kill -KILL 12345不要一上来就kill -9优雅退出能让程序把状态、连接、日志都处理好直接-9容易留下半截子的脏数据。第四步重新验证端口是否已释放ss -tlnp | grep 8080没输出就表示释放干净了可以重新启动服务。这里有一条容易忽略的情况如果服务本身用了SO_REUSEPORT多个进程同时占用同一端口是允许的。比如某些高性能网关会开多个worker进程共享端口。此时杀了一个进程端口依然存在你需要把所有相关进程都清理掉才能释放端口。遇到这种情况用lsof -i :8080把列出的所有PID一起看确认有没有遗漏。3.2 场景二telnet和端口连通性检查到底怎么看通不通运维工作里常有人问“telnet ip 端口命令怎么看通不通”我先直接说结论。执行telnet时如果很快进入一个有内容的黑色空白界面或者显示“Connected to”和Escape character就说明端口通了。如果看到Connection refused说明目标主机上端口没有监听如果是Connection timed out说明网络可能被防火墙挡了、路由不通或主机不可达。只有“Connected”才叫通其他都算没通。通用做法是telnet 192.168.1.100 8080如果系统没安装telnet新版Linux默认不一定装可以改用ncnc -zv 192.168.1.100 8080其中-z表示只扫描不发送数据-v表示verbose输出会比较清楚“Connection to 192.168.1.100 8080 port [tcp/http] succeeded!”还有更轻量的是直接用bash的伪设备timeout 5 bash -c echo /dev/tcp/192.168.1.100/8080 echo port open这段命令的意思是尝试向目标IP端口建立TCP连接如果成功就打印port open。适合不想依赖telnet/nc的场景。另外想测试SSH端口是否通看22端口只是入门。实际中SSH如果不开在默认22比如改成了2222你照样可以用上面的方法测试。安全基线上我也建议默认不把SSH放在标准端口22这样外部扫描怎么连都返回fail能很大程度上减少无差别的暴力尝试。3.3 场景三进程CPU飙升怎么从ps一路查到线程服务没挂但CPU飙到99%这种报警也很常见。我先用下面命令快速找出最耗CPU的进程ps aux --sort-%cpu | head -20找到可疑PID后下一步是看它内部的线程。这里用top的线程模式更好用top -Hp 12345在这个界面里可以直接看到每个线程的CPU占用按下大写P还可以按CPU排序。如果某个线程号一直排在最上面说明真正的热点就在这个线程里。接下来我想把线程ID转成16进制因为Java线程dump、JVM线程日志里记录的是十六进制线程ID。转换方式printf %x\n 4567然后在jstack输出或日志里搜索这个十六进制ID就能定位到具体代码。如果这台机器部署的是Java应用这招特别实用。实测过程中我发现很多CPU飙高的问题最后都不是程序代码本身的bug而可能是GC频繁导致线程震荡或者某个锁竞争导致的阻塞。光看ps不够还必须看线程和调用栈。这时候三剑客解决的是“问题在哪”的定位问题解释真正原因的还得靠应用日志和profile工具。3.4 在国产系统与容器环境里的额外体验现在不少环境都在用Linux国产操作系统其底层内核大多还是完整Linux体系上面积压的命令基本能用ss和lsof一般也没问题无非在包管理上名字略有差异。真正别扭的是容器环境。容器里进程和端口的概念没有变化但呈现方式和宿主机不完全一样。我在容器内执行ss -tlnp发现没有这个命令最常见的原因是镜像太精简没装iproute2。解决办法可以临时安装apt-get update apt-get install -y iproute2或者用/proc直接读取cat /proc/net/tcp这个文件里能看到TCP连接记录十六进制地址和端口解析起来稍显繁琐不像ss那么美观。如果想在宿主机上查看某个容器的进程和端口可以先用docker ps找到容器ID再在宿主机上用ps -ef和ss定位到对应的PID和端口。注意容器内的进程在宿主机上也能看到只是PID号可能在宿主机的Pid Namespace里映射成另一个数字。这层概念理解了你就不会在容器里到处埋怨命令不可用了。4. 常见问题与排查技巧实录4.1 明明端口在监听外部就是连不上遇到这种情况我一般先不怀疑服务先怀疑“地址绑定和防火墙”。登录机器执行ss -tlnp | grep 8080看本地地址是不是0.0.0.0。如果显示的是127.0.0.1:8080那说明服务只监听了回环地址外部主机根本无法访问。这种问题往往在配置里没写对外IP或写成localhost时出现。如果监听地址没问题再检查防火墙。CentOS/RHEL用firewall-cmdUbuntu用ufw也可能有iptables规则快速查看的姿势如下iptables -L -n | head -20如果有DROP规则别急着清空先确认规则顺序是否正常。很多老环境里规则是一层层累加出来的顺序错了会导致合法的连接被拦截。最后还有一种可能云主机的安全组。有时候你在系统内部看一切正常但云平台安全组没放行端口进出数据包在虚拟化层就被丢弃了。遇到这种问题光在Linux上折腾没用还得去云控制台看安全组策略。这是很多人会忽略的最后一环。4.2 进程kill不掉状态是D或Z怎么办D状态进程真的是杀不掉的因为它在等待不可中断的IO。常见原因有三个网络文件系统NFS挂载出了问题、磁盘硬件故障、内核IO路径卡住。你想kill也没用信号根本送不到进程。正确做法是优先恢复底层存储或网络让那个IO请求先完成进程才可能继续运行。如果底层恢复不了那就把服务依赖一拆重启主机或虚拟化平台很多时候就能摆脱困境。Z状态进程僵尸处理起来简单得多它们本身不占CPU和内存但数量多起来会占满PID表系统最终无法再创建新进程。处理方案是找父进程。用pstree或者ps查看PPID如果父进程是PID 1有时你有两个选择要么等systemd自行清理要么直接把相关服务重置。对普通僵尸进程诀窍是杀掉其父进程让僵尸被重新领养并清理。这里必须多说一句不要无脑kill -9。很多新人碰到问题就想-9但-9是最后的底牌不是第一个按钮。先用-15SIGTERM让进程有机会优雅退出过5秒再上-9这样对数据和服务影响最小。4.3 445、135、139这些端口应该如何关掉不少人在搜“445端口如何关闭”。445端口通常与SMB文件共享相关135、139则是老的远程过程调用和NetBIOS端口。它们都是安全基线里经常要求封禁的对象。在Linux上很可能没有这些服务在跑但排查时要会用命令确认ss -tlnp | grep -E :445|:135|:139如果没有输出说明本机没有监听这些端口心里可以踏实一点。如果确实监听了那就通过防火墙封禁可靠的方式iptables -A INPUT -p tcp --dport 445 -j DROP或者用firewalld添加持久化规则然后reload。另外还要看看是不是有服务主动开着比如samba相关组件systemctl disable --now smb nmb这个话题的要点是与其只关注某一个端口不如建立起“最小开放”的策略。如果这台服务器只提供Web服务那只需要80/443和运维管理端口就够了其他一概不开。端口开得少暴露面也就小了。4.4 TIME_WAIT、CLOSE_WAIT这些状态怎么看TIME_WAIT过多并不一定是坏事它是主动关闭方进入的一个安全状态默认60秒后自动消失。很多人一看到TIME_WAIT刷屏就紧张其实不用担心。它占用的只是少量内存和端口号如果大流量短连接服务出现大量TIME_WAIT可以用ss -s看一眼总量再适当调整内核参数sysctl -w net.ipv4.tcp_fin_timeout30但CLOSE_WAIT多就需要高度重视了。CLOSE_WAIT表示本端收到对方的FIN后自己还没发送FIN这说明应用层没有正确关闭socket。典型表现是一堆连接堆积在“半关闭”状态数量过多会导致文件描述符耗尽服务直接不可用。我处理过一次典型的CLOSE_WAIT故障应用是Java写的HTTP客户端底层连接池里的连接被服务端回收后客户端还继续复用这些连接于是出现了大量CLOSE_WAIT。最终解决方案是升级客户端连接池的心跳和重试策略。这种问题就不是三剑客能直接解决的但它们能帮你快速定位到CLOSE_WAIT的存在和规模——这已经是成功的一半了。4.5 常用命令速查表快查表放最后省得大家翻来翻去排查目标命令查看所有监听TCP端口ss -tlnp查看指定端口占用ss -tlnp | grep :8080 或 sudo lsof -i :8080查看端口对应进程详情ps -fp PID按内存排序查看进程ps aux --sort-%mem按CPU排序查看进程ps aux --sort-%cpu查看进程内线程ps -eLf | grep PID 或 top -Hp PID测试远程端口连通telnet IP 端口 / nc -zv IP 端口查看TCP连接总量状态ss -s杀掉占端口进程fuser -k 8080/tcp查看僵尸或D状态进程ps -eo pid,stat,comm | awk $2 ~ /Z|D/5. 写在最后我的一点个人心得写了这么多最后也说几句心里话。我在很多系统上调试过问题从刚开始只看一条报警手忙脚乱试命令到后来形成了稳定的排查节奏最大的改变不是记住了多少命令而是培养了一种“状态感”。命令很重要但把ps、ss、lsof当成一个整体去用更加关键你看到任何报警时都会下意识去获取系统快照再决定下一步动作而不是蒙着头乱试。我自己的习惯是登录机器先抓三张快照ps -eo pid,stat,comm看进程清单ss -tlnp看监听状态ss -s看连接汇总。然后才去业务日志里找线索。很多时候问题已经定位出来了真正难的是分析为什么会变成现在这样别让现象牵着鼻子走。这套东西不需要背用得多了自然就长在身上了。希望大家都能练出自己的“火眼金睛”半夜少被叫起来几次这就是运维人的最大幸福。