Linux实现打开的文件描述符C
1)为了获得打开的文件描述符的总数,是否可以循环使用/proc
? 我用下面的显示目录:Linux实现打开的文件描述符C
/proc/PID/fd/*
/proc/PID/maps
/proc/PID/cwd
/proc/PID/root
/proc/PID/exe
2)的数目不同于lsof | wc -l
和cat /proc/sys/fs/file-nr
3)加载动态链接库和当前工作目录可以算作打开文件描述符? 实现在C中的所有打开的文件描述符的Linux
你怎么指望这取决于你是什么样的信息感兴趣。
通过/proc/PID/fd/*
展望会给你打开的文件描述符的数量。但是,有一点需要注意的是,两个进程可能实际上共享一个文件描述符,如果分叉,那么子进程会从其父进程继承文件描述符,然后此方法将计算两次,每个进程计数一次。
/proc/PID/maps
将向您显示进程的内存映射,其中可以包括加载的可执行文件本身和动态链接的库,但也包括与堆,堆栈,vdso
节等文件不对应的内容内核导出的虚拟共享对象,等等。
lsof
将列出文件可以使用的各种方式,其中不仅包括文件描述符,它也包括可执行文件和共享库,但不包括不对应于在/proc/PID/maps
像栈,堆vdso
部显示的文件存储区域等
/proc/sys/fs/file-nr
将报告数量不限内核文件句柄。内核文件句柄不同于文件描述符;可以有多个文件描述符打开,指向相同的文件句柄,例如通过调用dup
或dup2
。
这些差异可以解释为什么从这些不同的计数方式中获得不同的数字。问题是,你使用这个计数的目的是什么?这将有助于回答您应该实际使用哪种计数方式。
1)没有,但似乎你都搞不清楚是什么构成一个打开的文件描述符,通过你的第二个问题
2)看http://codingtragedy.blogspot.com/2015/04/nofile-ulimit-n-rlimitnofile-most.html的建议 - 虽然它解释了对似乎不相关的资源限制的处理,它还解释了文件描述符与最有可能需要的“结构文件”之间的区别,它甚至涵盖了您的使用情况。
3)同样,目前还不清楚你的实际问题是什么。当前工作目录不是文件描述符,并且只用inode表示。一个进程可能会或可能不会为链接库保留fd,但映射本身占用一个“结构文件”。
谢谢你的回答,非常丰富。目的是监视打开的文件描述符,据我所知,我不需要查看映射和文件nr。 – Adelina