The meaning of the contents of /proc/net/unix

androidfilesystemsprocunix-sockets

On my Android device there is the file called /proc/net/unix who's content does not conform to that of any standard linux distribution (which show the unix domain sockets.) First few lines:

Num       RefCount Protocol Flags    Type St Inode Path
00000000: 00000002 00000000 00000000 0002 01 5287581 /data/misc/wifi/sockets/wpa_ctrl_789-3189
00000000: 00000003 00000000 00000000 0001 03    6402 /dev/socket/qmux_radio/qmux_client_socket    297
00000000: 00000002 00000000 00010000 0001 01    7180 /dev/.secure_storage/ssd_socket
00000000: 00000002 00000000 00010000 0001 01    6424 /dev/socket/cnd
00000000: 00000002 00000000 00010000 0001 01    6400 @QMulticlient
...

(1) What does these different columns stand for?


EDIT: Ok I've found this:

Here 'Num' is the kernel table slot number, 'RefCount' is the number of users of the socket, 'Protocol' is currently always 0, 'Flags' represent the internal kernel flags holding the status of the socket. Currently, type is always '1' (Unix domain data-gram sockets are not yet supported in the kernel). 'St' is the internal state of the socket and Path is the bound path (if any) of the socket.

However, that is not up-to-date as we have a type and not clarifying what "internal state" means.

(2) Also at the end of the path, there are sometimes an additional number without its own column name. What is that?

In addition, where in the kernel source code could I expect to find where this is created?

EDIT: 2016-04-27 (Resolved)

Thanks to answer below, I've confirmed through lsof |grep qmux, that the number in the last column for qmux_client_sockets items, is the PID of the process using it.

Best Answer

The code that generates this file is in the unix_seq_show() function in net/unix/af_unix.c in the kernel source. Looking at include/net/af_unix.h is also helpful, to see the data structures in use.

The socket path is always the last column in the output, and the Android kernel source matches the stock kernel in this respect. So unless I'm mistaken, that number that looks like a column isn't actually a separate column.

You can name UNIX domain sockets practically anything you want, as long as the total path length is less than 108 bytes. So you can't make any assumptions as to what these paths will look like. It's possible that the userspace code that's choosing those names is using a tab character followed by a number, or even padding the name out to a certain length with spaces. To test my theory, you might try looking at the socket files in /dev/socket/qmux_radio/.