案例4 小脚本惹出了大麻烦

案例4 小脚本惹出了大麻烦

某银行灾备环境. 运维人员经常需要远程校验灾备端数据的可用性。为了方便日常的常规操作写了专门的启动停止脚本.执行完脚本就登录不上测试主机了.能ping通。运维人员反映，偶尔也会发生这样的问题，一般做法就是要求系统管理员帮他们重新启动分区，听完了，感觉问题好诡异啊。 我们通过HMC登录到分区，AIX运行正常。后来经常一番仔细排查询问找到了"病根".

欢迎大家交流,下面公布原因

#!/bin/sh
su - oracle -c "/home/oracle/stopdb.sh"
echo "Please waitting for 30 seconds..."
sleep 10
su - oracle -c "/home/oracle/stopasm.sh"
/etc/init.cssd stop
/home/oracle/removedev.sh

#!/bin/sh
. /home/oracle/.profile
echo `id`
echo `env|grep ORA`
export ORACLE_SID=scdb
sqlplus '/as sysdba' <

#!/bin/sh
#umount filesystem
fuser -kux /oracle
umount /oracle

#varyoffvg
varyoffvg oralevg

#exportvg
exportvg oralevg

#rmdev
rmdev -dl hdisk10
rmdev -dl hdisk11
rmdev -dl hdisk12
rmdev -dl hdisk13
rmdev -dl hdisk14
rmdev -dl hdisk15
rmdev -dl hdisk16
rmdev -dl hdisk17

确实是脚本里的这行出问题，不是说这行命令有问题，是每次出现这个问题的时候，运维人员说过，有时候执行脚本停止里面有一些报错，为了保证执行成功，他们又执行了一遍。问题就出在这里，本来第一遍执行的时候/oracle已经被成功umount了，第二次执行的时候就不是/oracle文件系统了，而是一个目录，这个时候fuser会把很多root相关的进行直接kill掉，导致我们无法再登录了。

fuser -kux /oracle

这个场景很好模拟，找台测试机，执行2遍，效果自然就显现了。

如何解决呢，通过hmc登录到终端重启ssh进程，startsrc -s ssh.虽说这样能够重新登录,但是里面可能有其他的进程没有被重新启动，最安全的办法还是重启一下分区。