lsof

lsof copied to clipboard

On Debian GNU/Linux amd64 with packaged lsof 4.95.0 or built from current git HEAD (582d2331ed216b61265c49976ff36196c18c9a2a), for processes with an empty process name (as with perl -e '$0 = ""' for instance), lsof reports the name of the previous process (presumably in numeric order of pid) instead of the correct name (the empty string)

To Reproduce

$ perl -e '$0 = ""; sleep 999'  &
[2] 7994
$ lsof -w -ad cwd -F c -p "$!"
p7994
ckworker/u16:5-kcryptd/253:0

$ print /proc/<7990-7995>
/proc/7990 /proc/7992 /proc/7994

Previous process was 7992.

$ head /proc/{7992,7994}/stat
==> /proc/7992/stat <==
7992 (kworker/u16:5-kcryptd/253:0) I 2 0 0 0 -1 69238880 0 0 0 0 0 28 0 0 20 0 1 0 567709 0 0 18446744073709551615 0 0 0 0 0 0 0 2147483647 0 0 0 0 17 2 0 0 0 0 0 0 0 0 0 0 0 0 0

==> /proc/7994/stat <==
7994 () S 7913 7994 7913 34822 9170 1077936128 265 0 0 0 0 0 0 0 25 5 1 0 572261 234000384 905 18446744073709551615 93888647225344 93888648834373 140722633113296 0 0 0 0 128 0 1 0 0 17 5 0 0 0 0 0 93888650556392 93888650625732 93888665280512 140722633122183 140722633122210 140722633122210 140722633125866 0

Expected:

p7994
c

I can reproduce this bug.

I found the culprit, but was unsure how to display it. My current fix will show (unknown) as the command name, but the user will not be able to distinguish between empty process name and failure to retrieve it.

Thanks.

I'd argue that here the process is known and there shouldn't be any difficulty in retrieving it so it would be wrong to return (unknown) in that case. That would means however that with the normal output (as opposed to with -F), you would not see anything under COMMAND, and the PID would then appear to be the first field. One way to express such a command name there could be as \x00 as a special case (but still only c with -F c as that's not ambiguous).

It should also be possible to list open files for that command with

lsof -c '/^$/'

Fixed in master.