Who's got the other end of this unix socketpair?
Solution 1
Since kernel 3.3, it is possible using ss
or lsof-4.89
or above — see Stéphane Chazelas's answer.
In older versions, according to the author of lsof
, it was impossible to find this out: the Linux kernel does not expose this information. Source: 2003 thread on comp.unix.admin.
The number shown in /proc/$pid/fd/$fd
is the socket's inode number in the virtual socket filesystem. When you create a pipe or socket pair, each end successively receives an inode number. The numbers are attributed sequentially, so there is a high probability that the numbers differ by 1, but this is not guaranteed (either because the first socket was N and N+1 was already in use due to wrapping, or because some other thread was scheduled between the two inode allocations and that thread created some inodes too).
I checked the definition of socketpair
in kernel 2.6.39, and the two ends of the socket are not correlated except by the type-specific socketpair
method. For unix sockets, that's unix_socketpair
in net/unix/af_unix.c
.
Solution 2
Note: I now maintain a
lsof
wrapper that combines both approaches described here and also adds information for peers of loopback TCP connections at https://github.com/stephane-chazelas/misc-scripts/blob/master/lsofc
Linux-3.3 and above.
On Linux, since kernel version 3.3 (and provided the UNIX_DIAG
feature is built in the kernel), the peer of a given unix domain socket (includes socketpairs) can be obtained using a new netlink based API.
lsof
since version 4.89 can make use of that API:
lsof +E -aUc Xorg
Will list all the Unix domain sockets that have a process whose name starts with Xorg
at either end in a format similar to:
Xorg 2777 root 56u unix 0xffff8802419a7c00 0t0 34036 @/tmp/.X11-unix/X0 type=STREAM ->INO=33273 4120,xterm,3u
If your version of lsof
is too old, there are a few more options.
The ss
utility (from iproute2
) makes use of that same API to retrieve and display information on the list of unix domain sockets on the system including peer information.
The sockets are identified by their inode number. Note that it's not related to the filesystem inode of the socket file.
For instance in:
$ ss -x
[...]
u_str ESTAB 0 0 @/tmp/.X11-unix/X0 3435997 * 3435996
it says that socket 3435997 (that was bound to the ABSTRACT socket /tmp/.X11-unix/X0
) is connected with socket 3435996. The -p
option can tell you which process(es) have that socket open. It does that by doing some readlink
s on /proc/$pid/fd/*
, so it can only do that on processes you own (unless you're root
). For instance here:
$ sudo ss -xp
[...]
u_str ESTAB 0 0 @/tmp/.X11-unix/X0 3435997 * 3435996 users:(("Xorg",pid=3080,fd=83))
[...]
$ sudo ls -l /proc/3080/fd/23
lrwx------ 1 root root 64 Mar 12 16:34 /proc/3080/fd/83 -> socket:[3435997]
To find out what process(es) has 3435996, you can look up its own entry in the output of ss -xp
:
$ ss -xp | awk '$6 == 3435996'
u_str ESTAB 0 0 * 3435996 * 3435997 users:(("xterm",pid=29215,fd=3))
You could also use this script as a wrapper around lsof
to easily show the relevant information there:
#! /usr/bin/perl
# lsof wrapper to add peer information for unix domain socket.
# Needs Linux 3.3 or above and CONFIG_UNIX_DIAG enabled.
# retrieve peer and direction information from ss
my (%peer, %dir);
open SS, '-|', 'ss', '-nexa';
while (<SS>) {
if (/\s(\d+)\s+\*\s+(\d+) ([<-]-[->])$/) {
$peer{$1} = $2;
$dir{$1} = $3;
}
}
close SS;
# Now get info about processes tied to sockets using lsof
my (%fields, %proc);
open LSOF, '-|', 'lsof', '-nPUFpcfin';
while (<LSOF>) {
if (/(.)(.*)/) {
$fields{$1} = $2;
if ($1 eq 'n') {
$proc{$fields{i}}->{"$fields{c},$fields{p}" .
($fields{n} =~ m{^([@/].*?)( type=\w+)?$} ? ",$1" : "")} = "";
}
}
}
close LSOF;
# and finally process the lsof output
open LSOF, '-|', 'lsof', @ARGV;
while (<LSOF>) {
chomp;
if (/\sunix\s+\S+\s+\S+\s+(\d+)\s/) {
my $peer = $peer{$1};
if (defined($peer)) {
$_ .= $peer ?
" ${dir{$1}} $peer\[" . (join("|", keys%{$proc{$peer}})||"?") . "]" :
"[LISTENING]";
}
}
print "$_\n";
}
close LSOF or exit(1);
For example:
$ sudo that-lsof-wrapper -ad3 -p 29215 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME xterm 29215 stephane 3u unix 0xffff8800a07da4c0 0t0 3435996 type=STREAM <-> 3435997[Xorg,3080,@/tmp/.X11-unix/X0]
Before linux-3.3
The old Linux API to retrieve unix socket information is via the /proc/net/unix
text file. It lists all the Unix domain sockets (including socketpairs). The first field in there (if not hidden to non-superusers with the kernel.kptr_restrict
sysctl parameter) as already explained by @Totor contains the kernel address of a unix_sock
structure that contains a peer
field pointing to the corresponding peer unix_sock
. It's also what lsof
outputs for the DEVICE
column on a Unix socket.
Now getting the value of that peer
field means being able to read kernel memory and know the offset of that peer
field with regards to the unix_sock
address.
Several gdb
-based and systemtap
-based solutions have already been given but they require gdb
/systemtap
and Linux kernel debug symbols for the running kernel being installed which is generally not the case on production systems.
Hardcoding the offset is not really an option as that varies with kernel version.
Now we can use a heuristic approach at determining the offset: have our tool create a dummy socketpair
(then we know the address of both peers), and search for the address of the peer around the memory at the other end to determine the offset.
Here is a proof-of-concept script that does just that using perl
(successfully tested with kernel 2.4.27 and 2.6.32 on i386 and 3.13 and 3.16 on amd64). Like above, it works as a wrapper around lsof
:
For example:
$ that-lsof-wrapper -aUc nm-applet COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME nm-applet 4183 stephane 4u unix 0xffff8800a055eb40 0t0 36888 type=STREAM -> 0xffff8800a055e7c0[dbus-daemon,4190,@/tmp/dbus-AiBCXOnuP6] nm-applet 4183 stephane 7u unix 0xffff8800a055e440 0t0 36890 type=STREAM -> 0xffff8800a055e0c0[Xorg,3080,@/tmp/.X11-unix/X0] nm-applet 4183 stephane 8u unix 0xffff8800a05c1040 0t0 36201 type=STREAM -> 0xffff8800a05c13c0[dbus-daemon,4118,@/tmp/dbus-yxxNr1NkYC] nm-applet 4183 stephane 11u unix 0xffff8800a055d080 0t0 36219 type=STREAM -> 0xffff8800a055d400[dbus-daemon,4118,@/tmp/dbus-yxxNr1NkYC] nm-applet 4183 stephane 12u unix 0xffff88022e0dfb80 0t0 36221 type=STREAM -> 0xffff88022e0df800[dbus-daemon,2268,/var/run/dbus/system_bus_socket] nm-applet 4183 stephane 13u unix 0xffff88022e0f80c0 0t0 37025 type=STREAM -> 0xffff88022e29ec00[dbus-daemon,2268,/var/run/dbus/system_bus_socket]
Here's the script:
#! /usr/bin/perl
# wrapper around lsof to add peer information for Unix
# domain sockets. needs lsof, and superuser privileges.
# Copyright Stephane Chazelas 2015, public domain.
# example: sudo this-lsof-wrapper -aUc Xorg
use Socket;
open K, "<", "/proc/kcore" or die "open kcore: $!";
read K, $h, 8192 # should be more than enough
or die "read kcore: $!";
# parse ELF header
my ($t,$o,$n) = unpack("x4Cx[C19L!]L!x[L!C8]S", $h);
$t = $t == 1 ? "L3x4Lx12" : "Lx4QQx8Qx16"; # program header ELF32 or ELF64
my @headers = unpack("x$o($t)$n",$h);
# read data from kcore at given address (obtaining file offset from ELF
# @headers)
sub readaddr {
my @h = @headers;
my ($addr, $length) = @_;
my $offset;
while (my ($t, $o, $v, $s) = splice @h, 0, 4) {
if ($addr >= $v && $addr < $v + $s) {
$offset = $o + $addr - $v;
if ($addr + $length - $v > $s) {
$length = $s - ($addr - $v);
}
last;
}
}
return undef unless defined($offset);
seek K, $offset, 0 or die "seek kcore: $!";
my $ret;
read K, $ret, $length or die "read($length) kcore \@$offset: $!";
return $ret;
}
# create a dummy socketpair to try find the offset in the
# kernel structure
socketpair(Rdr, Wtr, AF_UNIX, SOCK_STREAM, PF_UNSPEC)
or die "socketpair: $!";
$r = readlink("/proc/self/fd/" . fileno(Rdr)) or die "readlink Rdr: $!";
$r =~ /\[(\d+)/; $r = $1;
$w = readlink("/proc/self/fd/" . fileno(Wtr)) or die "readlink Wtr: $!";
$w =~ /\[(\d+)/; $w = $1;
# now $r and $w contain the socket inodes of both ends of the socketpair
die "Can't determine peer offset" unless $r && $w;
# get the inode->address mapping
open U, "<", "/proc/net/unix" or die "open unix: $!";
while (<U>) {
if (/^([0-9a-f]+):(?:\s+\S+){5}\s+(\d+)/) {
$addr{$2} = hex $1;
}
}
close U;
die "Can't determine peer offset" unless $addr{$r} && $addr{$w};
# read 2048 bytes starting at the address of Rdr and hope to find
# the address of Wtr referenced somewhere in there.
$around = readaddr $addr{$r}, 2048;
my $offset = 0;
my $ptr_size = length(pack("L!",0));
my $found;
for (unpack("L!*", $around)) {
if ($_ == $addr{$w}) {
$found = 1;
last;
}
$offset += $ptr_size;
}
die "Can't determine peer offset" unless $found;
my %peer;
# now retrieve peer for each socket
for my $inode (keys %addr) {
$peer{$addr{$inode}} = unpack("L!", readaddr($addr{$inode}+$offset,$ptr_size));
}
close K;
# Now get info about processes tied to sockets using lsof
my (%fields, %proc);
open LSOF, '-|', 'lsof', '-nPUFpcfdn';
while (<LSOF>) {
if (/(.)(.*)/) {
$fields{$1} = $2;
if ($1 eq 'n') {
$proc{hex($fields{d})}->{"$fields{c},$fields{p}" .
($fields{n} =~ m{^([@/].*?)( type=\w+)?$} ? ",$1" : "")} = "";
}
}
}
close LSOF;
# and finally process the lsof output
open LSOF, '-|', 'lsof', @ARGV;
while (<LSOF>) {
chomp;
for my $addr (/0x[0-9a-f]+/g) {
$addr = hex $addr;
my $peer = $peer{$addr};
if (defined($peer)) {
$_ .= $peer ?
sprintf(" -> 0x%x[", $peer) . join("|", keys%{$proc{$peer}}) . "]" :
"[LISTENING]";
last;
}
}
print "$_\n";
}
close LSOF or exit(1);
Solution 3
Since kernel 3.3
You can now get this information with ss
:
# ss -xp
Now you can see in the Peer
column an ID (inode number) which corresponds to another ID in the Local
column. Matching IDs are the two ends of a socket.
Note: The UNIX_DIAG
option must be enabled in your kernel.
Before kernel 3.3
Linux didn't expose this information to userland.
However, by looking into kernel memory, we can access this information.
Note: This answer does so by using gdb
, however, please see @StéphaneChazelas' answer which is more elaborated in this regard.
# lsof | grep whatever
mysqld 14450 (...) unix 0xffff8801011e8280 (...) /var/run/mysqld/mysqld.sock
mysqld 14450 (...) unix 0xffff8801011e9600 (...) /var/run/mysqld/mysqld.sock
There is 2 different sockets, 1 listening and 1 established. The hexa number is the address to the corresponding kernel unix_sock
structure, having a peer
attribute being the address of the other end of the socket (also a unix_sock
structure instance).
Now we can use gdb
to find the peer
within kernel memory:
# gdb /usr/lib/debug/boot/vmlinux-3.2.0-4-amd64 /proc/kcore
(gdb) print ((struct unix_sock*)0xffff8801011e9600)->peer
$1 = (struct sock *) 0xffff880171f078c0
# lsof | grep 0xffff880171f078c0
mysql 14815 (...) unix 0xffff880171f078c0 (...) socket
Here you go, the other end of the socket is held by mysql
, PID 14815.
Your kernel must be compiled with KCORE_ELF
to use /proc/kcore
. Also, you need a version of your kernel image with debugging symbols. On Debian 7, apt-get install linux-image-3.2.0-4-amd64-dbg
will provide this file.
No need for the debuggable kernel image...
If you don't have (or don't want to keep) the debugging kernel image on the system, you can give gdb
the memory offset to "manually" access the peer
value. This offset value usually differ with kernel version or architecture.
On my kernel, I know the offset is 680 bytes, that is 85 times 64 bits. So I can do:
# gdb /boot/vmlinux-3.2.0-4-amd64 /proc/kcore
(gdb) print ((void**)0xffff8801011e9600)[85]
$1 = (void *) 0xffff880171f078c0
Voilà, same result as above.
If you have the same kernel running on several machine, it is easier to use this variant because you don't need the debug image, only the offset value.
To (easily) discover this offset value at first, you do need the debug image:
$ pahole -C unix_sock /usr/lib/debug/boot/vmlinux-3.2.0-4-amd64
struct unix_sock {
(...)
struct sock * peer; /* 680 8 */
(...)
}
Here you go, 680 bytes, this is 85 x 64 bits, or 170 x 32 bits.
Most of the credit for this answer goes to MvG.
Solution 4
Erkki Seppala actually has a tool that retrieves this information from the Linux kernel with gdb.. It's available here.
Solution 5
This solution, though working, is of limited interest since if you have a recent-enough systemtap, chances are you'll have a recent-enough kernel where you can use
ss
based approaches, and if you're on an older kernel, that other solution, though more hacky is more likely to work and doesn't require addition software.Still useful as a demonstration of how to use
systemtap
for this kind of task.
If on a recent Linux system with a working systemtap (1.8 or newer), you could use the script below to post-process the output of lsof
:
For example:
$ lsof -aUc nm-applet | sudo that-script COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME nm-applet 4183 stephane 4u unix 0xffff8800a055eb40 0t0 36888 type=STREAM -> 0xffff8800a055e7c0[dbus-daemon,4190,@/tmp/dbus-AiBCXOnuP6] nm-applet 4183 stephane 7u unix 0xffff8800a055e440 0t0 36890 type=STREAM -> 0xffff8800a055e0c0[Xorg,3080,@/tmp/.X11-unix/X0] nm-applet 4183 stephane 8u unix 0xffff8800a05c1040 0t0 36201 type=STREAM -> 0xffff8800a05c13c0[dbus-daemon,4118,@/tmp/dbus-yxxNr1NkYC] nm-applet 4183 stephane 11u unix 0xffff8800a055d080 0t0 36219 type=STREAM -> 0xffff8800a055d400[dbus-daemon,4118,@/tmp/dbus-yxxNr1NkYC] nm-applet 4183 stephane 12u unix 0xffff88022e0dfb80 0t0 36221 type=STREAM -> 0xffff88022e0df800[dbus-daemon,2268,/var/run/dbus/system_bus_socket] nm-applet 4183 stephane 13u unix 0xffff88022e0f80c0 0t0 37025 type=STREAM -> 0xffff88022e29ec00[dbus-daemon,2268,/var/run/dbus/system_bus_socket]
(if you see 0x0000000000000000 above instead of 0xffff..., it's because the kernel.kptr_restrict
sysctl parameter is set on your system which causes kernel pointers to be hidden from non-privileged processes, in which case you'll need to run lsof
as root to get a meaningful result).
This script doesn't make any attempt to cope with socket file names with newline characters, but nor does lsof
(nor does lsof
cope with blanks or colons).
systemtap
here is used to dump the address and peer address of all the unix_sock
structures in the unix_socket_table
hash in the kernel.
Only tested on Linux 3.16 amd64 with systemtap 2.6, and 3.13 with 2.3.
#! /usr/bin/perl
# meant to process lsof output to try and find the peer of a given
# unix domain socket. Needs a working systemtap, lsof, and superuser
# privileges. Copyright Stephane Chazelas 2015, public domain.
# Example: lsof -aUc X | sudo this-script
open STAP, '-|', 'stap', '-e', q{
probe begin {
offset = &@cast(0, "struct sock")->__sk_common->skc_node;
for (i = 0; i < 512; i++)
for (p = @var("unix_socket_table@net/unix/af_unix.c")[i]->first;
p;
p=@cast(p, "struct hlist_node")->next
) {
sock = p - offset;
printf("%p %p\n", sock, @cast(sock, "struct unix_sock")->peer);
}
exit()
}
};
my %peer;
while (<STAP>) {
chomp;
my ($a, $b) = split;
$peer{$a} = $b;
}
close STAP;
my %f, %addr;
open LSOF, '-|', 'lsof', '-nPUFpcfdn';
while (<LSOF>) {
if (/(.)(.*)/) {
$f{$1} = $2;
if ($1 eq 'n') {
$addr{$f{d}}->{"$f{c},$f{p}" . ($f{n} =~ m{^([@/].*?)( type=\w+)?$} ? ",$1" : "")} = "";
}
}
}
close LSOF;
while (<>) {
chomp;
for my $addr (/0x[0-9a-f]+/g) {
my $peer = $peer{$addr};
if (defined($peer)) {
$_ .= $peer eq '0x0' ?
"[LISTENING]" :
" -> $peer\[" . join("|", keys%{$addr{$peer}}) . "]";
last;
}
}
print "$_\n";
}
Related videos on Youtube
Jonathon Reinhart
Professional C, asm, Python developer GitLab, FreeNas admin
Updated on September 18, 2022Comments
-
Jonathon Reinhart over 1 year
I want to determine which process has the other end of a UNIX socket.
Specifically, I'm asking about one that was created with
socketpair()
, though the problem is the same for any UNIX socket.I have a program
parent
which creates asocketpair(AF_UNIX, SOCK_STREAM, 0, fds)
, andfork()
s. The parent process closesfds[1]
and keepsfds[0]
to communicate. The child does the opposite,close(fds[0]); s=fds[1]
. Then the childexec()
s another program,child1
. The two can communicate back and forth via this socketpair.Now, let's say I know who
parent
is, but I want to figure out whochild1
is. How do I do this?There are several tools at my disposal, but none can tell me which process is on the other end of the socket. I have tried:
lsof -c progname
lsof -c parent -c child1
ls -l /proc/$(pidof server)/fd
cat /proc/net/unix
Basically, I can see the two sockets, and everything about them, but cannot tell that they are connected. I am trying to determine which FD in the parent is communicating with which child process.
-
Jonathon Reinhart almost 13 yearsThanks @Gillles. I do recall reading something about that a while back, but was unable to find it again. I may just have to go writing a patch for /proc/net/unix.
-
Jonathon Reinhart almost 13 yearsAnd yes, I'd made that observation with the increasing inode numbers, and currently that's what I'm working with. However, as you noted, it is not guaranteed. The process I'm looking at has at least 40 open unix sockets, and I saw one instance where the N+1 did not hold true. Bummer.
-
Gilles 'SO- stop being evil' almost 13 years@JonathonReinhart I checked the definition of
socketpair
, and the two ends of the socket are not correlated except by the type-specificsocketpair
method. For unix sockets, that'sunix_socketpair
in `net/unix/af_unix.c. It would be nice to have this information for pipes, too. -
MvG almost 12 yearsVery useful information! Even if the tool didn't work out of the box for me (it caused a kernel Oops), the idea helped me to identify the other end. I described my solution on Stack Overflow.
-
Totor about 9 years
parse error: unknown statistic operator @var
: am I missing something? -
Stéphane Chazelas about 9 years@Totor,
@var
was added in systemtap 1.8, 2012-06-17 (latest is 2.7) -
Stéphane Chazelas about 9 yearsI've now added such a PoC which seems to work well on the systems I've tested.
-
mikeserv about 9 yearsIs this part of anything bigger? You seem to have put a lot of effort into this lately.
-
Stéphane Chazelas about 9 years@mikeserv, that's a follow-up on that comment. Not being able to find the other end of unix sockets is something that has always annoyed me (often when trying to find X clients and there was a recent question about that). I'll try and see if a similar approach can be used for pseudo-terminals and suggest those to the
lsof
author. -
mikeserv about 9 yearsdoes
ss
not do this? It's kind of over my head, butss -px
lists a lot of unix sockets with peer information like:users: ("nacl_helper",pid=18992,fd=6),("chrome",pid=18987,fd=6),("chrome",pid=18975,fd=5)) u_str ESTAB\t0\t0\t/run/dbus/system_bus_socket 8760\t\t* 15068
and the column headings are...State\tRecv-Q\tSend-Q\tLocal Address:Port\tPeer Address:Port
-
mikeserv about 9 yearsAlso, if I do
lsof -c terminology
I can seeterminolo 12731\tmikeserv\t12u\tunix\t0xffff880600e82680\t0t0\t1312426\ttype=STREAM
but if I doss -px | grep terminology
I get:u_str\tESTAB\t0\t0\t* 1312426\t*1315046\tusers:(("terminology",pid=12731,fd=12))
-
Stéphane Chazelas about 9 years@mikeserv, it looks like it does indeed! It seems I've been wasting a lot of time lately...
-
Stéphane Chazelas about 9 years@mikeserv, the
ss
man page even has an example to list the X server clients!ss -x src /tmp/.X11-unix/*
(doesn't work for me though) -
mikeserv about 9 yearsHmm... So it looks like
ss
is printing only the Node wherelsof
does the device name as well.. But if I do:ss -px | grep terminology
to get that 1312426 Node again, and then after -ss -px | grep 1315046
to search for the peer end it prints:u_str\tESTAB\t0\t0\t@/tmp/.X11-unix/X0 1315046\t* 1312426
. It seems to be inline with theman
page, which gives this example usage:ss -x src /tmp/.X11-unix/*
Find all local processes connected toX
server. -
mikeserv about 9 yearsYou pointed me back to that pty thing - and I remember looking at
ss
then (and understanding even less then) but it just kind of rung a bell. -
mikeserv about 9 yearsThe
ss -x src /tmp/...
does work here... I wonder what the difference would be? There's also an option for listing-m
emory usage, but that doesn't reveal much for me, though. Still, the reversegrep
thing pulled it in too. Hmmm... maybe try theman
example w/-p
as well? That seems to be a little more informative. Oh. You know - I'm probably running usermode X as well - since 1.16 (or whatever that version number was) which might make it easier for me to do introspection. Most X servers are probably still superuser. I wonder ifss
doesn't want to show you root info? -
Stéphane Chazelas about 9 years@mikeserv, On the systems I've tried, either
ss -x src /tmp/...
gives me all non-listening sockets (the filter doesn't filter) or it doesn't give me the peer. I can parse the output ofss -x;ss -lx
though (not reliably for sockets with spaces or newlines) -
mikeserv about 9 yearsIf I add
-e
I also get these little arrows like<->
or<--
or-->
. The<--
and-->
(at a glance) seem to occur only alongside entries which also list filenames. Do you think that is relevant at all? Strike that - That was a pretty weak glance. But it does seem that the@
begins a pathname to a socket proper. And at least all of the pathnames appear to be fully qualified - the/
slashes might be useful. -
Stéphane Chazelas about 9 years@mikeserv, not the best documented piece of software, is it? From the source, looks like those arrows are to indicate which direction of the socket is shutdown.
-
mikeserv about 9 yearsStephane, actually, it's got this huge trove of docs. It's a member of the... iproute2 suite. Ok, that was from memory and wrong. But there is this:
cat /usr/share/doc/iproute2/ss.html
-
mikeserv about 9 yearsWell, I give up on it - I still don't understand what it's all about really. Anyway, this does look interesting though - its seems to list only those users with something in (Receive|Send)Q:
ss -px src '/tmp/.X11*/*' | grep -v '^[^0-9]*0 *0 '
-
Totor about 9 yearsI don't get it guys, if I do
ss -px | grep mysql
I still cannot linkmysql
withmysqld
even if they both appear in the list (kernel 3.2). -
Stéphane Chazelas about 9 years@Totor, 3.2 would be too old. The feature was added in this commit, first released in 3.3 AFAICT.
-
Totor about 9 yearsIt looks like you're jumping from
long
tolong
to find thepeer
offset but how can you be sure thatpeer
is on along
boundary? -
Stéphane Chazelas about 9 years
-
Totor about 9 years@StéphaneChazelas thanks for the link. More accurately, it says that if you're looking for a N bytes value, you will find it on a N bytes address boundary (the compiler takes care of alignment).
-
Stéphane Chazelas about 9 years@Totor that doesn't mean an 8 byte struct will be 8 byte aligned. An 8 byte long will be 8 byte aligned within the struct and such a struct at least 8 byte aligned. on the systems I've looked at, unix_sock were 64 byte aligned on 64 bit systems and 256 byte aligned on 32 bit ones
-
Stéphane Chazelas about 9 years@mikeserv, the
ss
filter issue seems to have been fixed very recently in thread.gmane.org/gmane.linux.network/351180 -
Totor about 9 yearsLet us continue this discussion in chat.
-
Totor about 9 years@mikeserv I tried
ss -px | grep mysql
with iproute 3.16 on a 3.13.1 kernel. Still can't link the client and the server sockets. Is it only working withlsof
or doesn't it work at all? -
mikeserv about 9 years@Totor - not as far as I know, but I'll tell you, you're probably not asking the right guy. I have only the faintest idea about what a socket even does. Still, though, is the
mysql
socket owned by you? I want to believe thatss
wouldn't reveal privileged information to you. I wonder what I have that could be comparable... -
mikeserv about 9 years@Totor - actually the chrome thing from earlier is probably closest -
chrome
's processes are run in namespaced containers - and it maintains its own database. You can get information about a running process by referencing asrc
socket file (maybe) and you cangrep
for pid. I just cross-referencedlsof
because that seemed to be the thread of things here. Anyway, it might help. Also there's this crappy doc:cat /usr/share/doc/iproute2/ss.html
. (theip
docs are far and away better done). -
Totor about 9 years@mikeserv sorry, I didn't have
UNIX_DIAG
enabled in my kernel. Now I have, and indeed, when I usess -px
, the Peer column gives me an ID (inode number?) that is the same ID as the Local column on the other side of the socket. It works. -
mikeserv about 9 years@Totor - don't apologize - I wasn't aware until now that it was a requirement. Thank you. Still though, I'm not entirely certain it does work, or, really, what work it should do. But Stéphane seems to think it works, and, based on my past year hanging around this website, I'd say that it's probably a pretty good indicator. It's why there's no answer here from me - and there isn't likely to be. I don't really understand what is wanted - I don't know the difference really between a socket or a pty (line discipline?). I know I like to use ptys, and never had occasion to use a socket pair.
-
Totor about 9 years@mikeserv I updated my answer accordingly.
-
mikeserv about 9 years@Totor - I know. I upvoted accordingly. Thanks again, by the way.
-
mikeserv about 9 yearsThat's pretty cool - looks you chunked out the last block of code to make up the majority of the top script. But didn't do you have some q/a thing on Perl's
<>
? Is it better now? I seem to remember it was a security thing... -
Stéphane Chazelas about 9 years@mikeserv, I made it a wrapper around lsof directly as it's mostly only going to be useful to process lsof output anyway.
<>
is a dangerous feature. It's useful in that you can doperl -ne 'some processing' 'cmd|'
to do some processing on the output ofcmd
, but that becomes a problem when you doperl -ne 'some processing' -- *
and can't guarantee file names won't end in|
. Details there. Not really a concern here. -
Totor over 7 years@StéphaneChazelas sorry, continuing a very old chat here. :)