简介：这份PDF资料聚焦Linux/Unix服务器运维中的典型故障排查与修复，面向有一定基础的运维工程师、系统管理员及备考相关认证的技术人员。内容以真实案例为主线，涵盖RAID1数据分区挂载异常、依赖库丢失导致root无法登录、GRUB分区误删后的双系统引导修复、硬盘移除引发紧急模式，以及FreeBSD jail虚拟机/usr目录被写满等场景，并延伸出fstab配置、fsck检查、单用户模式、网络引导与MBR修复等实用排错思路。资源包共1个PDF文件，约367KB，轻量便携，适合随时查阅与复盘。目前已有92人学习，虽体量不大，但案例典型、步骤具体，能帮助读者理解故障成因、掌握应急恢复流程，并积累日常巡检与高可用模拟实验的注意事项，提升线上环境的排障信心与操作谨慎度。
1. 从一台"还能 ping 通"的 Linux 服务器说起：故障篇到底在讲什么
凌晨两点,监控告警响了,一台跑着业务的 Linux 服务器 SSH 连不上,但ping内网地址居然还通。这种"半死不活"的状态,比直接宕机更让人抓狂——因为ping显示一般故障,不代表系统健康,只代表 ICMP 那一层还活着。所谓"明明白白你的 Linux 服务器",核心不是背命令,而是建立一套从硬件、内核、网络到应用层的分层排查思路,让每一次故障都有迹可循,而不是靠重启碰运气。
这篇内容面向的是每天和服务器打交道的运维、后端和嵌入式 Linux 工程师。它解决的不是"Linux 怎么装"这种入门问题,而是当服务器出现硬盘掉盘、阵列卡告警、进程假死、网络时通时断、系统盘符对不上这些真实故障时,你该怎么一步步定位。下面按"先分层理解 → 再动手排查 → 最后避坑"的顺序展开,每一层都给出可复现的命令和判断依据,新手能照着敲,熟手能对照边界参数。
2. 故障分层模型：为什么你的第一反应总是错的
2.1 从硬件到应用的五层排查顺序
很多人一遇到服务器故障,第一反应是reboot,这是最省事也最危险的做法。重启会清掉内存里的现场,日志可能还没落盘,阵列卡缓存里的报错也可能被覆盖。正确的顺序是从下往上:硬件层(电源、内存、磁盘、阵列卡)、内核层(dmesg、内核 panic、驱动)、系统层(文件系统、挂载、进程)、网络层(网卡、路由、防火墙)、应用层(服务进程、端口、配置)。
这个顺序的道理很简单:上层故障往往是下层问题的表现。比如应用连不上数据库,可能是网络层 iptables 拦了,也可能是系统层磁盘满了导致数据库写不进去,还可能是硬件层某块盘掉了触发 RAID 降级。如果你直接从应用层查,很容易在错误的方向上耗掉半小时。
判断当前卡在哪一层,最快的入口是dmesg -T。它带时间戳输出内核环形缓冲区,硬件报错、驱动加载失败、磁盘 I/O 错误、OOM killer 触发都会在这里留痕。我一般排查任何服务器故障,第一条命令就是它。
# -T 把内核时间戳转成可读时间, -l 按级别过滤 err/warn dmesg -T --level=err,warn | tail -50 # 关注关键词: I/O error, medium error, RAID, megaraid, mpt3sas, OOM, call trace逻辑说明:内核日志是硬件和驱动问题的"黑匣子",优先级高于任何应用日志。参数上--level=err,warn能过滤掉大量 info 噪音,tail -50先看最近的。如果这里出现I/O error或medium error,基本可以锁定磁盘或链路问题,不用再往上查应用。
2.2 阵列卡与硬盘:盘符对不上时怎么定位
热搜里频繁出现lsi-9361-8i阵列卡和"怎么定位在系统下的盘符",这是硬件层最典型的痛点。RAID 卡把物理盘抽象成逻辑卷,操作系统看到的是/dev/sdb这种逻辑盘,而物理槽位号(Slot)和系统盘符之间没有直接对应关系。当阵列卡报某块物理盘 pre-fail(预故障)时,你得先知道它是哪个槽,再确认它对应系统里哪个设备。
常见做法是先用厂商工具查物理盘状态,再用lsblk和smartctl交叉验证。以 LSI/Broadcom 的 storcli 为例:
# 查看所有物理盘状态, EID:Slt 是机箱号和槽位号 storcli /c0/eall/sall show # 输出里 State 列出现 UGood(正常) / UBad(故障) / Rbld(重建中) # 查看某块盘的详细错误计数 storcli /c0/e252/s3 show all | grep -i error逻辑说明:/c0是控制器 0,eall/sall表示所有机箱所有槽位。拿到槽位号后,再对照系统盘符:
# 列出块设备及序列号, 用序列号跟阵列卡里的 WWN 对齐 lsblk -o NAME,SIZE,SERIAL,TYPE,MOUNTPOINT # 直接读某块盘的 SMART 健康信息 smartctl -a -d megaraid,3 /dev/sda参数说明:-d megaraid,3里的3是阵列卡给这块物理盘的 Device ID,不是系统盘符,必须先用 storcli 查到。这一步是很多人翻车的地方——直接对/dev/sdb跑 smartctl,读到的是逻辑卷的健康状态,不是那块预故障物理盘的。硬盘做 RAID0 时尤其要注意,RAID0 没有冗余,任何一块盘 pre-fail 都意味着数据随时可能全丢,发现预故障必须第一时间备份而不是等它彻底坏。
3. 系统层与网络层:那些"看起来正常"的假象
3.1 进程假死与 D 状态:为什么 kill -9 也杀不掉
系统层最容易被误判的是进程状态。一个进程ps看还在,但服务不响应,kill -9也杀不掉,这通常是 D 状态(不可中断睡眠)。D 状态意味着进程卡在内核的系统调用里,多半是在等 I/O——磁盘、NFS、或者挂载的 NAS 存储。热搜里"linux 挂载 nas 存储"相关的故障,十有八九是 NFS 服务端无响应,导致客户端进程全部卡在 D 状态。
# 找出所有 D 状态进程 ps -eo pid,stat,wchan:20,cmd | awk '$2 ~ /D/' # 查看进程卡在哪个内核函数 cat /proc/<PID>/stack # 查看 NFS 挂载状态, 是否有 hard 挂载导致无法中断 mount | grep nfs逻辑说明:wchan列显示进程正在等待的内核函数,/proc/<PID>/stack能看到更精确的调用栈。如果发现大量进程卡在nfs_开头的函数上,基本可以确认是 NFS 问题。参数上,hard挂载的 NFS 在服务端失联时会无限重试,进程无法被 kill,这是设计行为不是 bug。解决办法是改用soft挂载加timeo超时,或者先恢复 NFS 服务端。
提示:生产环境挂载 NFS 建议用
soft,timeo=100,retrans=3,避免服务端抖动导致客户端大面积 D 状态。但soft在写入时可能返回错误,数据库类场景要谨慎评估。
3.2 ping 通但服务不通:网络层排查的四个检查点
ping显示一般故障、ping内网通但 SSH 连不上,这类问题在网络层。ICMP 通只说明 IP 层可达,不代表 TCP 端口开放。排查顺序是:网卡链路状态 → IP 和路由 → 防火墙规则 → 目标端口监听。
# 1. 网卡物理链路和错误计数 ip -s link show eth0 # 2. 路由表, 确认默认网关和到目标网段的路由 ip route get 10.10.8.149 # 3. 防火墙规则, 注意 iptables 和 firewalld 可能同时存在 iptables -L -n -v --line-numbers # 4. 目标端口是否监听 ss -tlnp | grep :22逻辑说明:ip -s link的 RX/TX errors 和 dropped 计数能看出物理层是否有丢包。ip route get直接告诉你到目标地址会走哪个网卡和网关,比看整张路由表快。防火墙这块,iptables -L -n -v的-v会显示每条规则的匹配包数,如果某条 DROP 规则计数在涨,就是它拦的。ss -tlnp确认服务本身有没有监听端口,如果没监听,问题就不在防火墙而在服务本身。
热搜里"windows2016 服务器入站出站策略开放指定端口"和"ping 出现一般故障"经常一起出现,本质是同一类问题:网络策略把 ICMP 或目标端口拦了。Linux 侧对应的是 iptables/firewalld,Windows 侧是高级防火墙,排查思路一致——先确认链路,再确认策略。
4. 避坑与常见问题:那些年我踩过的排查陷阱
4.1 现象:重启后阵列卡报错消失,以为修好了
原因:重启清空了阵列卡的事件日志和内核环形缓冲区,预故障的物理盘可能暂时恢复响应,但 SMART 里的重映射扇区计数和 pending sector 不会因为重启归零。这是典型的"后悔药没得吃"——等它再次报错时,可能已经从 pre-fail 变成 failed。
解决:任何硬件告警,重启前先storcli /c0/eall/sall show all > /tmp/raid_before_reboot.log,把现场存下来。重启后对比 SMART 属性,重点看Reallocated_Sector_Ct、Current_Pending_Sector、Offline_Uncorrectable三个值,只要有一个在涨,盘就该换。
4.2 现象:df 显示磁盘没满,但服务报"no space left on device"
原因:inode 耗尽,或者有进程持有已删除文件的句柄。df -h看的是块使用率,df -i才看 inode。大量小文件(比如 session 文件、日志碎片)会把 inode 用光,块还有空间但无法创建新文件。另一种情况是rm删了大文件,但进程还开着句柄,空间不释放。
解决:先df -i确认 inode,再lsof | grep deleted找持有已删除文件的进程,重启该进程或> /proc/<PID>/fd/<FD>清空句柄。
4.3 现象:ping 内网通,但 SSH 连接超时,防火墙规则看着是空的
原因:firewalld 和 iptables 可能同时运行,iptables -L看到的是 iptables 自己的链,而 firewalld 用的是 nftables 后端,规则不在 iptables 里显示。或者 SELinux 拦了端口绑定。
解决:firewall-cmd --list-all看 firewalld 规则,nft list ruleset看 nftables,getenforce确认 SELinux 状态。三个都查一遍再下结论。
4.4 现象:RAID0 一块盘 pre-fail,想热插拔换盘
原因:RAID0 没有冗余,拔掉任何一块盘,整个逻辑卷立即失效,数据全丢。热插拔只对 RAID1/5/6/10 这类有冗余的阵列有意义。
解决:RAID0 遇到预故障,唯一正确操作是立即停机备份数据,然后整体重建。不要幻想在线换盘,RAID0 没有重建这回事。
4.5 现象:系统盘符从 /dev/sda 变成 /dev/sdb,启动失败
原因:服务器加了新硬盘或改了阵列卡配置,内核枚举顺序变了。用/dev/sdX写死在 fstab 或启动参数里,顺序一变就挂。
解决:改用 UUID 或 LABEL 挂载。blkid查 UUID,/etc/fstab里用UUID=xxxx替代设备名。启动参数里的 root 设备同理,用root=UUID=xxxx。
5. 把排查变成习惯:一套可复用的故障快照脚本
排查能力最终要沉淀成流程,而不是每次靠记忆。我一般会在每台服务器上放一个故障快照脚本,出问题时先跑一遍,把现场固化下来,再慢慢分析。这样即使后面重启了,证据还在。
#!/bin/bash # fault_snapshot.sh - 一键收集 Linux 服务器故障现场 SNAP_DIR="/var/log/fault_$(date +%Y%m%d_%H%M%S)" mkdir -p "$SNAP_DIR" # 硬件与内核层 dmesg -T > "$SNAP_DIR/dmesg.log" 2>&1 smartctl -a /dev/sda > "$SNAP_DIR/smart_sda.log" 2>&1 storcli /c0/eall/sall show all > "$SNAP_DIR/raid.log" 2>&1 # 系统层 ps -eo pid,ppid,stat,wchan:20,cmd > "$SNAP_DIR/ps.log" 2>&1 df -h > "$SNAP_DIR/df.log" 2>&1 df -i > "$SNAP_DIR/df_inode.log" 2>&1 free -m > "$SNAP_DIR/mem.log" 2>&1 cat /proc/loadavg > "$SNAP_DIR/loadavg.log" 2>&1 # 网络层 ip -s link > "$SNAP_DIR/iplink.log" 2>&1 ip route > "$SNAP_DIR/route.log" 2>&1 ss -tlnp > "$SNAP_DIR/ss.log" 2>&1 iptables -L -n -v > "$SNAP_DIR/iptables.log" 2>&1 firewall-cmd --list-all > "$SNAP_DIR/firewalld.log" 2>&1 # 打包 tar czf "$SNAP_DIR.tar.gz" -C "$(dirname $SNAP_DIR)" "$(basename $SNAP_DIR)" echo "快照已保存: $SNAP_DIR.tar.gz"逻辑说明:脚本按硬件、系统、网络三层分组收集,每类输出到独立文件,方便后续 grep。dmesg -T带时间戳,smartctl -a拿完整 SMART 属性,storcli show all拿阵列卡完整状态。ps里的wchan是排查 D 状态的关键列。最后打包成一个 tar.gz,方便传到分析机。
参数上要注意:smartctl对阵列卡后面的物理盘需要-d megaraid,N,脚本里对/dev/sda直接跑只能拿到逻辑卷信息,实际使用时要把 N 替换成 storcli 查到的 Device ID。storcli路径可能因版本不同在/opt/MegaRAID/storcli/下,脚本里最好用command -v storcli先判断存在性。
这套脚本的价值不在于命令多高级,而在于它强制你把"先取证再动手"变成肌肉记忆。我见过太多人一上来就重启,结果问题复现不了,只能等下次再炸。养成先跑快照的习惯后,你会发现大部分故障其实在 dmesg 和 SMART 里早就写了答案,只是之前没人去看。
最后说个我自己的教训:早年有台服务器反复掉盘,我每次都换盘了事,直到第三次才想起来对比三次的 SMART 日志,发现是背板供电不稳导致多块盘同时报错,换盘根本没用。从那以后,任何重复故障,我第一件事就是翻历史快照找规律,而不是急着换硬件。希望帮到你。
本文还有配套的精品资源，点击获取
