Bug 144039
Summary: | inodes > $MAX_32_BIT_INT not found by fuser (fixed upstream) | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 3 | Reporter: | Martin A. Brown <mabrown-redhat> |
Component: | psmisc | Assignee: | Karel Zak <kzak> |
Status: | CLOSED ERRATA | QA Contact: | Ben Levenson <benl> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 3.0 | CC: | rvokal |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2005-05-20 03:25:48 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 132991 |
Description
Martin A. Brown
2005-01-03 23:28:20 UTC
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. *** |