Bug 235205 - lsof do not show files with link count less than 1 anymore
lsof do not show files with link count less than 1 anymore
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: lsof (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Karel Zak
Brock Organ
Depends On:
  Show dependency treegraph
Reported: 2007-04-04 10:40 EDT by Peter Bieringer
Modified: 2007-11-16 20:14 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-05-31 05:51:04 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Peter Bieringer 2007-04-04 10:40:42 EDT
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
sshd       7162    root mem    DEL    8,1          0 456377
sshd       7162    root mem    DEL    8,1          0 456280

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

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 05:51:04 EDT
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

# /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.