简介面向Linux/Unix系统运维人员这份PDF资源聚焦服务器日常运行中高频出现的故障场景以故障现象、排查过程、解决命令为主线帮助读者建立从定位问题到恢复服务的完整思路。内容包含RAID1数据分区挂载异常、依赖库缺失导致root无法登录、误删GRUB分区、移除硬盘后系统进入紧急模式、FreeBSD jail的/usr被占满五个真实案例并附有作者多年运维总结的注意事项涵盖文件系统检查、磁盘修复、引导恢复与存储空间清理等典型处置方法。压缩包为单个PDF文件大小367KB内容紧凑便于随时查阅。已有92人学习下载适合有一定Linux基础、希望提升故障排查能力的运维人员参考。1. Linux 服务器故障排查一份来自一线的排障笔记做运维这几年服务器故障见得多了最深的感触是真正危险的不是故障本身而是处理故障时的手忙脚乱。这篇关于 Linux 服务器故障的笔记值得仔细拆解因为里面的“故障一”几乎是每个运维都会遇到的场景——挂载 RAID 分区后文件全部异常那一瞬间冷汗就下来了。这份笔记恰恰记录了这类问题的正确处理顺序而且非常贴近实际生产环境。从 CentOS 到 FreeBSD从 GRUB 修复到 Emergency 模式覆盖的场景足够典型正适合刚接触服务器运维、或者正在学习 Linux 故障排查的从业者。不过要注意这份笔记成文较早部分系统版本已经过时但其中的排查思路和命令在今天的 Linux 系统上仍然通用。我在复现过程中会补充近年来的一些变化帮你识别哪些操作需要调整。2. RAID 数据分区挂载异常fstab 与 fsck 的正确使用顺序2.1 为什么挂载后文件会“全部出错”先看原文描述的故障现象一台 64 位 CentOS 5.5 服务器四块硬盘做了两个 RAID1一个给 OS一个是数据盘。系统重装后直接执行mount /dev/mapper/ddf1_datap1 /data挂载数据盘挂载很顺利但用ll一看文件全部异常。这里的关键问题为什么挂载成功了文件却是错的常见做法是文件系统没被正确识别时系统可能以错误的参数挂载了分区。CentOS 5.5 时代DDFDisk Data Format阵列的 device mapper 条目和普通分区不同如果分区表信息不完整或者阵列元数据还没有被正确激活直接挂载可能把文件系统当成未初始化或损坏的状态。另一个容易忽略的原因系统重装后数据盘虽然没动过但 RAID 驱动或者 device mapper 的设备节点发生了变话。挂载动作本身“成功”了但底层文件系统层看到的设备内容和实际数据不一致表现出来就是文件全部异常。原文作者的处理方式是把挂载条目写进/etc/fstab重启后一切正常。这个操作的本质是让系统在启动过程中按正确的顺序加载 RAID 驱动、激活阵列、再挂载文件系统。手动mount时如果阵列还没完全激活或者内核还没识别到完整的 RAID 元数据就会出现“挂载成功但数据不对”的情况。2.2 defaults 选项的含义与影响原文里专门提到“大家别小看 defaults 选项这个默认会作许多事情的”。在/etc/fstab中defaults实际上展开为多个挂载选项/dev/mapper/ddf1_datap1 /data ext3 defaults 0 0defaults实际包含rw, suid, dev, exec, auto, nouser, async这组选项。rw表示读写挂载auto表示允许mount -a时自动挂载async表示所有文件系统操作采用异步方式。大多数情况下defaults是安全的选择。但需要注意它不包含noatime这意味着每次访问文件都会更新访问时间对高 IO 负载的数据库服务器会产生额外的写入开销。生产环境中MySQL 数据盘常见的挂载选项是defaults,noatime,nodiratime或者加上barrier1ext4 文件系统。原文这个案例值得注意的另一点作者写的是 ext3 文件系统。现代 Linux 系统大多已经切换到 ext4 或 xfs但挂载逻辑和排障思路是一样的。2.3 安全的复现操作顺序fsck 优先挂载在后原文最后写了一句“最后是将所有的数据备份后再仔细的 fsck 一遍确认无误再进行挂载”。这句话的顺序非常关键但实际操作中应该调整一下顺序——先检查再挂载而不是先挂载再检查。我在处理类似情况时会这样做# 1. 先检查 RAID 阵列状态确认设备节点存在 cat /proc/mdstat ls -l /dev/mapper/ | grep ddf1 # 2. 检查文件系统完整性-f 强制检查-y 自动修复 fsck -f -y /dev/mapper/ddf1_datap1 # 3. 以只读方式挂载先用 dmesg 确认内核日志无异常 mount -o ro /dev/mapper/ddf1_datap1 /mnt/data_check # 4. 只读挂载检查确认没问题后再读写挂载 umount /mnt/data_check mount /dev/mapper/ddf1_datap1 /data # 5. 查看挂载状态和系统日志 df -h /data dmesg | tail -n 30逻辑说明第 1 步确认 RAID 设备在系统中被正确识别避免对不存在的设备执行耗时操作第 2 步fsck必须在挂载前执行否则文件系统已经被内核使用fsck会拒绝操作或产生不正确的结果第 3 步先只读挂载是为了给数据多一层保护确认文件列表正常后再正式使用。参数说明-f是强制检查即使文件系统标记为 clean 也会执行完整扫描-y是遇到问题时自动回答 yes适合无人值守的检查场景。生产环境建议先不加-y手动跑一遍看清楚有哪些问题再决定是否自动修复。这条处理链路我已经在线上环境执行过多次尤其是系统重装后第一次挂载数据盘之前。不要嫌 fsck 耗时长——一块几 TB 的盘全盘检查可能需要好几个小时但比起数据丢失这点时间成本非常值得。2.4 fstab 写错导致开不了机常见误用/etc/fstab的坑远不止挂载选项本身。最常见的翻车现场是字段数写错导致无法开机。fstab 每行有 6 个字段字段含义注意事项设备可以是 /dev/xxx 或 UUID推荐用 UUID设备名可能变化挂载点系统目录路径不能有空格和特殊字符文件系统类型ext4、xfs、swap 等要与实际格式一致挂载选项defaults 或其他注意 sync/async、noatime 等dump是否备份0 或 1通常写 0passfsck 检查顺序根分区写 1其他写 2不需要检查写 0最容易出错的是最后一个字段。如果一张数据盘写成0 1系统启动时会对它执行 fsck碰到大容量盘中途卡住是常有的事。数据盘应该写0 0表示不参与启动时的 fsck 检查。还有一类常见问题用/dev/sdb1这种设备路径写 fstab但服务器加了一块新硬盘后设备名漂移比如 sdb 变成了 sdc系统启动时找不到对应设备就进 emergency mode。正确的做法是用blkid查 UUID然后写入 fstab# 查看分区的 UUID blkid /dev/sdb1 # 用 UUID 写 fstab echo UUID$(blkid -s UUID -o value /dev/sdb1) /data ext4 defaults 0 0 /etc/fstab这样一来即使设备名变了系统仍然能通过 UUID 精确定位到分区。我之前就见过一个同事因为设备名漂移导致生产服务器启动后进不了系统恢复方法是单用户模式下改 fstab但如果最初就用 UUID根本不会有这个问题。2.5 避坑记录现象一用mount挂载数据盘后ll看到文件全变成异常状态原因RAID 设备或 device mapper 条目还没完全激活文件系统层读到了不一致的数据。也可能文件系统本身存在损坏需要检查。解决先确认 RAID 阵列状态cat /proc/mdstat再对分区执行fsck最后写进 fstab 重启。严禁在文件系统异常时直接往上面写数据。现象二修改 fstab 后重启系统卡在维护模式原因fstab 中某一行语法错误或者挂载点不存在、设备路径不对。系统无法完成挂载就进入了 emergency mode。解决在维护模式下执行mount -o remount,rw /让根文件系统可写然后编辑 fstab 修正错误行。改完执行mount -a验证语法是否正确再重启。现象三分区表没问题但 /data 挂载后是空的原因挂载点本身是空目录时如果设备里没有数据挂了也是空的。另一种情况是之前有过数据但挂载到了别的目录或者文件系统被误格式化。解决用mount和df -h确认挂载状态用lsblk -f查看分区上的文件系统类型。如果分区上原本是 xfs 而挂载成 ext4就会出现设备被识别但内容异常的情况。3. root 无法登录libintl 丢失与单用户模式修复3.1 bash 依赖库文件丢失的症状原文第二个故障涉及 FreeBSD 的 jail 母机root 的 shell 是 bash而 bash 依赖的库文件libintl.so.8丢失直接导致 root 无法登录。具体报错信息是这样的/libexec/ld-elf.so.1: Shared object libintl.so.8 not found, required by bash Connection to 192.168.21.36 closed.这个案例的典型意义在于动态链接库丢失导致登录 shell 无法启动用户连系统都进不了。这类问题在 Linux 上同样存在比如libc.so.6被误删或覆盖几乎所有命令都无法执行局面比 FreeBSD 这个案例更严峻。修复的逻辑是相通的不能依赖正常登录必须走单用户模式或救援模式进入系统后先修复依赖再切换回正常的 shell。对于这类问题我建议先确认几个信息库文件是彻底被删了还是被替换成了不兼容的版本ldd /bin/bash能列出 bash 依赖的动态库清单如果libintl.so.8显示 not found那就需要找到正确的库文件恢复。如果以前备份过直接拷回去就行如果没有备份可以从同版本的系统包中提取。3.2 单用户模式下的修复步骤原文已经给出了一套可复现的流程我做了一些补充和调整。以 Linux 系统为例# 1. 在启动菜单选择内核时按 e进入编辑模式 # 2. 在 kernel 那一行末尾加上 single 或 1按 b 启动进入单用户模式 # 3. 进入单用户模式后先检查根文件系统 fsck -y # 4. 重新挂载所有文件系统 mount -a # 5. 查看 bash 的库依赖情况 ldd /bin/bash | grep libintl # 6. 如果缺失先从 rpm 包中提取或从其他机器拷贝 # 以 CentOS 为例用 rpm 验证 bash 包完整性 rpm -V bash # 7. 临时把 root 的 shell 切换为 /bin/sh chsh -s /bin/sh root # 8. 重启验证 reboot逻辑说明单用户模式只挂载根文件系统且默认是只读的所以第 4 步的mount -a在实际操作中通常配合mount -o remount,rw /使用把根文件系统改为可写才能执行后面的chsh和文件修复。fsck -y的安全意义在于单用户模式下文件系统没有被大量占用检查和修复的干扰最小。参数说明chsh -s /bin/sh root把 root 的登录 shell 改为 sh修改即时生效。如果之后想换回 bash得先在系统里修复好 bash 的依赖库否则又会出现登录不了的问题。FreeBSD 下对应的命令是chsh -s /bin/sh root语法类似。3.3 不是只有 bash 才会翻车这类“登录 shell 挂了导致进不了系统”的故障在真实环境中出现过很多变种变种一.bash_profile或.profile中有死循环或错误的命令登录时卡住看起来像是系统假死实则是脚本执行异常。解决方法是通过单用户模式进入系统把这两个文件改名备份# 在单用户模式下挂载根文件系统为可读写 mount -o remount,rw / # 备份出问题的用户配置文件 mv /root/.bash_profile /root/.bash_profile.bak mv /root/.bashrc /root/.bashrc.bak之后重启登录恢复正常再排查脚本中的具体问题。变种二系统提示libc.so.6版本不对连 ls、cat 都执行不了这种情况比缺失某个库文件更棘手因为几乎所有动态链接的命令都不可用。修复办法是通过救援模式启动或者使用系统安装盘的 chroot 环境# 在救援模式下挂载原系统的根分区 mount /dev/sda1 /mnt/sysimage chroot /mnt/sysimage # 在 chroot 环境下修复 libc rpm -e --nodeps glibc rpm -ivh glibc-xxx.rpm注意rpm -e --nodeps这种操作极其危险只适合已经无法正常启动的系统。实际操作中更稳妥的方式是直接用安装光盘的linux rescue模式让系统自动识别并修复。3.4 避坑记录现象一单用户模式登录后提示 root 密码错误原因单用户模式下某些系统变体仍然要求输入 root 密码或者/etc/shadow文件损坏。解决如果是 CentOS 7/RHEL7 以上单用户模式默认还是需要密码的要在启动时加上single rd.break配合chroot /sysroot操作。具体做法是修改启动参数为rd.break系统会停在 initramfs 阶段然后mount -o remount,rw /sysroot chroot /sysroot passwd root touch /.autorelabel exit reboot现象二chsh 修改 shell 后root 登录仍然失败原因bash 依赖的库文件虽然恢复了但可能存在符号链接指向错误路径例如libintl.so.8实际文件名是libintl.so.8.1缺少软链。解决手动创建正确的软链ln -sf /usr/lib/libintl.so.8.1 /usr/lib/libintl.so.8 ldconfig现象三fsck 执行到一半卡住不动敲什么都没反应原因fsck -y在修复大量错误时确实会耗时较长看起来像卡死。但如果超过几十分钟没有磁盘 IO 变化可能是文件系统损坏严重。解决先确认当前分区是否是根分区——如果执行fsck时根分区处于挂载状态会有严重的风险。正确做法是使用fsck -f前先确认该分区未被挂载。如果确实卡住重启进入单用户模式后用fsck -y配合timeout限制时间或者先备份分区镜像再尝试修复。4. GRUB 分区误删双系统引导修复的完整链路4.1 误删 GRUB 分区后的实际困境原文第三个故障是工作机上误删了 GRUB 所在的分区/dev/hdb8装的是 Windows 2003 和 CentOS 5.3 双系统结果 Windows 也进不去了。这台机器没有光驱和软驱U 盘启动也不支持最后靠网络引导和 MBR 修复工具解决了问题。这类问题在今天的运维环境中不算高频但一旦发生就非常紧急因为双系统的机器往往是个人开发机或测试机数据可能没有及时备份。误删 GRUB 分区后系统的行为是BIOS 从硬盘启动读取 MBRMBR 里指向 GRUB 引导代码的扇区已经不存在了屏幕显示grub提示符或者GRUB loading, please wait... Error 22之类的错误。需要明确的一点误删 GRUB 所在分区不等于删了系统所在分区。如果只是删除了/dev/hdb8这个引导分区Windows 的 C 盘数据和 Linux 的 / 分区数据未必受到影响只要修复 MBR 和 GRUB 配置就能恢复启动。但如果连引导扇区都被覆盖情况会更麻烦。4.2 保留现场优先进入 grub 交互模式手动引导修复的过程通常有两种路线一是用引导盘进入 DOS 或 PE 环境用工具修复 MBR二是直接在 GRUB 提示符下手动指定启动参数。原文给出的第二种办法非常实用我把它整理成更清晰的流程。当 GRUB 因为找不到配置文件而落到grub交互提示符时可以手动输入命令引导 Windows# 在 grub 提示符下把第一块硬盘的第一个分区设置为根设备不加载文件系统 rootnoverify (hd0,0) # 把引导权转交给当前分区首扇区 chainloader 1 # 执行启动 boot各参数含义(hd0,0)表示第一块物理硬盘的第一个分区rootnoverify的作用是告诉 GRUB “这个分区是根设备”但不实际挂载文件系统也不检查文件系统类型这样做的原因是我们无法预知 Windows 分区是否有 GRUB 支持的文件系统chainloader 1把控制权交给分区首扇区上的引导代码boot正式启动。如果进 Linux 系统后发现 GRUB 文件确实损坏了可以在 Linux 系统内重新安装 GRUB 到 MBR# CentOS 5/6 系列使用 grub-install grub-install /dev/sda # 重新生成配置文件 grub-mkconfig -o /boot/grub/grub.conf对于 CentOS 7 及以上版本GRUB2 的用法不同# 重新安装 GRUB2 引导程序 grub2-install /dev/sda # 重新生成配置文件 grub2-mkconfig -o /boot/grub2/grub.cfg注意grub-install和grub2-install是针对系统当前使用的引导方式的。安装时如果出现No Cursor或/dev/sda相关的错误可能是 BIOS 引导模式和 UEFI 引导模式的差异需要先确认系统是用哪种模式启动的。4.3 网络引导与 MBR 修复工具的组合操作原作者的机器不支持 U 盘引导他选择了网络引导方案用 MaxDOS_71PXE_G115.exe 做网络 Ghost 引导进入 DOS 环境后用 diskgen 或 spfdisk 修复 MBR。这段操作看似简单实际上有几个关键节点需要注意。网络引导成功后会出现一个 DOS 启动菜单里面通常包含 Ghost 和分区工具。如果在 Ghost 克隆结束后选择了“立即重启”会回到原来的 GRUB 错误状态因为 Ghost 没有修复 MBR 引导代码。正确顺序应该是网络引导 → 进入 DOS → 用 diskgen/spfdisk 修复 MBR → 验证分区表 → 重启。原文提到还可以用fdisk /mbr这是 DOS 时代遗留的工具作用是把标准 MBR 引导代码写回硬盘首扇区。这个操作对 Windows 分区有效但如果原来是用 GRUB 引导 Linuxfdisk /mbr会让 Linux 无法从 MBR 启动需要重新安装 GRUB 才能恢复。实际上在 Linux 系统内修复 MBR 有一个更常见的做法原文没有提到直接用 dd 备份和恢复 MBR。比如在重装系统之前把 MBR 备份出来# 备份第一个扇区 dd if/dev/sda of/root/mbr_backup bs512 count1 # 恢复 MBR dd if/root/mbr_backup of/dev/sda bs512 count1这条命令只操作 MBR 扇区不影响分区表之外的数据。但要注意如果分区表本身也变了直接恢复旧的 MBR 可能会把分区表覆盖成旧状态导致数据分区不识别。所以在恢复 MBR 前务必确认分区表是否和备份时一致。4.4 避坑记录现象一GRUB 修复后Windows 能启动但 Linux 进不了原因GRUB 配置中 Linux 的 root 设备指向了旧的分区号修复 GRUB 后分区编号发生了变化。解决重新进入 grub 提示符执行root (hd0,X)和setup (hd0)重建引导其中 X 是 Linux /boot 所在的实际分区号。也可以启动后修改/boot/grub/grub.conf或/boot/grub2/grub.cfg中的 root 参数。现象二fdisk /mbr 和 spfdisk 修复完成后重启屏幕提示无效分区表原因MBR 修复工具把引导代码写进去了但分区表本身已经损坏或者修复工具在写入时误改了分区表。解决不要反复执行fdisk /mbr这会覆盖更多扇区。用 testdisk 扫描分区表并尝试恢复恢复完成后重新安装 GRUB。现象三网络引导后找不到 Ghost 工具或 DOS 启动盘原因网络引导环境没有正确映射到包含 Ghost 的镜像或者网卡驱动不被 PXE 引导环境支持。解决将 MaxDOS 的镜像文件放到 TFTP 服务器的正确目录下然后检查 PXE 配置中引导文件名和 DHCP 下一个服务器地址是否正确。老机器网卡驱动的兼容性问题可能需要换用 Linux 下的systemrescuecd或类似工具做 PXE 引导。5. 移除硬盘后系统进入 Emergency 模式fstab 与硬件变更的关联5.1 Emergency 模式的触发机制原文第四个故障非常有代表性同事移走一块硬盘后直接启动 RHEL5系统进入 Emergency 模式。原因很清楚——/etc/fstab里还记录着那块被移除硬盘的挂载信息启动时系统尝试挂载不存在的设备就报错。Linux 在启动过程中会根据 fstab 逐条挂载文件系统。如果某个设备条目失败了系统不会忽略它而是直接进入 Emergency 模式等待人工干预。这是设计上的安全策略如果自动跳过挂载失败的设备可能导致数据分区未被正确挂载系统照常启动后面无数服务都会出问题数据写入错误时才意识到情况严重那时已经晚了。Emergency 模式的行为特征是系统启动后呈现的是一个极简的 shell 环境根文件系统被挂载为只读。在这里可以执行有限的管理命令但要修改 fstab 必须先把根分区重新挂载为可写。5.2 紧急模式下的可写重挂载与 fstab 修正原文描述的重点操作是mount -o remount,rw /。下面把完整流程展开# 1. 在 Emergency 模式下输入 root 密码后进入 shell # 2. 查看当前挂载状态确认根分区只读 mount | grep / # 3. 重新挂载根分区为可读写 mount -o remount,rw / # 4. 打开 fstab确认哪些条目涉及已移除的硬盘 cat /etc/fstab # 5. 把对应条目注释掉或删除 # 例如原始条目是 /dev/sdb1 /backup ext4 defaults 0 0 # 改为以下内容 # /dev/sdb1 /backup ext4 defaults 0 0 # 6. 执行挂载验证确认没有报错 mount -a # 7. 重启 reboot逻辑说明第 2 步确认根分区是否处于只读状态避免直接mount -o remount,rw去覆盖已经可写的文件系统第 4 步列出全部条目找到被移除硬盘对应的那一条第 5 步注释掉之后第 6 步的mount -a能检查 fstab 是否存在语法问题。ipad 再重启系统就能正常进入到多用户模式。参数说明mount -o remount,rw /中的remount表示重新挂载已挂载的文件系统rw切换为读写模式。这条命令在救援和排障场景中使用频率非常高操作本身不改变文件系统内容只是修改挂载标志相对安全。5.3 为什么说“移走硬盘不更新 fstab”是灾难级操作这篇文章里的故障在真实运维中几乎每周都能遇到。很多人觉得改 BIOS 设置、加硬盘、拔硬盘都是硬件操作不需要通知运维。但是拔硬盘之前得先搞清楚这块盘在系统里扮演什么角色。场景风险正确处理数据盘整盘移除fstab 还有挂载条目系统启动进 Emergency 模式先注释 fstab 条目再做物理移除拔掉 RAID 成员盘之一视 RAID 级别可能出现数据丢失或降级先确认阵列状态确认可安全离线更换硬盘后设备名变化fstab 的 UUID/设备名可能失效用 blkid 获取新设备 UUID更新 fstab如果系统里跑了数据库或应用服务直接在开机状态下拔掉数据盘会导致进程崩溃甚至文件系统损坏绝不是“像 Windows 一样直接移走”就行了的。实际上Windows 也不是完全无感的。Windows 的盘符分配也有自己的规则只是对硬件变更的容错相对宽松。Linux 的设计逻辑不同一切挂载关系都由 fstab 显式定义系统启动时按配置执行任何一个环节出了问题都会明确报错并等待人工处理——这从故障排查的角度反而是好事。5.4 避坑记录现象一在 Emergency 模式下执行 mount -a部分挂载条目依然报错原因根文件系统虽然被重挂载为可写但其他分区比如 /home、/var可能还没有挂载mount -a会按照 fstab 里的顺序逐个尝试。被移除硬盘的条目被注释掉之后应该不会再报错但如果注释的行号不对或者挂载点目录不存在仍然会报错。解决先执行mkdir -p创建缺失的挂载点目录再执行mount -a。检查时用df -h和lsblk验证挂载结果。现象二注释掉 fstab 中的一条之后重启仍然进 emergency mode原因fstab 里可能不止一处引用被移除的硬盘比如 swap 条目、另一个数据分区条目。注释掉一条不够。解决在执行mount -a时系统会从上到下逐条执行遇到第一个报错就停止。用mount -a -v可以看到每一步的输出根据输出定位到具体哪一行有问题然后修正对应条目。现象三用 mount -o remount,rw / 时提示 Device or resource busy原因有进程正在占用根文件系统的文件常见的有日志服务、数据库进程。Emergency 模式下系统服务较少但如果有残留进程重挂载会被拒绝。解决先尝试lsof /或fuser -v /查看哪些进程占用必要时用kill或fuser -k /结束它们。如果实在无法终止可以在重启时通过内核启动参数init/bin/bash进入这样不经过完整的服务启动流程占用进程会少很多。6. 故障定位的思路与方法从磁盘占满到系统巡检6.1 最快定位“大文件写入”的搜索组合原文最后一个技术故障来自 FreeBSD jail 虚拟机某个程序形成死循环持续写某个文件导致 /usr 分区被占满。作者使用的方法是先touch test创建测试文件再执行find / -newer test找出比 test 文件更新的文件。这类“分区突然占满”的故障核心诉求只有一个快速定位可疑文件。Linux 系统下我常用的定位命令和原文的思路一致但可以更精确一些# 1. 确认哪个分区满了 df -h # 2. 查看该分区根目录下每个目录的体积 du -sh /usr/* | sort -rh | head -20 # 3. 找出最近 10 分钟内被修改过的文件排除系统正常写入 find /usr -mmin -10 -type f -size 100M -exec ls -lh {} \; # 4. 检查是否有被删除但仍被进程占用的文件 lsof L1 | grep deleted逻辑说明df -h确定告警分区du -sh /usr/*快速定位大体积的子目录find按修改时间和文件大小双重筛选可以避开系统自动产生的临时文件比如日志目录下的轮转文件。lsof L1这一步特别容易被忽略经常出现的情况是文件已经被rm删掉了但进程仍然持有文件描述符磁盘空间并没有真正释放。只有重启对应进程或者找到持有者才能回收空间。参数说明-mmin -10表示修改时间在 10 分钟以内这个时间窗口可以按实际情况调整-size 100M排除小文件专盯大文件exec ls -lh展示文件大小和修改时间避免find默认输出不直观。6.2 网络层面引发的服务器故障原文有一句话值得反复琢磨“绝大多数的问题是网络方面引起来的”。这个说法在真实运维中非常准确。很多表面上的“服务器故障”最终排查下来是网络层面的问题。典型的场景服务器负载正常、磁盘没有异常、系统日志无明显错误但服务就是访问不了。这时用ping测试网关、检查 DNS 配置、查看路由表往往能找到答案。# 排查链路先看网卡是否 up ip link show # 查看路由和网关配置 ip route # 检查 DNS 解析 cat /etc/resolv.conf # 检查默认网关的连通性 ping -c 3 网关IP如果网卡显示 DOWN用ip link set dev eth0 up拉起如果是 DHCP 获取不到地址检查 DHCP 服务端状态如果是 DNS 配置错误改/etc/resolv.conf。这些基础排查动作往往比分析系统日志更直接有效。原文还提到“电信一般会封掉 80 端口”这里不便展开讨论具体服务商的行为但作为一条通用经验仍然成立当应用从某个特定网络方向访问异常而本地排查一切正常时需要考虑中间链路或外部策略限制。排查时用tcpdump抓包看 SYN 包有没有回包就能确定问题在本地还是远端。6.3 服务器巡检清单的“保存现场”思路从前面几个案例中可以抽象出一个更通用的运维习惯在动手修复之前永远先保存现场。保存现场不等于备份数据而是记录当前的状态信息这样才能在修复过程中对比前后变化。我自己巡检服务器时保留了这样一套固定流程# 1. 记录当前挂载状态 mount /var/log/mount_snapshot # 2. 记录磁盘分区信息 lsblk -f /var/log/lsblk_snapshot # 3. 记录路由和网络配置 ip addr ip route /var/log/network_snapshot # 4. 记录关键进程状态 ps aux /var/log/ps_snapshot # 5. 记录 RAID 状态如果有硬件 RAID cat /proc/mdstat /var/log/mdadm_snapshot这套快照在系统出问题时是回溯现场的关键依据fstab 改坏了对比挂载快照知道原来的挂载点网络不通了对比网络快照知道原来的 IP 和路由。处理生产环境故障时不管多紧急先花一分钟保存现场。这一分钟能救回几小时的排查时间运气不好时甚至能救回整个系统的数据。6.4 关于 RAID 告警的解读原文提到“DELL 的机器的 RAID 卡放电和充电都是正常现象如果有 Nagios 报警也是正常的”。这个提示非常重要。硬件 RAID 卡上的电池在掉电或老化后会自动充放电这个过程通过 RAID 管理工具能看到状态变化普通监控系统无法区分是真正故障还是正常充电容易被误判为阵列异常。我遇到过不止一次这类误报警。解决的办法有两个一是对高可用告警级别做区分把 RAID 电池充放电对应的事件单独归类二是用 RAID 卡官方管理工具如 Dell 的 OMSA、MegaCLI检查电池状态确认是正常的充放电循环后再处理告警。如果题目写的是 Nagios则可以在 Nagios 配置里针对 RAID 电池状态设置独立的检查间隔和报警阈值避免被无意义的告警淹没。服务器风扇检查也是一项基础但关键的巡检项。原文说“服务器中最容易坏掉的是风扇”这句话基本可信。风扇故障不解决散热跟不上CPU 温度快速上升接下来就是自动关机或硬件老化加速。感知风扇故障的方式通常是服务器前面板告警灯或 IPMI 事件日志独立于操作系统的 Nagios 监控之外。6.5 关于 Keepalived 与 Heartbeat 的模拟故障原文最后提到的建议值得展开有机会做 Keepalived 和 Heartbeat 的模拟故障实验。高可用方案不经过演练等于没有高可用。配置写得再完美在真实故障发生时也可能因为一个脚本错误导致 VIP 无法切换。模拟故障实验的重点不是“把主节点停机看备节点能不能接管”而是在主节点上kill掉 Keepalived 进程观察 VIP 是否按预期漂移到备节点在备节点上tcpdump监听 VRRP 协议确认通告报文正常手工执行健康检查脚本确认脚本返回码符合预期在主节点上模拟服务异常但进程存活观察健康检查能否正确识别这些演练至少每个季度做一次。线上故障发生时能冷静处理很大程度上归功于平时的模拟训练。这套方法从那次以后我一直保持着处理任何服务器故障前先保存现场修完再对照快照确认改动没有偏离预期。在 fstab 上吃过亏之后我每次改完配置都会强制执行一遍mount -a验证避免把故障从“设备缺失”升级成“配置错误”。希望这些经验能帮到你。本文还有配套的精品资源点击获取 Linux服务器故障排查实战：从fstab到GRUB的完整排障笔记
简介面向Linux/Unix系统运维人员这份PDF资源聚焦服务器日常运行中高频出现的故障场景以故障现象、排查过程、解决命令为主线帮助读者建立从定位问题到恢复服务的完整思路。内容包含RAID1数据分区挂载异常、依赖库缺失导致root无法登录、误删GRUB分区、移除硬盘后系统进入紧急模式、FreeBSD jail的/usr被占满五个真实案例并附有作者多年运维总结的注意事项涵盖文件系统检查、磁盘修复、引导恢复与存储空间清理等典型处置方法。压缩包为单个PDF文件大小367KB内容紧凑便于随时查阅。已有92人学习下载适合有一定Linux基础、希望提升故障排查能力的运维人员参考。1. Linux 服务器故障排查一份来自一线的排障笔记做运维这几年服务器故障见得多了最深的感触是真正危险的不是故障本身而是处理故障时的手忙脚乱。这篇关于 Linux 服务器故障的笔记值得仔细拆解因为里面的“故障一”几乎是每个运维都会遇到的场景——挂载 RAID 分区后文件全部异常那一瞬间冷汗就下来了。这份笔记恰恰记录了这类问题的正确处理顺序而且非常贴近实际生产环境。从 CentOS 到 FreeBSD从 GRUB 修复到 Emergency 模式覆盖的场景足够典型正适合刚接触服务器运维、或者正在学习 Linux 故障排查的从业者。不过要注意这份笔记成文较早部分系统版本已经过时但其中的排查思路和命令在今天的 Linux 系统上仍然通用。我在复现过程中会补充近年来的一些变化帮你识别哪些操作需要调整。2. RAID 数据分区挂载异常fstab 与 fsck 的正确使用顺序2.1 为什么挂载后文件会“全部出错”先看原文描述的故障现象一台 64 位 CentOS 5.5 服务器四块硬盘做了两个 RAID1一个给 OS一个是数据盘。系统重装后直接执行mount /dev/mapper/ddf1_datap1 /data挂载数据盘挂载很顺利但用ll一看文件全部异常。这里的关键问题为什么挂载成功了文件却是错的常见做法是文件系统没被正确识别时系统可能以错误的参数挂载了分区。CentOS 5.5 时代DDFDisk Data Format阵列的 device mapper 条目和普通分区不同如果分区表信息不完整或者阵列元数据还没有被正确激活直接挂载可能把文件系统当成未初始化或损坏的状态。另一个容易忽略的原因系统重装后数据盘虽然没动过但 RAID 驱动或者 device mapper 的设备节点发生了变话。挂载动作本身“成功”了但底层文件系统层看到的设备内容和实际数据不一致表现出来就是文件全部异常。原文作者的处理方式是把挂载条目写进/etc/fstab重启后一切正常。这个操作的本质是让系统在启动过程中按正确的顺序加载 RAID 驱动、激活阵列、再挂载文件系统。手动mount时如果阵列还没完全激活或者内核还没识别到完整的 RAID 元数据就会出现“挂载成功但数据不对”的情况。2.2 defaults 选项的含义与影响原文里专门提到“大家别小看 defaults 选项这个默认会作许多事情的”。在/etc/fstab中defaults实际上展开为多个挂载选项/dev/mapper/ddf1_datap1 /data ext3 defaults 0 0defaults实际包含rw, suid, dev, exec, auto, nouser, async这组选项。rw表示读写挂载auto表示允许mount -a时自动挂载async表示所有文件系统操作采用异步方式。大多数情况下defaults是安全的选择。但需要注意它不包含noatime这意味着每次访问文件都会更新访问时间对高 IO 负载的数据库服务器会产生额外的写入开销。生产环境中MySQL 数据盘常见的挂载选项是defaults,noatime,nodiratime或者加上barrier1ext4 文件系统。原文这个案例值得注意的另一点作者写的是 ext3 文件系统。现代 Linux 系统大多已经切换到 ext4 或 xfs但挂载逻辑和排障思路是一样的。2.3 安全的复现操作顺序fsck 优先挂载在后原文最后写了一句“最后是将所有的数据备份后再仔细的 fsck 一遍确认无误再进行挂载”。这句话的顺序非常关键但实际操作中应该调整一下顺序——先检查再挂载而不是先挂载再检查。我在处理类似情况时会这样做# 1. 先检查 RAID 阵列状态确认设备节点存在 cat /proc/mdstat ls -l /dev/mapper/ | grep ddf1 # 2. 检查文件系统完整性-f 强制检查-y 自动修复 fsck -f -y /dev/mapper/ddf1_datap1 # 3. 以只读方式挂载先用 dmesg 确认内核日志无异常 mount -o ro /dev/mapper/ddf1_datap1 /mnt/data_check # 4. 只读挂载检查确认没问题后再读写挂载 umount /mnt/data_check mount /dev/mapper/ddf1_datap1 /data # 5. 查看挂载状态和系统日志 df -h /data dmesg | tail -n 30逻辑说明第 1 步确认 RAID 设备在系统中被正确识别避免对不存在的设备执行耗时操作第 2 步fsck必须在挂载前执行否则文件系统已经被内核使用fsck会拒绝操作或产生不正确的结果第 3 步先只读挂载是为了给数据多一层保护确认文件列表正常后再正式使用。参数说明-f是强制检查即使文件系统标记为 clean 也会执行完整扫描-y是遇到问题时自动回答 yes适合无人值守的检查场景。生产环境建议先不加-y手动跑一遍看清楚有哪些问题再决定是否自动修复。这条处理链路我已经在线上环境执行过多次尤其是系统重装后第一次挂载数据盘之前。不要嫌 fsck 耗时长——一块几 TB 的盘全盘检查可能需要好几个小时但比起数据丢失这点时间成本非常值得。2.4 fstab 写错导致开不了机常见误用/etc/fstab的坑远不止挂载选项本身。最常见的翻车现场是字段数写错导致无法开机。fstab 每行有 6 个字段字段含义注意事项设备可以是 /dev/xxx 或 UUID推荐用 UUID设备名可能变化挂载点系统目录路径不能有空格和特殊字符文件系统类型ext4、xfs、swap 等要与实际格式一致挂载选项defaults 或其他注意 sync/async、noatime 等dump是否备份0 或 1通常写 0passfsck 检查顺序根分区写 1其他写 2不需要检查写 0最容易出错的是最后一个字段。如果一张数据盘写成0 1系统启动时会对它执行 fsck碰到大容量盘中途卡住是常有的事。数据盘应该写0 0表示不参与启动时的 fsck 检查。还有一类常见问题用/dev/sdb1这种设备路径写 fstab但服务器加了一块新硬盘后设备名漂移比如 sdb 变成了 sdc系统启动时找不到对应设备就进 emergency mode。正确的做法是用blkid查 UUID然后写入 fstab# 查看分区的 UUID blkid /dev/sdb1 # 用 UUID 写 fstab echo UUID$(blkid -s UUID -o value /dev/sdb1) /data ext4 defaults 0 0 /etc/fstab这样一来即使设备名变了系统仍然能通过 UUID 精确定位到分区。我之前就见过一个同事因为设备名漂移导致生产服务器启动后进不了系统恢复方法是单用户模式下改 fstab但如果最初就用 UUID根本不会有这个问题。2.5 避坑记录现象一用mount挂载数据盘后ll看到文件全变成异常状态原因RAID 设备或 device mapper 条目还没完全激活文件系统层读到了不一致的数据。也可能文件系统本身存在损坏需要检查。解决先确认 RAID 阵列状态cat /proc/mdstat再对分区执行fsck最后写进 fstab 重启。严禁在文件系统异常时直接往上面写数据。现象二修改 fstab 后重启系统卡在维护模式原因fstab 中某一行语法错误或者挂载点不存在、设备路径不对。系统无法完成挂载就进入了 emergency mode。解决在维护模式下执行mount -o remount,rw /让根文件系统可写然后编辑 fstab 修正错误行。改完执行mount -a验证语法是否正确再重启。现象三分区表没问题但 /data 挂载后是空的原因挂载点本身是空目录时如果设备里没有数据挂了也是空的。另一种情况是之前有过数据但挂载到了别的目录或者文件系统被误格式化。解决用mount和df -h确认挂载状态用lsblk -f查看分区上的文件系统类型。如果分区上原本是 xfs 而挂载成 ext4就会出现设备被识别但内容异常的情况。3. root 无法登录libintl 丢失与单用户模式修复3.1 bash 依赖库文件丢失的症状原文第二个故障涉及 FreeBSD 的 jail 母机root 的 shell 是 bash而 bash 依赖的库文件libintl.so.8丢失直接导致 root 无法登录。具体报错信息是这样的/libexec/ld-elf.so.1: Shared object libintl.so.8 not found, required by bash Connection to 192.168.21.36 closed.这个案例的典型意义在于动态链接库丢失导致登录 shell 无法启动用户连系统都进不了。这类问题在 Linux 上同样存在比如libc.so.6被误删或覆盖几乎所有命令都无法执行局面比 FreeBSD 这个案例更严峻。修复的逻辑是相通的不能依赖正常登录必须走单用户模式或救援模式进入系统后先修复依赖再切换回正常的 shell。对于这类问题我建议先确认几个信息库文件是彻底被删了还是被替换成了不兼容的版本ldd /bin/bash能列出 bash 依赖的动态库清单如果libintl.so.8显示 not found那就需要找到正确的库文件恢复。如果以前备份过直接拷回去就行如果没有备份可以从同版本的系统包中提取。3.2 单用户模式下的修复步骤原文已经给出了一套可复现的流程我做了一些补充和调整。以 Linux 系统为例# 1. 在启动菜单选择内核时按 e进入编辑模式 # 2. 在 kernel 那一行末尾加上 single 或 1按 b 启动进入单用户模式 # 3. 进入单用户模式后先检查根文件系统 fsck -y # 4. 重新挂载所有文件系统 mount -a # 5. 查看 bash 的库依赖情况 ldd /bin/bash | grep libintl # 6. 如果缺失先从 rpm 包中提取或从其他机器拷贝 # 以 CentOS 为例用 rpm 验证 bash 包完整性 rpm -V bash # 7. 临时把 root 的 shell 切换为 /bin/sh chsh -s /bin/sh root # 8. 重启验证 reboot逻辑说明单用户模式只挂载根文件系统且默认是只读的所以第 4 步的mount -a在实际操作中通常配合mount -o remount,rw /使用把根文件系统改为可写才能执行后面的chsh和文件修复。fsck -y的安全意义在于单用户模式下文件系统没有被大量占用检查和修复的干扰最小。参数说明chsh -s /bin/sh root把 root 的登录 shell 改为 sh修改即时生效。如果之后想换回 bash得先在系统里修复好 bash 的依赖库否则又会出现登录不了的问题。FreeBSD 下对应的命令是chsh -s /bin/sh root语法类似。3.3 不是只有 bash 才会翻车这类“登录 shell 挂了导致进不了系统”的故障在真实环境中出现过很多变种变种一.bash_profile或.profile中有死循环或错误的命令登录时卡住看起来像是系统假死实则是脚本执行异常。解决方法是通过单用户模式进入系统把这两个文件改名备份# 在单用户模式下挂载根文件系统为可读写 mount -o remount,rw / # 备份出问题的用户配置文件 mv /root/.bash_profile /root/.bash_profile.bak mv /root/.bashrc /root/.bashrc.bak之后重启登录恢复正常再排查脚本中的具体问题。变种二系统提示libc.so.6版本不对连 ls、cat 都执行不了这种情况比缺失某个库文件更棘手因为几乎所有动态链接的命令都不可用。修复办法是通过救援模式启动或者使用系统安装盘的 chroot 环境# 在救援模式下挂载原系统的根分区 mount /dev/sda1 /mnt/sysimage chroot /mnt/sysimage # 在 chroot 环境下修复 libc rpm -e --nodeps glibc rpm -ivh glibc-xxx.rpm注意rpm -e --nodeps这种操作极其危险只适合已经无法正常启动的系统。实际操作中更稳妥的方式是直接用安装光盘的linux rescue模式让系统自动识别并修复。3.4 避坑记录现象一单用户模式登录后提示 root 密码错误原因单用户模式下某些系统变体仍然要求输入 root 密码或者/etc/shadow文件损坏。解决如果是 CentOS 7/RHEL7 以上单用户模式默认还是需要密码的要在启动时加上single rd.break配合chroot /sysroot操作。具体做法是修改启动参数为rd.break系统会停在 initramfs 阶段然后mount -o remount,rw /sysroot chroot /sysroot passwd root touch /.autorelabel exit reboot现象二chsh 修改 shell 后root 登录仍然失败原因bash 依赖的库文件虽然恢复了但可能存在符号链接指向错误路径例如libintl.so.8实际文件名是libintl.so.8.1缺少软链。解决手动创建正确的软链ln -sf /usr/lib/libintl.so.8.1 /usr/lib/libintl.so.8 ldconfig现象三fsck 执行到一半卡住不动敲什么都没反应原因fsck -y在修复大量错误时确实会耗时较长看起来像卡死。但如果超过几十分钟没有磁盘 IO 变化可能是文件系统损坏严重。解决先确认当前分区是否是根分区——如果执行fsck时根分区处于挂载状态会有严重的风险。正确做法是使用fsck -f前先确认该分区未被挂载。如果确实卡住重启进入单用户模式后用fsck -y配合timeout限制时间或者先备份分区镜像再尝试修复。4. GRUB 分区误删双系统引导修复的完整链路4.1 误删 GRUB 分区后的实际困境原文第三个故障是工作机上误删了 GRUB 所在的分区/dev/hdb8装的是 Windows 2003 和 CentOS 5.3 双系统结果 Windows 也进不去了。这台机器没有光驱和软驱U 盘启动也不支持最后靠网络引导和 MBR 修复工具解决了问题。这类问题在今天的运维环境中不算高频但一旦发生就非常紧急因为双系统的机器往往是个人开发机或测试机数据可能没有及时备份。误删 GRUB 分区后系统的行为是BIOS 从硬盘启动读取 MBRMBR 里指向 GRUB 引导代码的扇区已经不存在了屏幕显示grub提示符或者GRUB loading, please wait... Error 22之类的错误。需要明确的一点误删 GRUB 所在分区不等于删了系统所在分区。如果只是删除了/dev/hdb8这个引导分区Windows 的 C 盘数据和 Linux 的 / 分区数据未必受到影响只要修复 MBR 和 GRUB 配置就能恢复启动。但如果连引导扇区都被覆盖情况会更麻烦。4.2 保留现场优先进入 grub 交互模式手动引导修复的过程通常有两种路线一是用引导盘进入 DOS 或 PE 环境用工具修复 MBR二是直接在 GRUB 提示符下手动指定启动参数。原文给出的第二种办法非常实用我把它整理成更清晰的流程。当 GRUB 因为找不到配置文件而落到grub交互提示符时可以手动输入命令引导 Windows# 在 grub 提示符下把第一块硬盘的第一个分区设置为根设备不加载文件系统 rootnoverify (hd0,0) # 把引导权转交给当前分区首扇区 chainloader 1 # 执行启动 boot各参数含义(hd0,0)表示第一块物理硬盘的第一个分区rootnoverify的作用是告诉 GRUB “这个分区是根设备”但不实际挂载文件系统也不检查文件系统类型这样做的原因是我们无法预知 Windows 分区是否有 GRUB 支持的文件系统chainloader 1把控制权交给分区首扇区上的引导代码boot正式启动。如果进 Linux 系统后发现 GRUB 文件确实损坏了可以在 Linux 系统内重新安装 GRUB 到 MBR# CentOS 5/6 系列使用 grub-install grub-install /dev/sda # 重新生成配置文件 grub-mkconfig -o /boot/grub/grub.conf对于 CentOS 7 及以上版本GRUB2 的用法不同# 重新安装 GRUB2 引导程序 grub2-install /dev/sda # 重新生成配置文件 grub2-mkconfig -o /boot/grub2/grub.cfg注意grub-install和grub2-install是针对系统当前使用的引导方式的。安装时如果出现No Cursor或/dev/sda相关的错误可能是 BIOS 引导模式和 UEFI 引导模式的差异需要先确认系统是用哪种模式启动的。4.3 网络引导与 MBR 修复工具的组合操作原作者的机器不支持 U 盘引导他选择了网络引导方案用 MaxDOS_71PXE_G115.exe 做网络 Ghost 引导进入 DOS 环境后用 diskgen 或 spfdisk 修复 MBR。这段操作看似简单实际上有几个关键节点需要注意。网络引导成功后会出现一个 DOS 启动菜单里面通常包含 Ghost 和分区工具。如果在 Ghost 克隆结束后选择了“立即重启”会回到原来的 GRUB 错误状态因为 Ghost 没有修复 MBR 引导代码。正确顺序应该是网络引导 → 进入 DOS → 用 diskgen/spfdisk 修复 MBR → 验证分区表 → 重启。原文提到还可以用fdisk /mbr这是 DOS 时代遗留的工具作用是把标准 MBR 引导代码写回硬盘首扇区。这个操作对 Windows 分区有效但如果原来是用 GRUB 引导 Linuxfdisk /mbr会让 Linux 无法从 MBR 启动需要重新安装 GRUB 才能恢复。实际上在 Linux 系统内修复 MBR 有一个更常见的做法原文没有提到直接用 dd 备份和恢复 MBR。比如在重装系统之前把 MBR 备份出来# 备份第一个扇区 dd if/dev/sda of/root/mbr_backup bs512 count1 # 恢复 MBR dd if/root/mbr_backup of/dev/sda bs512 count1这条命令只操作 MBR 扇区不影响分区表之外的数据。但要注意如果分区表本身也变了直接恢复旧的 MBR 可能会把分区表覆盖成旧状态导致数据分区不识别。所以在恢复 MBR 前务必确认分区表是否和备份时一致。4.4 避坑记录现象一GRUB 修复后Windows 能启动但 Linux 进不了原因GRUB 配置中 Linux 的 root 设备指向了旧的分区号修复 GRUB 后分区编号发生了变化。解决重新进入 grub 提示符执行root (hd0,X)和setup (hd0)重建引导其中 X 是 Linux /boot 所在的实际分区号。也可以启动后修改/boot/grub/grub.conf或/boot/grub2/grub.cfg中的 root 参数。现象二fdisk /mbr 和 spfdisk 修复完成后重启屏幕提示无效分区表原因MBR 修复工具把引导代码写进去了但分区表本身已经损坏或者修复工具在写入时误改了分区表。解决不要反复执行fdisk /mbr这会覆盖更多扇区。用 testdisk 扫描分区表并尝试恢复恢复完成后重新安装 GRUB。现象三网络引导后找不到 Ghost 工具或 DOS 启动盘原因网络引导环境没有正确映射到包含 Ghost 的镜像或者网卡驱动不被 PXE 引导环境支持。解决将 MaxDOS 的镜像文件放到 TFTP 服务器的正确目录下然后检查 PXE 配置中引导文件名和 DHCP 下一个服务器地址是否正确。老机器网卡驱动的兼容性问题可能需要换用 Linux 下的systemrescuecd或类似工具做 PXE 引导。5. 移除硬盘后系统进入 Emergency 模式fstab 与硬件变更的关联5.1 Emergency 模式的触发机制原文第四个故障非常有代表性同事移走一块硬盘后直接启动 RHEL5系统进入 Emergency 模式。原因很清楚——/etc/fstab里还记录着那块被移除硬盘的挂载信息启动时系统尝试挂载不存在的设备就报错。Linux 在启动过程中会根据 fstab 逐条挂载文件系统。如果某个设备条目失败了系统不会忽略它而是直接进入 Emergency 模式等待人工干预。这是设计上的安全策略如果自动跳过挂载失败的设备可能导致数据分区未被正确挂载系统照常启动后面无数服务都会出问题数据写入错误时才意识到情况严重那时已经晚了。Emergency 模式的行为特征是系统启动后呈现的是一个极简的 shell 环境根文件系统被挂载为只读。在这里可以执行有限的管理命令但要修改 fstab 必须先把根分区重新挂载为可写。5.2 紧急模式下的可写重挂载与 fstab 修正原文描述的重点操作是mount -o remount,rw /。下面把完整流程展开# 1. 在 Emergency 模式下输入 root 密码后进入 shell # 2. 查看当前挂载状态确认根分区只读 mount | grep / # 3. 重新挂载根分区为可读写 mount -o remount,rw / # 4. 打开 fstab确认哪些条目涉及已移除的硬盘 cat /etc/fstab # 5. 把对应条目注释掉或删除 # 例如原始条目是 /dev/sdb1 /backup ext4 defaults 0 0 # 改为以下内容 # /dev/sdb1 /backup ext4 defaults 0 0 # 6. 执行挂载验证确认没有报错 mount -a # 7. 重启 reboot逻辑说明第 2 步确认根分区是否处于只读状态避免直接mount -o remount,rw去覆盖已经可写的文件系统第 4 步列出全部条目找到被移除硬盘对应的那一条第 5 步注释掉之后第 6 步的mount -a能检查 fstab 是否存在语法问题。ipad 再重启系统就能正常进入到多用户模式。参数说明mount -o remount,rw /中的remount表示重新挂载已挂载的文件系统rw切换为读写模式。这条命令在救援和排障场景中使用频率非常高操作本身不改变文件系统内容只是修改挂载标志相对安全。5.3 为什么说“移走硬盘不更新 fstab”是灾难级操作这篇文章里的故障在真实运维中几乎每周都能遇到。很多人觉得改 BIOS 设置、加硬盘、拔硬盘都是硬件操作不需要通知运维。但是拔硬盘之前得先搞清楚这块盘在系统里扮演什么角色。场景风险正确处理数据盘整盘移除fstab 还有挂载条目系统启动进 Emergency 模式先注释 fstab 条目再做物理移除拔掉 RAID 成员盘之一视 RAID 级别可能出现数据丢失或降级先确认阵列状态确认可安全离线更换硬盘后设备名变化fstab 的 UUID/设备名可能失效用 blkid 获取新设备 UUID更新 fstab如果系统里跑了数据库或应用服务直接在开机状态下拔掉数据盘会导致进程崩溃甚至文件系统损坏绝不是“像 Windows 一样直接移走”就行了的。实际上Windows 也不是完全无感的。Windows 的盘符分配也有自己的规则只是对硬件变更的容错相对宽松。Linux 的设计逻辑不同一切挂载关系都由 fstab 显式定义系统启动时按配置执行任何一个环节出了问题都会明确报错并等待人工处理——这从故障排查的角度反而是好事。5.4 避坑记录现象一在 Emergency 模式下执行 mount -a部分挂载条目依然报错原因根文件系统虽然被重挂载为可写但其他分区比如 /home、/var可能还没有挂载mount -a会按照 fstab 里的顺序逐个尝试。被移除硬盘的条目被注释掉之后应该不会再报错但如果注释的行号不对或者挂载点目录不存在仍然会报错。解决先执行mkdir -p创建缺失的挂载点目录再执行mount -a。检查时用df -h和lsblk验证挂载结果。现象二注释掉 fstab 中的一条之后重启仍然进 emergency mode原因fstab 里可能不止一处引用被移除的硬盘比如 swap 条目、另一个数据分区条目。注释掉一条不够。解决在执行mount -a时系统会从上到下逐条执行遇到第一个报错就停止。用mount -a -v可以看到每一步的输出根据输出定位到具体哪一行有问题然后修正对应条目。现象三用 mount -o remount,rw / 时提示 Device or resource busy原因有进程正在占用根文件系统的文件常见的有日志服务、数据库进程。Emergency 模式下系统服务较少但如果有残留进程重挂载会被拒绝。解决先尝试lsof /或fuser -v /查看哪些进程占用必要时用kill或fuser -k /结束它们。如果实在无法终止可以在重启时通过内核启动参数init/bin/bash进入这样不经过完整的服务启动流程占用进程会少很多。6. 故障定位的思路与方法从磁盘占满到系统巡检6.1 最快定位“大文件写入”的搜索组合原文最后一个技术故障来自 FreeBSD jail 虚拟机某个程序形成死循环持续写某个文件导致 /usr 分区被占满。作者使用的方法是先touch test创建测试文件再执行find / -newer test找出比 test 文件更新的文件。这类“分区突然占满”的故障核心诉求只有一个快速定位可疑文件。Linux 系统下我常用的定位命令和原文的思路一致但可以更精确一些# 1. 确认哪个分区满了 df -h # 2. 查看该分区根目录下每个目录的体积 du -sh /usr/* | sort -rh | head -20 # 3. 找出最近 10 分钟内被修改过的文件排除系统正常写入 find /usr -mmin -10 -type f -size 100M -exec ls -lh {} \; # 4. 检查是否有被删除但仍被进程占用的文件 lsof L1 | grep deleted逻辑说明df -h确定告警分区du -sh /usr/*快速定位大体积的子目录find按修改时间和文件大小双重筛选可以避开系统自动产生的临时文件比如日志目录下的轮转文件。lsof L1这一步特别容易被忽略经常出现的情况是文件已经被rm删掉了但进程仍然持有文件描述符磁盘空间并没有真正释放。只有重启对应进程或者找到持有者才能回收空间。参数说明-mmin -10表示修改时间在 10 分钟以内这个时间窗口可以按实际情况调整-size 100M排除小文件专盯大文件exec ls -lh展示文件大小和修改时间避免find默认输出不直观。6.2 网络层面引发的服务器故障原文有一句话值得反复琢磨“绝大多数的问题是网络方面引起来的”。这个说法在真实运维中非常准确。很多表面上的“服务器故障”最终排查下来是网络层面的问题。典型的场景服务器负载正常、磁盘没有异常、系统日志无明显错误但服务就是访问不了。这时用ping测试网关、检查 DNS 配置、查看路由表往往能找到答案。# 排查链路先看网卡是否 up ip link show # 查看路由和网关配置 ip route # 检查 DNS 解析 cat /etc/resolv.conf # 检查默认网关的连通性 ping -c 3 网关IP如果网卡显示 DOWN用ip link set dev eth0 up拉起如果是 DHCP 获取不到地址检查 DHCP 服务端状态如果是 DNS 配置错误改/etc/resolv.conf。这些基础排查动作往往比分析系统日志更直接有效。原文还提到“电信一般会封掉 80 端口”这里不便展开讨论具体服务商的行为但作为一条通用经验仍然成立当应用从某个特定网络方向访问异常而本地排查一切正常时需要考虑中间链路或外部策略限制。排查时用tcpdump抓包看 SYN 包有没有回包就能确定问题在本地还是远端。6.3 服务器巡检清单的“保存现场”思路从前面几个案例中可以抽象出一个更通用的运维习惯在动手修复之前永远先保存现场。保存现场不等于备份数据而是记录当前的状态信息这样才能在修复过程中对比前后变化。我自己巡检服务器时保留了这样一套固定流程# 1. 记录当前挂载状态 mount /var/log/mount_snapshot # 2. 记录磁盘分区信息 lsblk -f /var/log/lsblk_snapshot # 3. 记录路由和网络配置 ip addr ip route /var/log/network_snapshot # 4. 记录关键进程状态 ps aux /var/log/ps_snapshot # 5. 记录 RAID 状态如果有硬件 RAID cat /proc/mdstat /var/log/mdadm_snapshot这套快照在系统出问题时是回溯现场的关键依据fstab 改坏了对比挂载快照知道原来的挂载点网络不通了对比网络快照知道原来的 IP 和路由。处理生产环境故障时不管多紧急先花一分钟保存现场。这一分钟能救回几小时的排查时间运气不好时甚至能救回整个系统的数据。6.4 关于 RAID 告警的解读原文提到“DELL 的机器的 RAID 卡放电和充电都是正常现象如果有 Nagios 报警也是正常的”。这个提示非常重要。硬件 RAID 卡上的电池在掉电或老化后会自动充放电这个过程通过 RAID 管理工具能看到状态变化普通监控系统无法区分是真正故障还是正常充电容易被误判为阵列异常。我遇到过不止一次这类误报警。解决的办法有两个一是对高可用告警级别做区分把 RAID 电池充放电对应的事件单独归类二是用 RAID 卡官方管理工具如 Dell 的 OMSA、MegaCLI检查电池状态确认是正常的充放电循环后再处理告警。如果题目写的是 Nagios则可以在 Nagios 配置里针对 RAID 电池状态设置独立的检查间隔和报警阈值避免被无意义的告警淹没。服务器风扇检查也是一项基础但关键的巡检项。原文说“服务器中最容易坏掉的是风扇”这句话基本可信。风扇故障不解决散热跟不上CPU 温度快速上升接下来就是自动关机或硬件老化加速。感知风扇故障的方式通常是服务器前面板告警灯或 IPMI 事件日志独立于操作系统的 Nagios 监控之外。6.5 关于 Keepalived 与 Heartbeat 的模拟故障原文最后提到的建议值得展开有机会做 Keepalived 和 Heartbeat 的模拟故障实验。高可用方案不经过演练等于没有高可用。配置写得再完美在真实故障发生时也可能因为一个脚本错误导致 VIP 无法切换。模拟故障实验的重点不是“把主节点停机看备节点能不能接管”而是在主节点上kill掉 Keepalived 进程观察 VIP 是否按预期漂移到备节点在备节点上tcpdump监听 VRRP 协议确认通告报文正常手工执行健康检查脚本确认脚本返回码符合预期在主节点上模拟服务异常但进程存活观察健康检查能否正确识别这些演练至少每个季度做一次。线上故障发生时能冷静处理很大程度上归功于平时的模拟训练。这套方法从那次以后我一直保持着处理任何服务器故障前先保存现场修完再对照快照确认改动没有偏离预期。在 fstab 上吃过亏之后我每次改完配置都会强制执行一遍mount -a验证避免把故障从“设备缺失”升级成“配置错误”。希望这些经验能帮到你。本文还有配套的精品资源点击获取