我有兴趣通过分配大量文件描述符并导致Out-of-File-Descriptor失败来关闭系统（例如15分钟）。 （别担心，我不是想破解任何东西。这是为了测试我正在编写的服务......看看它在其他程序行为不当的情况下。）任何最佳实践？我应该继续在无限循环中说fopen（）吗？ 15分钟后，我可以杀死这个过程吗？有没有人有这方面的经验？
更新：我正在运行Linux，我正在编写的程序将拥有超级用户权限。
谢谢， 〜瑜珈
答案 0 :(得分：2)
您是否考虑在运行程序之前使用setrlimit RLIMIT_NOFILE降低文件描述符限制？
这可以使用bash ulimit -n内置，在您测试应用程序的同一个shell中完成，例如：
ulimit -n 32
它不会扰乱很多已经运行的其他服务。降低该限制将使您的应用程序（在相同的shell中运行）快速受损（为了您的测试目的）。
在整个系统级别，您也可以写入/proc/sys/fs/file-max，例如与
echo 1024 > /proc/sys/fs/file-max
答案 1 :(得分：0)
取决于操作系统的实现，但是从同一个进程调用同一个文件的fopen将不会分配新的文件描述，而只是增加引用计数器。
我建议您阅读有关stress testing
的内容以下是一些可用的软件（您没有标记任何OS平台）：
答案 2 :(得分：0)
我在正常使用中曾经发生这种情况。我相信你在linux中运行inode。我不知道打开文件的更快捷方式。小心点，我们锁定了系统。不久之前，所以我不记得试图打开文件的是什么，但事情通常认为它们可以获得文件句柄，并且在它们不能的情况下表现不尽如人意。 〜奔
答案 3 :(得分：0)
我的2美分：
1.编写一个创建大量文件描述符的程序。您可以通过以下方法之一来实现它：
（a）在您的代码中打开许多不同的文件
（b）打开许多套接字描述符
（c）创建大量线程
2.现在，继续使用shell脚本或类似的东西生成在Step-1中创建的程序的多个实例（即创建多个进程）。
注意： 在linux以及大多数其他操作系统中，每个进程的文件描述符数量有限制（默认情况下，我认为它是1024.你可以使用ulimit -a来检查它）。所以，当你这样做时，你的过程就会失败。我真的不太确定只需增加文件描述符的使用次数就可以使系统停机。
答案 4 :(得分：0)
您可以使用mkstemp获取临时文件的文件描述符。