[ 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)
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 0.0.0.0:25 0.0.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
# ./fuser-21.5 -n tcp 25 # -- works as expected
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):
Steps to Reproduce:
1. Run a box for a long time with lots of processes (particularly
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
In CVS prepared for RHEL3-U5.
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
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?
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?
$ rpm -qlp RPMS/i386/procps-2.0.17-13.5.i386.rpm
Ooops... sorry, it's my stupid mistake. It's "psmisc" and not "procps"
Here's the one I had used before (just for comparison).
# ./fuser-21.5 -n tcp 25
Here's the one compiled from your SRPM--it looks good and works
# ./fuser-RHEL-U5 -n tcp 25
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?
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.
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,
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.
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!
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.
*** Bug 143892 has been marked as a duplicate of this bug. ***