[转]python执行系统命令,怎么就卡死了?
最近很忙,术后恢复也很久没有去更新博客了。
来自陌陌安全团队的文章,但是python 执行系统命令popen方法设置了stdout或者stderr,创建子进程把pipe size填满之前没有具体了解,终于知道原因了,也顺手记录一下。
====================================================
title: python执行系统命令,怎么就卡死了?
发生背景
本次问题的发现,主要来源于最近的一个需求,调用第三方工具扫描从gitlab中拉下来项目的依赖信息。其实这个需求要实现的功能比较简单,核心就是在拉下来的项目目录下执行第三方工具,然后读取该工具产生的结果文件,处理后写到回数据库中。
发生过程
该脚本开发完毕后,在经过了单元测试和在测试机器中的完整流程测试后,就在生产环境中上线了。但上线后却发现,扫描任务队列的的数据并没有像预想的那样被消费掉,于是开始检查日志,但并没有发现任何的异常信息。
接着尝试记录更加详细日志进行排错,并在观察中有如下发现:
①并不是所有的任务都会卡死;
②同一个任务第一次执行卡死,第二次重新执行就正常了。
这里我第一个排除掉的原因是当前代码中的逻辑问题,再次仔细观察日志后终于发现了端倪:每次发生的卡死现象都发生在了执行系统命令上,于是开始重点关注命令调用逻辑的代码。
问题分析
下面是问题代码:
由于在之前的脚本中写过不少类似的功能,但大多使用的都是io模块中的os.popen()方法,在新版的python中推荐使用subprocess模块来替代一些旧的模块,于是这次也改成了新的方式,但问题也随之被引入了。
我们先手动调用下这个工具来分析下这个项目的依赖:
https://github.com/momosecurity/mosec-maven-plugin
这个工具的使用也比较简单,具体使用方式可以参考github上的说明,先看看它的输出:
这里需要注意的是,在执行过程中会输出大量的下载信息。
然后我们回到上面的问题代码中,当popen方法设置了stdout或者stderr参数后,系统会创建一个管道用于和子进程进行通信,而上面输出的大量下载信息会把创建的管道填满,进而使得后续的内容无法继续写入管道中,这样整个程序就卡死了。此外这里也没及时读取管道的数据,而是一直等待子进程完成,于是就发生了我们最常见的死锁情况,所以最后的表现就是脚本卡死了。
但是当我们第二次重启脚本运行的时候,由于缓存的存在,使得之前大量的下载信息没有被打印出来,所以这次程序输出的内容少了很多,也就不会把上面的管道填满了。
通过查询我们机器的信息,可以看到当前Linux系统管道的默认大小是4kB(8 * 512B = 4kB),而在第二次调用的时候因为输出的数据明显小于4kB,这才有了第一次卡死,第二次却执行成功的现象。
此外在Python的官方文档*中也在wait方法和stderr属性中做了明确的标注:
当
stdout=PIPE
或者 stderr=PIPE 并且子进程产生了足以阻塞 OS 管道缓冲区接收更多数据的输出到管道时,将会发生死锁。当使用管道时用 Popen.communicate() 来规避它。
警告:
使用 communicate() 而非 .stdin.write, .stdout.read 或者 .stderr.read 来避免由于任意其他 OS 管道缓冲区被子进程填满阻塞而导致的死锁。
问题解决
这里是我们修改后的代码:
![](https://img2022.cnblogs.com/blog/737185/202207/737185-20220719152320376-302822990.png)
虽然官方推荐是使用communicate方法来解决上面的问题,但我们只是为了获得输出,并尽可能的避免其他可能发生的问题,就直接使用check_output方法来替代。此外我们还可以看到,在check_output方法中也确实使用了communicate:
总结
为了实现某个功能,我们最常见方式就是在网上搜出来一些代码,然后不经思考就直接粘贴复制到我们的项目中,但这可能会隐藏很多难以发现的问题。这时候最好的方式就是确定好代码中的每一个方法有没有问题,尤其是对于不熟悉的方法,好好看看官方的文档,或许会有意想不到收获。
参考
[*] Python官方文档 https://docs.python.org/zh-cn/3.7/library/subprocess.html
来源:
https://mp.weixin.qq.com/s/CJK-_yMo_VN1_yIUiO787w