[PATCH] ev: fix epoll_init fd leak

Brandon Black blblack at gmail.com
Wed Nov 2 15:43:56 CET 2011

On Wed, Nov 2, 2011 at 6:58 AM, Christian Parpart <trapni at gentoo.org> wrote:
> I do think a little bit different here. Think of a server app. The app:
> 1.) first reads config file,
> 2.) populates internal data structures out of it,
> 3.) cleans up its environment (including closing inherited fds, including
> 0,1,2)
> 4.) initializes its own subsystem, including epoll_create(libev) and its
> own log targets and listener sockets
> 5.) runs the loop until exit.
> This is not a bad behaviour.
It is arguably bad behavior.  You shouldn't be just closing 0/1/2 as part
of your daemon init, you should be re-opening them on /dev/null if you have
nothing more interesting to do with them (arguably, connecting fd#2 to some
mechanism for capturing error output from other libraries might be more
robust, but if you want to ignore any stderr generated by other code that's
fine too).

Here's the first random hit I got on google showing an example of using
freopen() to do this during daemon init.  Countless other examples exist,
and most real-world daemons do something similar with regard to 0/1/2:

p.s.: you wanted a software-example, well, I once worked at a company where
> resources (like fds)
> and high performance where treated very precise, keeping fds around for
> nothing would have been
> a joke, though, sure, you might work around libev's behaviour.
Keeping 3 whole fds around pointed at /dev/null is pretty common practice,
and isn't going to affect your performance, that's just silly premature

-- Brandon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.schmorp.de/pipermail/libev/attachments/20111102/ffd430ba/attachment.html>

More information about the libev mailing list