[ 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. ] Greetings! 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 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 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 problem: * inode and devices use ino_t and dev_t SF#: And I believe this is the relevant change. http://cvs.sourceforge.net/viewcvs.py/psmisc/psmisc/src/fuser.c?r1=1.19&r2=1 .20 So, in short, the upstream psmisc-21.5 does not exhibit this bug. -Martin Version-Release number of selected component (if applicable): How reproducible: Always 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
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 for RHEL3-U5. Thanks Karel, -Martin
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? http://people.redhat.com/kzak/procps/RHEL3/ Thanks!
Karel, 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, -Martin $ rpm -qlp RPMS/i386/procps-2.0.17-13.5.i386.rpm /bin/ps /lib/libproc.so.2.0.17 /sbin/sysctl /usr/bin/free /usr/bin/pgrep /usr/bin/pkill /usr/bin/pmap /usr/bin/skill /usr/bin/slabtop /usr/bin/snice /usr/bin/tload /usr/bin/top /usr/bin/uptime /usr/bin/vmstat /usr/bin/w /usr/bin/watch /usr/doc/procps-2.0.17 /usr/doc/procps-2.0.17/BUGS /usr/doc/procps-2.0.17/NEWS /usr/doc/procps-2.0.17/TODO /usr/man/man1/free.1 /usr/man/man1/pgrep.1 /usr/man/man1/pkill.1 /usr/man/man1/pmap.1 /usr/man/man1/ps.1 /usr/man/man1/skill.1 /usr/man/man1/slabtop.1 /usr/man/man1/snice.1 /usr/man/man1/tload.1 /usr/man/man1/top.1 /usr/man/man1/uptime.1 /usr/man/man1/w.1 /usr/man/man1/watch.1 /usr/man/man5/sysctl.conf.5 /usr/man/man8/sysctl.8 /usr/man/man8/vmstat.8
Ooops... sorry, it's my stupid mistake. It's "psmisc" and not "procps" :-((( http://people.redhat.com/kzak/psmisc/RHEL3/psmisc-21.3-2.src.rpm
Karel, 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 beautifully. # ./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? -Martin
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.
Karel, 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, -Martin
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. Thanks.
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! -Martin
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. http://rhn.redhat.com/errata/RHBA-2005-107.html
*** Bug 143892 has been marked as a duplicate of this bug. ***