Kind of hard to explain but I noticed when straceing the PID that has the socket open I cannot see any of the communication. How can I sit in the middle of a socket file to watch communication?

  • 1
    Can you elaborate a bit? In the mean time this might be helpful: hokstad.com/5-simple-ways-to-troubleshoot-using-strace – slm Jul 14 '13 at 0:54
  • When you say socket you mean a server running on a port on a host? Like a Apache web server running on hostA listening on port 80? Or do you truly mean a socket device file such as a pipe device? – slm Jul 14 '13 at 1:15
  • The socket in this list: en.wikipedia.org/wiki/Unix_file_types? – slm Jul 14 '13 at 1:17
  • How exactly are you sending signals to a socket? Or do you not mean signals in the sense kill -15 $pid? – tripleee Jul 14 '13 at 6:41
  • You can't send signals to a socket – Ulrich Dangel Jul 14 '13 at 11:05

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.

  • @JMoore With strace -ff -o log -s 20000 memcached... you'll see all communication exchanged over the sockets. If there's communication not traced there, then that's not over sockets. – Stéphane Chazelas Jul 14 '13 at 10:05
  • 1
    You can't MITM all communication on unix domain socket using socat. for example UDS allows you to send file descriptors using sendmsg() and recievemsg() but doint MITM then wouldn't make sense, as all action happens inside the kernel, like creating file descriptors for the recipient, etc. – Sahil Singh Sep 13 '16 at 16:15

You can't "strace a socket", strace works on processes, so you can strace all processes that talk to the socket, but you can't use strace to see absolutely all communication involving the socket. You may be able to get somewhere with dtrace or systemtap if they're available on your OS, but that's quite a bit of work.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy