Linux下文件描述符继承以及数量上限所引发的问题

Linux下文件描述符继承以及数量上限所引发的问题

1、问题描述

最近遇到了一个很经典的问题，测试对产品进行压力测试更新固件500次，连续下载不到500次会出现应用启动失败的情况。经过分析是文件描述符继承以及数量上限所引发的问题。

2、原理分析

固件更新流程

在第三步中，通过应用程序启动脚本，然后再通过脚本启动应用程序，会出现文件描述符被继承的关系，即使脚本中对应用程序进行了kill，最终出现进程中文件描述符被占用完。
例：
应用如下，其编译名称为testsh：

在此应用中启动脚本 shtest.sh，脚本中的内容如下：

启动后，通过cat /proc/pid号/fd可查看这两个进程分别所具体的fd如下:

可以看到，4被启动的脚本进程所继承。
这个问题的本质是在应用程序中执行system函数，其实是创建了一个子进程去执行命令，创建子进程会复制父进程的资源。但是如果正常执行system后还有代码执行则会回收子进程，若像上述例子一样执行完毕直接return,则需要在执行system前将没有用的文件描述符关闭下，防止被子进程继承从而出现套娃现象。

3、关闭方式：

1.c++中使用QProcess::startDetached启动shell。该方式启动应用前会关闭一些资源。
2.c语言中利用exec函数簇。

4、关于文件描述符的个数

Linux配置系统最大打开文件描述符个数
（1）系统级限制

理论上系统内存有多少就可以打开多少的文件描述符，但是在实际中内核是会做相应的处理，一般最大打开文件数会是系统内存的10%（以KB来计算），称之为系统级限制。这个数字可以通过 cat /proc/sys/fs/file-max 或者 sysctl -a | grep fs.file-max 命令查看。

更改系统级限制有临时更改和永久更改两种方式：

临时更改：session断开或者系统重启后会恢复原来的设置值。使用命令 sysctl -w fs.file-max=xxxx，其中xxxx就是要设置的数字。

永久更改：vim编辑 /etc/sysctl.conf 文件，在后面添加 fs.file-max=xxxx，其中xxxx就是要设置的数字。保存退出后还要使用sysctl -p 命令使其生效。

（2）用户级限制

同时为了控制每个进程消耗的文件资源，内核也会对单个进程最大打开文件数做默认限制，即用户级限制。32位系统默认值一般是1024，64位系统默认值一般是65535，可以使用 ulimit -n 命令查看。

更改用户级限制也有临时更改和永久更改两种方式：

临时更改：session断开或者系统重启后会恢复原来的设置值。使用命令 ulimit -SHn xxxx 命令来修改，其中xxxx就是要设置的数字。

永久更改：vim编辑 /etc/security/limits.conf 文件，修改其中的 hard nofile xxxx 和 soft nofile xxxx，其中xxxx就是要设置的数字。保存后退出。关于hard和soft的区别，参照下面参考链接中的第5个。

参考：
https://blog.csdn.net/yushuaigee/article/details/107883964