背景：
国产化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值）
标签：0022,web,容器,umask,升级,sh,644,权限 From： https://www.cnblogs.com/lihao007/p/18368298