passenger's modification to libeio

Hongli Lai hongli at phusion.nl
Thu Apr 23 12:02:11 CEST 2015


Hi Marc, Orion.

The reason for introducing these changes is for the purpose of
debugging file descriptor leaks in Passenger. There have been several
instances of file descriptor leaks inside Passenger in recent history.
The 'lsof' tool allows us to see that there is a file descriptor leak,
but the tool doesn't tell us what the file descriptors are for. So in
order to trace leaks to their origin, we need some kind of accounting
system, which is what that Github commit introduced. Based on the logs
for opening and closing file descriptors, and based on extra logs that
tell us what purpose each file descriptor serves (e.g. "file
descriptor 45 is the socket for server client 62"), we can get a
complete overview of which file descriptors are open, why, and where
they were created, in order to make file descriptor leak debugging
easier.

On Thu, Apr 23, 2015 at 1:21 AM, Marc Lehmann <schmorp at schmorp.de> wrote:
> On Wed, Apr 22, 2015 at 03:31:30PM -0600, Orion Poplawski <orion at cora.nwra.com> wrote:
>> phusion passenger 5.0.6 ships a modified libeio 4.15.  Fedora builds it
>> against system libeio, so this fails due to missing symbols.  The full diff is:
>
> This is a diff against libev, not libeio btw.
>
> It's possible that these hacks work for passenger and the platforms it
> supports, in which case it would need to be built with its custom version
> as standard libev doesn't expose these internal values.
>
>> Changes appear to be part of this commit:
>
> If this is all, then these hacks are indeed only used to provide extra
> logging information. Personally, I don't quite see why anybody would want
> to log these fds, certainly not at the cost of breaking compatibility with
> the standard version of libev, but the passenger authors are certainly
> allowed to create their own custom libev version for that.
>
> (One can log these values without modifying the libev sources as well, but
> it would sitll need to be embedded for that).
>
>> Which allows for some additional logging of fd opening/closing.  I know
>> nothing about the motivation for this change, but I'm wondering if this would
>> be accepted by libev?
>
> I have no clue why anybody would want to log these fd numbers, especially as
> they can change without notice. On the other hand, I can see how exposing
> these values leads to some people using them, which would break down as
> these fds are not always available, and the patches don't have a way of
> notifying user code when an fd has changed.
>
> For these patches to be accepted in libev, there would need to be a
> reason, and at the moment, there are only reasons against this.
>
> --
>                 The choice of a       Deliantra, the free code+content MORPG
>       -----==-     _GNU_              http://www.deliantra.net
>       ----==-- _       generation
>       ---==---(_)__  __ ____  __      Marc Lehmann
>       --==---/ / _ \/ // /\ \/ /      schmorp at schmorp.de
>       -=====/_/_//_/\_,_/ /_/\_\
>
> _______________________________________________
> libev mailing list
> libev at lists.schmorp.de
> http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev



-- 
Phusion | Web Application deployment, scaling, and monitoring solutions

Web: http://www.phusion.nl/
E-mail: info at phusion.nl
Chamber of commerce no: 08173483 (The Netherlands)



More information about the libev mailing list