Linux故障应按资源层→服务层→日志层→网络权限层→系统层级链排查:先用top/htop、free、df、iostat查CPU、内存、磁盘、I/O;再用systemctl、journalctl、ss定位服务与端口;结合dmesg、SELinux、防火墙、权限及strace深入验证。

Linux系统出问题时,别急着重装或重启,大部分故障能通过分层排查快速定位。关键不是“看啥命令”,而是“按什么顺序看”。
先看系统资源是否被耗尽
很多看似奇怪的行为(如命令卡住、SSH连不上、服务响应慢)其实只是内存或CPU被占满。优先确认基础资源水位,避免在错误方向上浪费时间。
-
top或htop看实时 CPU 和内存占用,注意%CPU和RES列;htop更直观,但需手动安装 -
free -h检查available是否接近 0;若available极低但cached很高,可能是内核缓存未及时回收,不一定是真实内存不足 -
df -h查磁盘空间,重点看/、/var、/tmp—— 日志打爆/var是高频原因 -
iostat -x 1(需sysstat包)看%util和await,持续 >90% 或await>100ms 表明 I/O 瓶颈
再查关键进程和依赖服务状态
服务不可用,往往不是它自己崩了,而是上游依赖挂了,比如数据库连不上导致 Web 服务报 502,或者 systemd 里某个单元 failed 导致连锁失败。
-
systemctl list-units --state=failed直接列出所有失败单元,比翻日志快得多 -
systemctl status看该服务的最新日志、启动状态、依赖关系(service-nameLoaded:行会显示 unit 文件路径,可确认是否被覆盖或修改) -
journalctl -u查最近 50 行日志;加service-name-n 50 --no-pager-b可限定当前 boot,避免翻到上次关机前的旧记录 - 对网络服务,用
ss -tulnp | grep确认端口是否真被监听,且是预期进程在监听(portss比netstat更轻量、更准)
日志里找线索:别从头翻,要带条件过滤
直接 tail -f /var/log/messages 容易漏掉关键上下文,也容易被滚动日志冲走。得用时间、关键词、优先级三重锚定。
-
journalctl --since "2024-06-15 14:30:00" --until "2024-06-15 14:35:00"锁定故障发生窗口 -
journalctl -p err..alert只看错误及以上级别;-p warning可补看预警信息 -
dmesg -T | grep -i "oom\|kill\|fail\|error"查内核级事件,OOM killer 日志就在这里,Out of memory: Kill process后面跟着的就是被干掉的进程 - 应用日志路径不统一?先查
systemctl show -p FragmentPath看 unit 文件在哪,里面常有service-nameStandardOutput或LogPath提示
网络与权限类问题的快速验证点
网络不通、拒绝连接、Permission denied 这类报错,表面看是配置问题,实际常因 SELinux、防火墙策略或文件权限链断裂引发。
-
getenforce看 SELinux 是否启用;若为Enforcing,临时setenforce 0测试是否恢复——若恢复,说明是 SELinux 策略限制,而非配置本身错 -
firewall-cmd --list-all(firewalld)或iptables -L -n -v(iptables)确认端口是否放行;注意publiczone 默认可能没开你用的端口 - 权限问题先跑
ls -lZ(含 SELinux 上下文)和ls -ld(父目录权限),常见坑:Web 服务进程用户无法 traverse 上级目录(即缺少执行 x 权限) -
strace -p实时抓进程在打开哪些文件、连哪个地址——比猜配置文件路径高效得多pid-e trace=openat,connect,bind
journalctl -u nginx --since "2024-06-15 10:00:00" -p err | grep -E "(connect|permission|denied|failed)"
真正难的不是命令记不住,而是看到一条报错后,不知道该往系统哪一层挖:是硬件层(磁盘坏块)、内核层(OOM、模块异常)、运行时层(cgroup 限流、OOMScoreAdj 设置)、还是应用层(配置错、代码 bug)。每次排查,都得默念一遍这个层级链。










