嵌入式C语言开发：文件描述符(fd)泄漏排查（经验分享）

大家好，今天给大家介绍文件描述符(fd)泄漏排查，文章末尾附有本毕业设计的论文和源码的获取方式，可进群免费领取。

生产多次遇到文件描述符（fd）泄露相关的问题，文件描述符泄漏一般引起
的现象是文件句柄数（封面图）/tcp alloc（上图）增长。文章分为两部分介绍文件描述符相关内容，第一部分介绍文件描述基础知识，第二部分通过实际案例进行剖析。

一. 文件描述符相关基础知识

什么是文件描述符？
内核利用文件描述符来访问文件, 打开现存文件或新建文件（建立）时，内核会返回一个文件描述符，读写文件也需要使用文件描述符来指定待读写的文件。所有执行I/O操作(包括网络socket操作)的系统调用都通过文件描述符
最大文件描述符介绍系统最大文件描述符限制
sysctl -a | grep fs.file-max （查看系统最大描述符）echo “fs.file-max=1610270” >> /etc/sysctl.conf（修改最大描述符）sysctl -p（立即生效）用户级最大文件描述限制ulimit -n （查看用户最大描述符）echo “* hard nofile 65535” >> /etc/security/limits.confecho “* soft nofile 65535” >> /etc/security/limits.conf代表所有用户，支持具体用户（优先级高，不受影响）。文件修改即生效，退出
或打开新终端执行ulimit -n即看到修改效果具体某个进程（PID）最大描述符通过cat /proc/PID/limits | grep “Max open files”Limit Soft Limit Hard Limit UnitsMax open files 65536 65536 files进程最大描述符受限与系统／用户级，以及进程本身相关代码程序限制，比如下面Golang代码将进程打开的最大描述符限制为10var rLimit syscall.RlimitrLimit.Cur = 10if err := syscall.Setrlimit(syscall.RLIMIT_NOFILE, &rLimit); err != nil {panic(err)}

二. 文件描述符泄漏的实际案例

某个周末，ops同学在运维群反馈某核心业务应用文件描述符以及tcp alloc非常高，导致服务不可用（这块监控不到位）。业务架构同学为了排查相关问题具体原因保留了一台问题服务，当然咯，闲着无事，参与线上故障排查。从监控图看到文件描述符不断/tcp alloc 不断增长

 netstat -tan|awk '$1~/tcp/{print $NF}'|sort|uniq -c|sort -nr 156 TIME_WAIT 141 FIN_WAIT2 80 ESTABLISHED 10 LISTEN 3 CLOSE_WAIT 2 LAST_ACK

通过lsof 相关信息我们找不出具体由于某原因导致的，我们通过strace查看系统调用，查看fd泄漏的具体原因（抓取5分钟）
strace -f -p 4730 -T -tt -o /home/futi/strace_4730.log-tt 在每行输出的前面，显示毫秒级别的时间-T 显示每次系统调用所花费的时间-v 对于某些相关调用，把完整的环境变量，文件stat结构等打出来。-f 跟踪目标进程，以及目标进程创建的所有子进程-e 控制要跟踪的事件和跟踪行为,比如指定要跟踪的系统调用名称-o 把strace的输出单独写到指定的文件-s 当系统调用的某个参数是字符串时，最多输出指定长度的内容，默认是32个字节-p 指定要跟踪的进程pid, 要同时跟踪多个pid, 重复多次-p选项即可。tomcate多线程应用，我们需要追踪子进程运行情况，所以-f，其它参数大家看解析应该可以理解

/home/futi/strace_4730.log，找到strace抓取这段时间内最近泄漏的fd进行分析，通过lsof -d 49959 ，可以看到出现Prtocol：TCP异常情况。下面截一小部分内容前面有大量对fd为49959打开，关闭等操作。但从4783线程操作这个fd以后strace抓取的内容未有再使用49959这个fd，且fd 不断增大，有使用大于49959的fd，所以我们可以断定是这个fd 在这块出了问题。