Bug 71434 - lsof omits displaying deleted memory-mapped files
Summary: lsof omits displaying deleted memory-mapped files
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: lsof
Version: 7.2
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Brock Organ
Depends On:
TreeView+ depends on / blocked
Reported: 2002-08-13 16:36 UTC by dharris
Modified: 2007-04-18 16:45 UTC (History)
0 users

Clone Of:
Last Closed: 2002-08-13 17:57:03 UTC

Attachments (Terms of Use)

Description dharris 2002-08-13 16:36:42 UTC
Description of Problem:

When listing the open files of a process that has memory mapped a filename that 
is now unlinked (but the inode still exists because it is still open), lsof 
simply omits displaying the memory map. It should display the filename, the 
inode number, and mention that the file has been deleted.

Version-Release number of selected component (if applicable):

lsof-4.51-2 (red hat RPM)
(This RPM contains lsof-4.51 compiled with linux/proc data-getting)

How Reproducible:


Steps to Reproduce:
1. Find a long-running daemon process.
2. Upgrade a shared library.
3. Run lsof and compare with /proc/PID/maps

Actual Results:

# lsof -p 26226 | grep crypto
# cat /proc/26226/maps | grep crypto
40470000-40525000 r-xp 00000000 68:02 
34640      /lib/libcrypto.so.0.9.6b;3d5831be (deleted)
40525000-40531000 rw-p 000b4000 68:02 
34640      /lib/libcrypto.so.0.9.6b;3d5831be (deleted)

Expected Results:

Well, lsof should have listed /lib/libcrypto.so.0.9.6b and noted that it was a 
deleted file and listed the inode number of that deleted file.

This is now lsof deals with files opened on a file descriptor:

# lsof -p 18200 | head -1
# lsof -p 18200 | grep randomfile01
sleep   18200 root    1w   REG  104,2       0  69555 /tmp/randomfile01
# rm /tmp/randomfile01
#  lsof -p 18200 | grep randomfile01
sleep   18200 root    1w   REG  104,2       0  69555 /tmp/randomfile01 (deleted)

Additional Information:

For an additional idea of why things failed I ran a strace. You can see below 
that lsof is treating the pseuto-filename in /proc/PID/maps as a real filename, 
not parsing the deleted info, and trying to stat that filename. Apparently lsof 
ignores the filename when the stat fails.

# strace -o /tmp/strace-02 lsof -p 26226 | grep crypto
# grep libcrypto /tmp/strace-02
stat64("/lib/libcrypto.so.0.9.6b;3d5831be", 0xbfffc200) = -1 ENOENT (No such 
file or directory)

Comment 1 dharris 2002-08-13 17:56:59 UTC
I corresponded with the author who said:

"1) the 4.51 revision is 13 revisions out of date (The current lsof revision is 
4.64.); and 2) the bug was fixed 9 lsof revisions ago in 4.55."

I suggest an upgrade. (Perhaps also an RHBA?)

(I looked and Red Hat 7.3 is also running lsof version 4.51.)

Comment 2 Jakub Jelinek 2002-08-13 18:19:04 UTC
Yes, but rawhide or 7.3.9x beta versions are already at 4.63.

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