Issue #1947 has been updated by daniel.
Is there *ever* a case that puppet wants a file descriptor it opens inherited by a child process? The right solution is to use O_CLOEXEC or FD_CLOEXEC on the file descriptor. This probably involves overriding the core File / IO methods, since we otherwise rely on all module implementors (A) knowing about the issue, and (B) getting it right. http://www.ruby-doc.org/stdlib/libdoc/fcntl/rdoc/index.html @ File.new("/tmp/example") File.new("/tmp/test").fcntl(Fcntl::F_SETFL, Fcntl::FD_CLOEXEC) @ Season to taste for other methods of obtaining a file descriptor, of course. (Windows, naturally, doesn't support FD_CLOEXEC, but does support O_INHERITABLE which can be managed through the platform API only, god love 'em.) ---------------------------------------- Bug #1947: Puppet still leaks FDs on exec http://projects.reductivelabs.com/issues/1947 Author: nwp Status: Accepted Priority: Normal Assigned to: Category: exec Target version: Complexity: Unknown Affected version: 0.24.7 Keywords: Puppet still leaks FDs on exec. This can be when restarting a "service" resource or running an "exec" resource; anything that uses util.rb's functions to actually do the exec. The line "3.upto(256){|fd| IO::new(fd).close rescue nil}" (introduced in 0.24.6 I believe) is not adequate; FDs numbered above 256 remain open. I now have hosts failing in the middle of puppet catalog runs due to running out of FDs. Looking at one of the services that gets regular puppet-controlled restarts, it has FDs 1-13, and 257->985 open. Restarting it manually makes the problem go away. Actually knowing which FDs are in use (for communication with the puppetmaster in particular, but also anything else that I haven't yet noticed) and closing them would probably fix the problem completely; iterating over FDs in the hope that the system you are on doesn't happen to allow higher-numbered ones and hasn't been using them if it does, is not a good solution. ---------------------------------------- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://reductivelabs.com/redmine/my/account --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en -~----------~----~----~----~------~----~------~--~---
