运维人员踩坑记录之总是被忽略的NFS难题

场景

某一天晚上，小明的手机突然收到一堆短信，他很是奇怪，现在的人应该基本都是玩微信，谁还玩短信这么无聊，小明随之一看，当场吓了个半死，是一堆服务器宕机的告警！

 

难道机房被火力攻击了吗？冷静，冷静，小明忍住心慌，打开了电脑，然后打开自己平时用来测试服务器网络的脚本，咦，网络全通，然后再远程服务器看看，发现远程正常，防火墙正常，SNMP服务正常，应用服务正常，但告警短信还是不停的发过来。

恐怖如斯！

不过小明是见过大场面的运维，他很想直接关手机，然后睡觉，但是运维的职业精神引导着他打开了监控服务器，经过一系列检查，确实无法正常监控，然后这些服务器都有一个共同点，df -h卡死

到这里，其实有些经验的人就应该发现，这些服务器都是挂载着同一个NFS服务，而这个NFS服务挂掉了！

 

解决方法

一、如果NFS服务器能恢复，这当然是最理想的情况了，当nfs服务器恢复之时，告警就会自动取消

二、但还是会有一些尴尬的时候，就是nfs服务器死得不能再死了，短时间内或者永久没办法恢复

解决思路：

1、强制取消客户端挂载

2、重新挂载一个新的NFS

处理方法：

1、强制取消客户端挂载

umount -lf nfs目录

2、若不能正常取消挂载，还有另一个办法

df -h主要的文件在/etc/mtab和/etc/fstab，nfs的挂载信息是在/etc/mtab，而且它是一个软连接

 

而/proc/self/mounts是一个内核创建的文件，无法修改，所以我们只能修改/etc/mtab，可以直接用sed进行修改，例如
sed -i ‘29d’ /etc/mtab

 

但是这样，软连接其实会直接中断，或者直接将文件备份，重新创建一个mtab文件，将异常的nfs挂载信息清理了，就能正常df -h了，但是实际上这条异常的nfs信息是没有清理的，还是需要将物理机重启一遍

温馨提醒，不管是遇到什么故障，第一时间，是冷静有条理的分析！