Linux操作系统故障排查案例实战

前言：

       Linux操作系统作为企业级服务的核心载体，其稳定性直接影响业务连续性然而硬件老化、配置变更、资源瓶颈等风险无处不在，运维人员需在分钟级响应中精准定位故障根源——这要求我们既掌握日志分析、性能监控等硬技能，更需建立系统化的排查思维。本指南从数百个真实案例提炼方法论，旨在帮助工程师跨越“盲目试错”阶段，构建分层诊断能力，让故障修复从被动救火转向主动防御。

目录

案例1：GRUB引导故障

案例2：文件系统只读故障

案例3：OOM Killer触发

案例4：系统启动卡住（initramfs损坏）

案例5：磁盘空间耗尽

案例6：SSH登录缓慢

案例7：逻辑卷无法扩展

案例8：内核模块冲突

案例9：NTP时间不同步

案例10：SELinux导致服务异常

案例11: root密码遗忘

学习建议

总结

---

案例1：GRUB引导故障

故障现象：
系统启动卡在"GRUB>"提示符，无法进入系统

原因分析：

1.GRUB配置文件损坏（/boot/grub/grub.cfg）

2.引导文件被误删或磁盘损坏
解决步骤：

1.在GRUB命令行依次执行：

insmod xfs
set root=(hd0,msdos1)
linux16 /vmlinuz-3.10.0-1160.el7.x86_64 root=/dev/mapper/centos-root ro crashkernel=auto rd.lvm.lv=centos/root rd.lvm.lv=centos/swap rhgb quiet
initrd16 /initramfs-3.10.0-1160.e17.x86_64.img
boot

2.进入系统后执行：grub2-mkconfig -o /boot/grub2/grub.cfg

案例2：文件系统只读故障

故障现象：
无法创建文件，提示"Read-only file system"
排查过程：

1.dmesg | grep -i error 发现磁盘I/O错误

2.smartctl -a /dev/sda 检查磁盘健康状态

解决方案：

1.卸载分区：umount /dev/sda1

2.强制修复：fsck -y /dev/sda1 或者xfs文件系统：xfs_repair /dev/sda1

3.重新挂载：mount -a

案例3：OOM Killer触发

故障现象：
关键进程突然被终止，系统日志出现"Killed process"
分析工具：

1.grep -i 'killed process' /var/log/messages

2.free -h 查看内存使用情况

3.vmstat 1 监控内存交换

优化方案：

1.调整oom_score_adj：echo -100 > /proc/[PID]/oom_score_adj

2.修改sysctl.conf：

#涉及到内存优化
vm.overcommit_memory = 2   #对内存超出多少内存的提交，内存提交的一个限制
vm.overcommit_ratio = 80   #速率IO，超过这个数值范围之后要做一些处理

案例4：系统启动卡住（initramfs损坏）

故障现象：
启动时卡在"Loading initial ramdisk"
紧急处理：

1.进入救援模式(Troubleshooting)使用Rescue a Centos system

2.选择1）continue 继续，其实就是进入live CD 模式

3.重建initramfs：

chroot /mnt/sysimage
dracut -f /boot/initramfs-$(uname -r).img $(uname -r)
exit
reboot

4. 假如之前调整了bios启动顺序，需要还原回来。

案例5：磁盘空间耗尽

故障现象：
服务异常，df显示使用率100%
快速定位：

1.lsof -n | grep deleted 查找未释放空间的进程

2.du -xh --max-depth=1 / | sort -hr 定位大文件

典型场景：

1./var/log/journal 日志膨胀：journalctl --vacuum-size=100M

