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,对于这个问题也没有更多的帮助。实在古怪了。 最后这个问题被解决了,但原因还是没找到,解决的方法估计你们也能猜出来了:重启服务器。这是我能想到的唯一的,可能行得通的解决方案。结果还真奏效了。 高人说:相信你还会遇到这个问题的。我说:墨菲定律,对么? 这个问题,虽然花费了半天时间,最后还是没找到原因,但学到了些新技能,也不算太亏。


标签: Linux, 服务器, 脚本, script, 问题, denied, Permission, 执行, sh

相关文章推荐

添加新评论,含*的栏目为必填