Microsoft research: A fork() in the road
Microsoft research: A fork() in the road
Posted Apr 11, 2019 5:32 UTC (Thu) by mm7323 (subscriber, #87386)In reply to: Microsoft research: A fork() in the road by epa
Parent article: Microsoft Research: A fork() in the road
One thing this can break is Valgrind, which creates some high numbered descriptors above the normal ulimit(). By testing the ulimit you can avoid closing these. Other libraries and tools may not be so lucky though, so an O_NOCLOEXEC maybe better, and it's actually a O_NOCLOFORK that would be best.
Posted May 31, 2021 17:44 UTC (Mon)
by immibis (subscriber, #105511)
[Link]
What if opening /proc/self/fds fails because too many FDs are open? Okay, then you just close FD 0. But you actually need that one. So close FD 3 instead. You're closing all the FDs, right - so it doesn't matter if you close one prematurely?
What if FD 3 is on your do-not-close list? Okay, just pick the lowest number that isn't.
What if there are too many FDs and they're all really high numbers? Scan the whole 32-bit or 64-bit FD space until you manage to close one, then open /proc/self/fds? (they can be higher than your RLIMIT_NOFILE, if RLIMIT_NOFILE was set to a larger number in the past)
What if your RLIMIT_NOFILE is zero? Then you can't open /proc/self/fds. But there is nothing to close. But will you detect that and succeed instead of failing?
Actually, there could be open FDs from before RLIMIT_NOFILE was set to zero. Will you temporarily increase it, so you can open /proc/self/fds?
What if /proc isn't mounted? This is actually very likely to come up, IF your code is ever used in a program that creates containers, or perhaps even just from a rescue shell.
Wouldn't it be great if you could *just tell the kernel to do the thing you want it to do*?
Microsoft research: A fork() in the road