2./tmp目录堆积：rm -rf /tmp/*.tmp

案例6：SSH登录缓慢

故障现象：
SSH连接延迟超过10秒
排查步骤：

1.ssh -vvv user@host 查看详细日志

2.检查DNS配置：UseDNS no in sshd_config

3.关闭GSSAPI认证：GSSAPIAuthentication no

4.strace -p [sshd_PID] 跟踪系统调用

案例7：逻辑卷无法扩展

故障现象：
lvextend后文件系统未扩容
正确操作流程：

 lvextend -L +10G /dev/vg01/lv_dataresize2fs /dev/vg01/lv_data  # 对ext4文件系统xfs_growfs /data            # 对XFS文件系统

注意事项：

1.确保物理卷有足够空间：vgs查看Free PE

2.在线扩容无需卸载

案例8：内核模块冲突

故障现象：
系统更新后网卡失效
解决方案：

1.lsmod | grep e1000 查看加载模块

2.modinfo e1000 检查模块信息

filename:       /lib/modules/3.10.0-1160.el7.x86_64/kernel/drivers/net/ethernet/intel/e1000/e1000.ko.xz

3.rmmod e1000 && modprobe e1000 重载驱动

回滚驱动：dnf reinstall kmod-e1000-4.18.0

案例9：NTP时间不同步

故障现象：
日志出现"Clock skew detected"警告
排错流程：

1.ntpq -pn 查看时间源状态

2.chronyc sources -v 检查chrony同步状态

3.systemctl restart chronyd

4.硬件时钟同步：hwclock --systohc

案例10：SELinux导致服务异常

故障现象：
Apache无法访问自定义目录

诊断方法：

tail -f /var/log/audit/audit.log | grep httpd

sealert -a /var/log/audit/audit.log

解决方案：

 # 临时解决setenforce 0# 永久方案semanage fcontext -a -t httpd_sys_content_t "/webroot(/.*)?"restorecon -Rv /webroot

案例11: root密码遗忘

在RHEL/CentOS 7及更新版本中，如果忘记root密码，可以通过以下步骤重置（需物理/虚拟控制台访问权限）：

方法原理

通过修改GRUB2启动参数进入单用户模式，绕过身份验证直接获取root权限

---

详细操作步骤

1.重启系统并中断引导

 # 当系统启动到GRUB菜单时，快速按下方向键阻止自动引导# 选择默认内核条目（通常第一条）按 `e` 键进入编辑模式

2.修改内核参数

 # 在linux16行（或linux行）末尾追加：rd.break enforcing=0​# 修改后的完整行示例：linux16 /vmlinuz-3.10.0-1160.el7.x86_64 root=/dev/mapper/rhel-root ro rd.break enforcing=0

3.进入紧急模式

 # 按 Ctrl+X 启动系统，进入紧急救援模式的shell环境# 此时文件系统挂载在/sysroot（只读模式）

4.重新挂载文件系统

 # 重新挂载为读写模式：mount -o remount,rw /sysroot

5.切换根目录

 chroot /sysroot

6.修改root密码

 # 此时已获得完整root权限：passwd root# 输入新密码两次（不会显示输入内容）

7.修复SELinux上下文

 # 强制重新标记文件系统（重要！）：touch /.autorelabel

8.退出并重启

 exitexitreboot

---

关键参数说明

参数	作用
rd.break	在内核加载初期中断启动流程
enforcing=0	临时禁用SELinux强制模式

---

注意事项

1. 磁盘加密系统：若启用了LUKS加密，需先解密再操作

2. 云服务器：部分云平台需通过VNC或救援模式操作

3. 时间控制：.autorelabel会导致首次重启时间较长（约5-15分钟）

4. UEFI系统：可能需要关闭Secure Boot功能

5. 审计日志：系统日志会记录密码修改操作（/var/log/audit/audit.log）

---

替代方案（适用于不同场景）

1. init方法：

    # 在GRUB的linux行后追加：init=/bin/bash

2. systemd方法：

    systemctl edit --force --full rescue.target

---

防范建议

1. 配置sudo权限给普通用户

2. 使用密码管理工具（如KeePass）

3. 定期进行密码备份（加密存储）

4. 启用SSH密钥认证+sudo组合验证

该方法适用于：RHEL/CentOS 7/8/9、Oracle Linux 7+、Fedora 19+等使用systemd的系统

学习建议

1.每个案例配套实验环境（VM快照）

2.故障模拟建议：

(1)使用dd破坏文件系统头

(2)使用stress触发OOM

(3)手动删除grub.cfg

3.考核方式：故障场景重现→学员排障→处理报告

附加资源推荐：

• Linux Performance观测工具集（perf, ftrace）

• systemd-analyze分析启动耗时

• eBPF工具链（BCC工具包）

总结：

1.信息为锚，日志为舟​
系统日志（/var/log/messages）、内核缓存（dmesg）和资源监控（top/iotop）构成故障定位的黄金三角。例如磁盘满告警需同步检查lsof | grep deleted，避免空间未释放的“幽灵文件”陷阱。
​2.分层拆解，逐级击破​
遵循“硬件→系统→服务→应用”链条：先以smartctl检测磁盘健康，再通过fsck修复文件系统，最后用systemctl status验证服务状态。这种结构化流程可减少误判率超60%。
​3.预防优于修复​
定期巡检磁盘空间（df -h）、配置日志轮转（logrotate）、备份关键文件（/etc/fstab, grub.cfg），能将70%严重故障扼杀于萌芽。当危机突发时，单用户模式与Live CD则是挽救系统的最后防线