On Fri, 2012-11-30 at 11:14 -0500, Dave Brolley wrote:
> ...
> If this metric and the code which implements it were indeed written by
> Ken, then I think we need some clarification from him regarding the
> original intent before we can come up with the proper solution.
Yep, you can blame me ... 8^)>
As far as I can recall (which is not far when you get to my age), the
original motivation for this was to _cheaply_ collect a metric that
would detect an obscure file descriptor leak problem.
Using the number of open fd would be better than the maximum fd ever if
the maximum is now very large in the NSS/NSPR case.
I don't think iteration with dup() meets the "cheap" requirement.
So provided you have closure of all the places open() and friends are
called (as the current code does) _and_ closure over all the places
close() and friends are called (the current does not do this), then
changing the metric to be "currently open" would be fine. If the IPC
table is already capturing all of the open and close cases, that would
be fine ... my only question would be what happens to the fd uses that
are not related to client-pmcd or pmcd-pmda ipc, e.g. files, pipes to
shells, mmap (including DSOs) ... some of these might be outside the
view of the IPC table but could potentially the source of fd leaks.
|