Всегда ли lsof показывает разрешенные абсолютные пути к открытым файлам

Без опций пути должны предоставляться в разрешенной форме. Из lsof (8 )руководство:

An open file may be a regular file, a directory, a block special file, a character special file, an executing text reference, a library, a stream or a network file (Internet socket, NFS file or UNIX domain socket.) A specific file or all the files in a file system may be selected by path.

Конечно, могут быть ошибки, такие как слишком длинное имя пути , и в этом случае имя пути не будет разрешено, но в остальном lsof, по-видимому, зависит от функции-оболочки вокругreadlink(), который должен выполнять эту работу.

Если вы укажете имя файла, как в lsof [options] [--] names, оно должно быть разрешено:

names These are path names of specific files to list. Symbolic links are resolved before use. The first name may be separated from the preceding options with the ''--'' option.

Разумеется, применяются стандартные правила разрешения имен файлов. Слишком много уровней символических ссылок приведет к ошибке . lsofзависит от переменной MAXSYMLINKS , жестко запрограммированной в ядре Linux на максимальный уровень 40 символических ссылок , а для других систем, где переменная не определена -, устанавливает это значение равным 32 .

Если вы укажете опцию -b, имена файлов не будут разрешены:

Third, if the names of your file system directories that lsof obtains from your system's mount table are symbolic links, lsof won't be able to resolve the links. This is because the -b option causes lsof to avoid the kernel readlink(2) function it uses to resolve symbolic links.

Я не знаю, должен ли используемый файл сокета считаться открытым файлом, но в случае сокетов домена unix lsofбудет отображаться только какNAME(и может быть найден только по )точное имя, к которому был привязан сокет, будь то относительный или абсолютный путь, с сохранением любых артефактов пути:

$ cd /tmp
$ nc -dUl./././///sock &
[3] 6324
$ ls sock /tmp/sock./sock
./sock  /tmp/sock  sock
$ lsof sock /tmp/sock./sock
[nothing]
$ lsof./././///sock
COMMAND  PID USER   FD   TYPE             DEVICE SIZE/OFF   NODE NAME
nc      6324  XXX    3u  unix 0xffff9f9faab76000      0t0 175260./././///sock type=STREAM

Обратите внимание, что в случае не -не -абстрактного доменного сокета unix путь, к которому сокет был привязан или связан, имеет значение только до тех пор, пока ядро ​​не разрешит его; это кортеж [device,inode], который является реальным адресом, к которому привязан или подключен сокет:

$ cd /tmp
$ nc -dUl./././///sock &
[1] 7293
$ mv sock SOCK
$ lsof -aUp $!
COMMAND  PID  USER   FD   TYPE             DEVICE SIZE/OFF    NODE NAME
nc      7293   xxx    3u  unix 0xffff908d70bb5800      0t0 1137631./././///sock type=STREAM
$ lsof./././///sock
lsof: status error on./././///sock: No such file or directory
[stupid junk snipped]
$ lsof SOCK
[nothing]
$ nc -U./././///sock
nc: unix connect failed: No such file or directory
$ nc -U SOCK
[connected ok]

lsofтакже не может найти "подключенные" сокеты дейтаграмм (, т.е. с их адресом отправки по умолчанию, установленным )в другой сокет, делает невозможным отличить абстрактные сокеты с @в их имени от тех, у которых байт NUL в их имени, и т. д.

На случай, если кому-то интересно, вся необходимая информация доступна через sock_diagинтерфейс (UDIAG_SHOW_VFS, UDIAG_SHOW_PEERсмотрите заголовок linux/unix_udiag.h); просто lsofслишком глуп, чтобы им пользоваться.

Обратите внимание, :в примерах используется ncиз пакета netcat-openbsdот Debian, который поддерживает сокеты Unix.