strace-4.21-alt2 -P FILE -e trace=read makes strace show only reads from fds associated with the specified path. However, this doesn't work for sockets connected to a path (for connect,close,sendto,recvfrom). Example showing that -P has an effect on filtering reads: $ strace -f -P .lpoptions -e trace=read cat .lpoptions strace: Requested path '.lpoptions' resolved into '/space/home/imz/.lpoptions' read(3, "EmbedAllFonts=yes", 131072) = 17 EmbedAllFonts=yesread(3, "", 131072) = 0 +++ exited with 0 +++ $ strace -f -y -e trace=read cat .lpoptions read(3</lib64/libc-2.25.so>, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200\7\2\0\0\0\0\0"..., 832) = 832 read(3</space/home/imz/.lpoptions>, "EmbedAllFonts=yes", 131072) = 17 EmbedAllFonts=yesread(3</space/home/imz/.lpoptions>, "", 131072) = 0 +++ exited with 0 +++ $
(To reproduce a bug, I wanted to inject a success for a close syscall associated with a socket connected to a specific file.)
(In reply to comment #1) > (To reproduce a bug, I wanted to inject a success for a close syscall > associated with a socket connected to a specific file.) Of course, the requested feature could be a useful feature in general, but in my case it (combined with success injection) wouldn't help me to reproduce that bug. It could only be useful for filtering and reading the log. (However, filtering can be done by external tools, so the absence of the requested feature is not critical.) I didn't understand that it wouldn't help when I wrote this feature request, but I understood this after a while; and here is why: if I made the close() syscall not have any real effect, I would make subsequent socket() and open() syscalls return shifted fd numbers (which would break the behavior pattern when the bug is not observed), but that wouldn't actually make the subsequent select() syscalls using the old fd number fail, because that would still be a valid open fd. The bug would appear if the subsequent syscalls would try to work with the old and already closed fd. (Therefore, I made up a way of not re-using the old fd number by "randomizing" the number returned from socket() with an LD_PRELOAD, so that it has little chance to coincide with the old, just closed fd.)
(In reply to comment #2) > The bug would appear if the subsequent syscalls would try to work with the old > and already closed fd. Or more accurately: ...if they tried to work with the old fd, that got re-used for a non-socket connection or a unrelated connection. > (Therefore, I made up a way of not re-using the old fd > number by "randomizing" the number returned from socket() with an LD_PRELOAD, > so that it has little chance to coincide with the old, just closed fd.)
Запрос не выполнен: -P/--trace-path по-прежнему сопоставляется только с путями в аргументах файловых системных вызовов и не раскрывает адрес AF_UNIX-сокета. Проверено в контейнере Sisyphus на strace 7.2-alt1 (сборка 18.08.2026). Клиент соединяется с /tmp/s.sock: $ strace -f -P /tmp/s.sock -e trace=connect,sendto,close python3 cl.py (ни одной строки трассировки) $ strace -f -y -e trace=connect python3 cl.py connect(3<socket:[...]>, {sa_family=AF_UNIX, sun_path="/tmp/s.sock"}, 14) = 0 То есть путь сокета strace знает и печатает, но как критерий отбора он не используется. Апстримный тикет с этой же просьбой — strace/strace#40 "filter socket operations by path" — заведён 20.02.2018 и открыт до сих пор, метка project/filtering. Оставляю открытым: сведения из комментариев 2-3 (для исходной задачи фильтр всё равно не помог бы) не отменяют самого запроса.
