|
|
Subscribe / Log in / New account

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

I've actually implemented something like that in the past - you can scan /proc/self/fds and generally call close() on what you find there.

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.


to post comments

Microsoft research: A fork() in the road

Posted May 31, 2021 17:44 UTC (Mon) by immibis (subscriber, #105511) [Link]

I recall already seeing this approach. But it has so many moving parts compared to just telling the kernel to do what you want.

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*?


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds