Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 235205 - lsof do not show files with link count less than 1 anymore
Summary: lsof do not show files with link count less than 1 anymore
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: lsof
Version: 4.4
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: Karel Zak
QA Contact: Brock Organ
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-04-04 14:40 UTC by Peter Bieringer
Modified: 2007-11-17 01:14 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-05-31 09:51:04 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Peter Bieringer 2007-04-04 14:40:42 UTC
Description of problem:
After updating system libraries like e.g. krb5-libs I use lsof to detect library
files with link count less than 1. This works for RHEL3, but no longer for RHEL4.

Version-Release number of selected component (if applicable):
lsof-4.72-1.4 (RHEL4)
lsof-4.78-3 (FC6)

Last known working
lsof-4.63-4.1 (RHEL3)


How reproducible:
After each system library update.

Steps to Reproduce:
1. update a system library
2. run following lsof command:
# /usr/sbin/lsof +L1 | /bin/egrep -w "txt|mem" | /bin/grep -v " /SYSV"
  
Actual results:
No result

Expected results:
Something like on RHEL3:
# /usr/sbin/lsof +L1 | /bin/egrep -w "txt|mem" | /bin/grep -v " /SYSV"
sshd       7162    root mem    DEL    8,1          0 456184
/usr/kerberos/lib/libgssapi_krb5.so.2.2;4613b37a
sshd       7162    root mem    DEL    8,1          0 456377
/usr/kerberos/lib/libcom_err.so.3.0;4613b37a
sshd       7162    root mem    DEL    8,1          0 456280
/usr/kerberos/lib/libk5crypto.so.3.0;4613b37a


Additional info:
Is this a bug introduced with lsof version 4.7x or is this a well known behavior
change?

On RHEL4 and FC6 I had to use following grep command instead:

# /usr/sbin/lsof |grep "path inode="
sshd       3049    root  mem       REG        8,2               164919
/usr/lib/libkrb5.so.3.2 (path inode=164904)
sshd       3049    root  mem       REG        8,2               164909
/usr/lib/libk5crypto.so.3.0 (path inode=164908)
sshd       3049    root  mem       REG        8,2               164905
/usr/lib/libgssapi_krb5.so.2.2 (path inode=165216)

Is there an lsof option which supersets this grep?

Comment 1 Karel Zak 2007-05-31 09:51:04 UTC
on FC6, lsof-4.78-3:

# lsof +L | grep libslang
mc        20791      kzak  mem       REG              253,0   911464     1     
        1337214 /usr/lib64/libslang.so.2.0.7

# cp /usr/lib64/libslang.so.2.0.7 /usr/lib64/libslang.so.2.0.7.org
# rm -f /usr/lib64/libslang.so.2.0.7

# lsof +L1 | grep libslang
(nothing)

# /usr/sbin/lsof +L | grep libslang
mc        20791      kzak  DEL       REG              253,0                    
        1337214 /usr/lib64/libslang.so.2.0.7

.. "+L" doesn't report zero as NLINK, there is empty space only. The lsof
reports deleted files by the "DEL" in TYPE field. 

It means "lsof +L1" is probably not the best way how to check for deleted libraries.

There is some info about it in lsof FAQ:

10.4.2  Why is neither link count nor size reported for some Linux
        ``DEL'' and ``mem'' file types?

        Link count and size are not reported for some entries from the
        process' ``maps'' file because a stat(2) of the entry file path
        failed or stat(2) delivered device or inode numbers that don't
        match the ones in the ``maps'' entry.

        When the stat(2) device or inode numbers don't match those in
        the ``maps'' file entry, it is likely that the stat(2) results
        don't apply to the file that was originally mapped by the
        process and whose path appears in the ``maps'' file entry, so
        lsof tries to avoid reporting possibly incorrect information.

        See the answer to the "What do ``path dev=xxx'' and ``path
        inode=yyy'' mean in the NAME column of Linux ``mem'' file
        types?" for more information on how mismatched stat(2) device
        and inode numbers are reported.

I hope it helps.



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