FS#57859 - [lsof] "lsof $file" wrongly reports char devices

Attached to Project: Arch Linux
Opened by Peter Wu (Lekensteyn) - Friday, 16 March 2018, 10:34 GMT
Last edited by Doug Newgard (Scimmia) - Saturday, 22 September 2018, 14:04 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Anatol Pomozov (anatolik)
Levente Polyak (anthraxx)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
Assume that nothing uses /etc/hostname, try "lsof /etc/hostname". In lsof 4.89-1, it would report no output. Since lsof 4.90-1, it reports a bunch (400+) unrelated entries:

COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
bash 459 peter 0u CHR 136,9 0t0 12 /dev/pts/9
bash 459 peter 1u CHR 136,9 0t0 12 /dev/pts/9
...
kded5 709 peter 35u CHR 5,2 0t0 1114 /dev/ptmx
kded5 709 peter 36u CHR 136,1 0t0 4 /dev/pts/1
kwin_x11 749 peter mem CHR 226,128 14367 /dev/dri/renderD128

This broke a script of me which greps the output of lsof to detect whether a file has users, making lsof rather unusable. Reverting to 4.89-1 in meantime.
This task depends upon

Closed by  Doug Newgard (Scimmia)
Saturday, 22 September 2018, 14:04 GMT
Reason for closing:  Fixed
Additional comments about closing:  lsof 4.90-2
Comment by Anatol Pomozov (anatolik) - Saturday, 17 March 2018, 03:39 GMT
I do not see how this issue can be affected by Arch packaging script. Please report your issue upstream.
Comment by Peter Wu (Lekensteyn) - Saturday, 17 March 2018, 10:52 GMT
Looks like this bug is caused by addition of a new "feature":
---
00DIST
Incorporated Linux pseudoterminal endpoint processing (+|-E)
provided by Masatake YAMATO <yamato@redhat.com> with access to
test systems provided by Peter Schiffer <pschiffe@redhat.com>.
---

Until this is fixed, consider running the following between "./Configure -n linux" and "make":
sed 's/ -DHASPTYEPT//' Makefile -i

(in addition, the feature had another bug which needs the attached patch)

I'll try to reach out the authors.
Comment by Peter Wu (Lekensteyn) - Saturday, 17 March 2018, 11:01 GMT
I subscribed to the lsof-l list (https://lists.purdue.edu/mailman/listinfo/lsof-l), there also appears to be another Linux patch. Frustratingly, the lsof.itap.purdue.edu servers are inaccessible for at least two days now so I cannot check it.

Edit:
One of the contributors maintain a port for Linux here:
https://github.com/masatake/lsof-linux
but it suffers from the same problem as described originally.

Also, in case you have missed it, this is visible in the changelog:

!!!NOTE!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
! !
! It is likely that this is the last lsof revision I !
! will issue, unless serious bugs are detected, Stay !
! tuned to lsof-l for information about future support !
! of lsof. !
! !
! I thank all the many contributors to lsof over the !
! many years (20+?) I have been distributing lsof !
! versions 1, 2, 3 and 4. !
! !
! Vic Abell <abe@purdue.edu> !
! !
!!!NOTE!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Comment by Peter Wu (Lekensteyn) - Saturday, 24 March 2018, 17:12 GMT
Consider applying this patch to address this specific issue:
https://github.com/masatake/lsof-linux/commit/f5d024877006deb5d0a500235068f8c4f928939e
Comment by Anatol Pomozov (anatolik) - Sunday, 25 March 2018, 20:58 GMT
Thank you for the follow-up with the upstream developers. That is really Arch-y behavior!!! I just pushed 4.90-2 to [testing]. Please check it if it works as you expect.

Thanks again!
Comment by Peter Wu (Lekensteyn) - Sunday, 25 March 2018, 21:36 GMT
Yep, confirmed fixed with lsof 4.90-2, thanks!

Upstream was reacted very quickly and were quite helpful, kudos to Vic and Masatake!

FYI, there are additional fixes in a pre-release (4.91A, see the ftp site and Masatake's Github repo), but I think that those fixes can wait until an official "4.91" release.

Loading...