一次离奇的脚本失效原因查找过程

背景

最近公司为了实现研发区域和测试区域的网机器网络隔离.
将测试机器整天进行了迁移, 过程中需要关机和搬迁
以及更换网络地址等步骤. 
前期为了提高产品的日志查看. 使用了NFS挂载的方式收集日志. 
因为NFS日志服务器也进行了迁移, 所以导致了一系列的问题. 
这里简单总结一下.

问题现象

因为规划问题, 部分服务器没有发生变化. 机器同时也是开着的.
然后发现部分机器之前正常运行了一年多的启动脚本出现了异常.
会卡死然后无法正常启动服务. 以及进行邮件发送等动作. 
非常奇怪. 

解决过程1

个人感觉调试脚本与调试程序方法和道理是一样的. 
我根据输出的日志发现在某个脚本上卡死了
然后在脚本内部添加 echo 验证执行到什么命令式出现异常. 
类似于开发调试代码时的断点处理.

结果很明显就发现到了 lsof -i:xxxx 获取活动进程信息时 出现了异常卡死的现象.
根据此 需要进一步分析

解决过程2

使用 strace 根据 lsof 具体命令的调用栈
starce lsof -i:5200
然后会进行很长时间的 输出
最后定位到一个具体的进行信息的文件内容 比如我这个的内容是 
/proc/20406/fd/4
这里就很诡异了 然后程序卡住了
要分析下一具体因为什么卡住了.
ps -ef |grep 20406 发现是tee进程写入 nfs 挂载点的问题
这样就有眉目了 
kill -9 20406 
但是发现并没有效果. 进程依旧坚挺
推测应该是tee 和 NFS在NFS失效时出现了内核bug 导致进程都无法kill
没办法只能采取重启打法好.

解决过程3

重启后, 发现没有了 NFS挂载点
tee的进程也没有了.
然后脚本就又可以正常使用了.
这个里面充分说明 重启服务器在很多情况下能够解决问题
这次虽然水了篇文章, 但是也从原理上明白了为何会这样.

这里在补充一点的是 NFS服务器宕机之后 很奇怪的是 
我使用 finalshell的方式都看不到文件和右侧的路径信息等.
今天在解决一个服务器xfs 文件损坏时 学到了一个 
umount -lf /NFS_PATH的命令 然后立马就用了一下
发现就可以理解展开文件和取消挂载了. 
发现命令是无穷尽需要学习的. 知识点非常庞杂. 

总结

重启大法好
多学一点没坏处.
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章