This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 71434 - lsof omits displaying deleted memory-mapped files
lsof omits displaying deleted memory-mapped files
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: lsof (Show other bugs)
7.2
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-08-13 12:36 EDT by dharris
Modified: 2007-04-18 12:45 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-08-13 13:57:03 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description dharris 2002-08-13 12:36:42 EDT
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:

Always.

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
COMMAND   PID USER   FD   TYPE DEVICE    SIZE   NODE NAME
# 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 13:56:59 EDT
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 14:19:04 EDT
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.