踩过的坑（一）——web容器升级

背景：

国产化web容器(宝兰德)升级。

 

踩坑过程：

web容器升级后，web系统正常访问，看似正常。晚上批量跑批的时候，中断了。

中断原因：发现某路径下的文件，的确存在，但是程序报NoSuchFileException。

调查得知，现在该文件的权限是640（linux），想定应该是644。其他用户组的read权限缺失，导致文件不可读（也就是读取不到）。

项目启动脚本中，有umask 0022。

（默认情况下的umask 0022 ，为了控制默认权限，使得默认文件和目录不会具有全部权限。umask 0022 文件的默认权限是644，目录默认权限是755）

经过分析，以前执行脚本 umask 0022 赋的权限是644，那么却现在赋成了640。

那么，为什么会出现这个状况？

sh test.sh 原因在于此。

sh 命令执行后面的shell时，会另起一个新的子进程。这时，宝兰德容器内部为了安全性的考虑会默认设置640的权限。

改法：

sh test.sh 改成 source test.sh （source 命令在当前shell进程中执行指定的脚本，并将命令和变量导入到当前shell环境中，这就意味着外面的umask 0022的作用会影响到test.sh的运行环境，使得umask值644）

 

当时这个方案确定后，我组织人力批量修改。但是还有人改漏了，出了生产问题。

复盘：

1.reviewer 没细看代码导致问题带出

复合代码人必须逐步检查。

2.自己写的代码，自己检查。常常发现不了问题。

要进行交叉检查。A写的代码，B去检查。B写的代码，A去检查。

3.测试环境下的变量值，与生产不一致。

后续要保证一致，避免出错。

4.开发人员改了10处。那么发现一处改错了，要确认好其余9处是否有同样问题。切记！！！

（完）

 

附：

cat proc / 进程id / status  命令 （查看某进程下的umask值）