Bug 71434
| Summary: | lsof omits displaying deleted memory-mapped files | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | dharris |
| Component: | lsof | Assignee: | Jakub Jelinek <jakub> |
| Status: | CLOSED RAWHIDE | QA Contact: | Brock Organ <borgan> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 7.2 | ||
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2002-08-13 17:57:03 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: | |||
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.) Yes, but rawhide or 7.3.9x beta versions are already at 4.63. |
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)