sockets are a kernel API for communication. Using the socket API, you can exchange data between two endpoints over TCP/IP connections, SCTP associations, UDP datagrams, or between two processes (datagram or connection) using Unix domain sockets...
Being a kernel API, any interaction with a socket is via system calls (socket
, bind
, connect
, listen
, accept
, sendmsg
, send
, recv
, write/read
...).
So typically, strace
will be able to trace those because strace
traces system calls. The only communication mechanism that strace
can't trace is IPC over shared memory (because reading/writing something in memory obviously doesn't involve a system call).
More likely, in your case, it's something else. My bet would be that the application is multi-threaded and you're not stracing the right thread. Or it could be that the application is setuid/setgid and not started as superuser.
If you want to strace what's being exchanged over Unix domain sockets, the options are:
strace
and other ptrace
debugger (trace the server or the clients)
- The audit system (
auditd
/auditctl
), again that traces the system calls
- use a
LD_PRELOAD
trick to wrap the system calls that interact with the socket
- instrument the code of the application to add logging there.
- systemtap and other low level kernel tracing/debugging systems as already mentioned
- insert a man in the middle.
For the MITM, you could for instance use socat
. Here for a connection oriented Unix domain socket like for X11:
socat -x unix-listen:/tmp/.X11-unix/X42,fork unix:/tmp/.X11-unix/X0
DISPLAY=:42 xlogo
Then, you see the X11 traffic that xlogo
and the X server exchange.
No, there are no spare sockets just floating around, But they are easy to make, so easy that you may have done so if the directory you were creating them in existed and you had write permission. To make your example work you probably need mkdir /some; chown vlc_user.rmt_grp /some; chmod 0775 /some
. and it is easier if the remote control and the player run as the same user.
Best Answer
Those commands have to be run when the server you want to monitor is currently listening on
/path/to/sock
. Then, if you rename/path/to/sock
, the server won't be affected.The
socat
command inserts a man-in-the-middle. It listens on/path/to/socks
and forwards all the traffic by the clients to/path/to/socks.original
(and logs it in the process with-v
).That only works for stream types of sockets (use
UNIX-RECVFROM
/UNIX-RECV
for datagram sockets) and only if the clients just toread/write/send/recv
on those sockets, notsendmsg()
with ancillary data and other fancy things.lsof
will only report the listening processes (socat
and the server for the listening and accepted sockets). It's generally not possible to link a connected socket on the client to the path of the socket.If you do that before starting the server, then that won't work as the server will try to listen on
/path/to/socks
and fail assocat
is already listening on that. Or you need to tell the server to listen on/path/to/sock.original
instead.