libuuid's gen_uuid.c:get_clock() goes to some length to try to reuse its fd and avoid repeated opens of /var/lib/libuuid/clock.txt and also to be thread safe. But the current implementation must lead to fd leakage in multithreaded applications. This has been reported multiple places as the gen_uuid.c file seems to have been reused in various open source projects. But I don't see mention of this issue in the util-linux archives. Some mentions I've found: http://sourceforge.net/tracker/index.php?func=detail&aid=3276476&group_id=2406&atid=102406 https://github.com/samuel/python-gearman/pull/3 And it's come into my lap by way of some complicated Java application I can't claim to understand, but they error on too many open files and note via lsof that opens of clock.txt grow unbounded during their runtime. While googling around I also noticed the C++98 spec (well maybe anyway...as referenced here: http://gcc.gnu.org/onlinedocs/gcc-4.6.1/gcc/C_002b_002b98-Thread_002dLocal-Edits.html#C_002b_002b98-Thread_002dLocal-Edits) includes the idea that things in TLS shouldn't have non-trivial destructors. Shows at least that somebody's thought about the problem. I'd guess having to have something know to do fclose() / close() on parts of the TLS counts as non-trivial and shouldn't be done. The sourceforge.net link above includes a number of suggested options. And there's also just the simple implementation option for get_clock() that doesn't have the fd as static much less TLS and opens/closes at each invocation. That maybe comes with a noticable performance hit for some types of users and I don't really know the full list of possible use cases here...do some people really need that high performance uuid generation? Either way, the "right" general solution isn't immediately obvious to me so I thought I'd see what others here thought... Tim -- To unsubscribe from this list: send the line "unsubscribe util-linux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html