Bug 144039 - inodes > $MAX_32_BIT_INT not found by fuser (fixed upstream)
Summary: inodes > $MAX_32_BIT_INT not found by fuser (fixed upstream)
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: psmisc   
(Show other bugs)
Version: 3.0
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Karel Zak
QA Contact: Ben Levenson
Depends On:
Blocks: 132991
TreeView+ depends on / blocked
Reported: 2005-01-03 23:28 UTC by Martin A. Brown
Modified: 2007-11-30 22:07 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-05-20 03:25:48 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2005:107 normal SHIPPED_LIVE psmisc bug fix update 2005-05-19 04:00:00 UTC

Description Martin A. Brown 2005-01-03 23:28:20 UTC
[ Note that this was filed initially under 143892 on 2004-12-31, but
  somehow that bug number contains g++ data.  Note that the bugzilla
  query engine shows the fuser/inode bug number and subject as
  initially entered.  Sorry for duplicate, but I now have no idea
  what else to do. ]


From /proc/net/tcp, one can see that there is an open (and listening)
tcp/25 socket:

   3: 00000000:0019 00000000:0000 0A 00000000:00000000 00:00000000
00000000     0        0 2216815516 1 f7ff4400 300 0 0 2 -1

Note the inode number is 2216815516, which is greater than 2147483647.

Interestingly, netstat reports the socket with inode $MAX_32_BIT_INT
instead of the real inode number.   This is not a show-stopper--at
least netstat reports the socket exists, though it cannot report any
process information (netstat -ntlepa).

tcp        0      0    *              
LISTEN      0          2147483647 -

fuser (from psmisc), reports nothing

# fuser -n tcp 25              # -- system fuser (RHEL supplied)
# ./fuser-21.3 -n tcp 25       # -- vanilla package
# ./fuser-21.4 -n tcp 25       # -- vanilla psmisc-21.4 works
here: 25                       #    with funny extra message
25/tcp:               2328
# ./fuser-21.5 -n tcp 25       # -- works as expected
25/tcp:               2328

I think this is the comment from the ChangeLog which identifies this

        * inode and devices use ino_t and dev_t SF#:

And I believe this is the relevant change.


So, in short, the upstream psmisc-21.5 does not exhibit this bug.


Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Run a box for a long time with lots of processes (particularly
   socket-using processes).
2. Wait until the kernel uses inodes greater than $MAX_32_BIT_INT.
3. Bind a socket on a $PORT of your choice.
4. fuser -n tcp $PORT

Comment 3 Karel Zak 2005-01-05 08:08:13 UTC
In CVS prepared for RHEL3-U5.

Comment 4 Martin A. Brown 2005-01-05 19:15:08 UTC
Since this bug now has a dependency on 132991, I would like to be
added to the CC list on that bug.  Right now, I am unable to view the bug.

I appreciate your quick turnaround on preparing the updated package
for RHEL3-U5.

Thanks Karel,


Comment 5 Karel Zak 2005-01-06 09:35:20 UTC
The bug 132991 is a "RHEL3 U5 Tracking Bug" -- it means list of bugs
which should be fixed in U5. It's nothing exactly connected with the
problem that you reported. Don't worry that it's hidden your you :-)

But there's something other -- we have a problem found in RH computer
with so big inode numbers as you have at your machine. Martin, can you
test the fixed "fuser" at your computer?



Comment 6 Martin A. Brown 2005-01-06 15:55:16 UTC

I grabbed the SRPM at the indicate URL, rebuilt it (procps, he asks
himself?) and used rpm -qlp to list the files included in the package.

As I guessed, there was no "fuser" binary in this package.  Let me
know where I can fetch the psmisc SRPM, and I'll give it a try.

Could you give me a bit more detail about the problem you have found
with the large (socket) inode numbers?

Thank you,


$ rpm -qlp RPMS/i386/procps-2.0.17-13.5.i386.rpm

Comment 7 Karel Zak 2005-01-06 16:38:05 UTC
Ooops... sorry, it's my stupid mistake. It's "psmisc" and not "procps"


Comment 8 Martin A. Brown 2005-01-06 16:58:13 UTC

Here's the one I had used before (just for comparison).

# ./fuser-21.5  -n tcp 25
25/tcp:               2328

Here's the one compiled from your SRPM--it looks good and works

# ./fuser-RHEL-U5  -n tcp 25
25/tcp:               2328

You alluded to a problem with the large inode numbers (the 'long long'
numbers).  Could I reiterate my request for a bit of information on
what you have discovered?


Comment 9 Karel Zak 2005-01-06 21:14:52 UTC
Thanks for your tests. 

I backported some code from lates fuser version. The new code works
more careful with inode and device numbers -- it's better use ino_t
and dev_t datatypes everywhere in code. I think for exact description
you can see the patch psmisc-21.3-devtype.patch in the srpm package.

Comment 10 Martin A. Brown 2005-01-06 21:36:45 UTC

In comment #5 above, you said the following:

 : But there's something other -- we have a problem found in RH
 : computer with so big inode numbers as you have at your machine.

This comment leads me to believe that there's an additional problem
with big inode numbers.  Is there another problem with big inodes?  I
understood that the patch I pointed out from the sourceforge.net CVS
repository changed the size of storage allocated to be ino_t and dev_t
instead of another C type (long, I think).

I am simply curious if there is another bug here--your comment
suggested to me that there was another problem.

I'm also curious to know if you'll be fixing net-tools (netstat
displays a similar behaviour).   Or will somebody else patch net-tools
to show the extended information?

Thank you for your assistance, Karel,


Comment 11 Karel Zak 2005-01-07 08:24:50 UTC
I don't think there's an additional problem with inode numbers --
kernel support it in this size. Our box is probably more busy than our
RH test boxes;-) It's nothing abnormal that a problem is possible
reproduce at customers machine only.

The net-tools maintainer already knows about it. I add him to CC: --
maybe he will ask you for tests too.


Comment 12 Martin A. Brown 2005-01-07 18:27:24 UTC
OK!  Karel, thank you--I think I understand a bit better what you meant.

I appreciate your reply, and I look forward to hearing about the
patch/fix to the net-tools package.

Best regards and thank you very much!


Comment 13 Dennis Gregorovic 2005-05-20 03:25:48 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


Comment 14 Karel Zak 2005-08-04 13:52:11 UTC
*** Bug 143892 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.