2021-08-05   中午时候，同事说我们一台生产环境服务器的程序发布遇到了问题，一直发布不上去。   发布程序到生产环境，我是用一个脚本来做的，我们在管理界面上操作一下，间接地会触发一个服务器的脚本，由这个脚本来执行发布动作。   我迅速ssh到生产环境服务器，手动运行脚本，出现了熟悉的Permission denied。   “靠！谁到生产环境改了脚本的执行权限？”——这是我的第一反应。   但很快我就发现脚本具有“x”权限，反复确认我没看错后，我尝试用root去执行，问题依旧，有些奇怪了。   我编写了一个极简单的脚本，里面只有一条“ls”命令，加上“x”权限，执行它，嗯？一样的Permission denied。看来不是脚本内容的问题。   我检查了我cron定时任务的日志，发现这个问题是前天开始出现的，我开始找人，看谁前天上过服务器做过什么事情，同事都说没有。我再通过history查询服务器的命令执行情况，发现除了当天我做的动作之外，就是好几个星期前的事情了，真没人上过这台服务器。——更奇怪了。   这问题的难度还在于在网上只能找到最普通的回答：用chmod啊！——显然我这里不是这个问题。   接着我发现，是所有的脚本都无法执行。但二进制执行文件却没问题。   再接着研究我发现脚本可以这样执行：

$sh ./my_script

间接的用shell就能执行！我有点方向了，后来在网上找到了这个：https://unix.stackexchange.com/questions/136547/what-is-the-difference-between-running-bash-script-sh-and-script-sh

这个帖子讨论了 ./script.sh 和 bash ./script.sh的不同，我了解了，但对解决我的问题帮助不大。   再就是这个：https://unix.stackexchange.com/questions/203371/run-script-sh-vs-bash-script-sh-permission-denied   这是个比较全面的讨论Permission Denied的帖子。其中提到了磁盘挂载的时候如果带有“noexec”参数，就会导致这个问题，这跟我遇到的情况简直就是一模一样。遗憾的是，我仔细检查了我的/etc/fstab，以及当前挂载的情况，并无“noexec”参数。我继续尝试了在不同的挂载点上执行脚本，都是一样的结果。   另外这个帖子还提到了ACL，可以使用命令getfacl来检查对一个文件的访问控制，我这里也没发现任何问题。   检查用户/组，没有发现任何问题。   于是请教高人。高人说给出了几个建议：   1，脚本头部加上解释符“#/bin/sh”——试了，问题依旧 2，检查磁盘空间是否满了 —— 检查了，远没满 3，使用strace跟踪脚本的运行情况    strace打印了很详细的信息，但遇到系统调用就直接Permission denied，对于这个问题也没有更多的帮助。实在古怪了。   最后这个问题被解决了，但原因还是没找到，解决的方法估计你们也能猜出来了：重启服务器。这是我能想到的唯一的，可能行得通的解决方案。结果还真奏效了。   高人说：相信你还会遇到这个问题的。我说：墨菲定律，对么？   这个问题，虽然花费了半天时间，最后还是没找到原因，但学到了些新技能，也不算太亏。