lsfd + nsenter: Parse and allow to join target process's network namespace #3200

0x7f454c46 · 2024-09-17T00:10:46Z

Arista's userspace uses network namespaces a lot, including userspace VRFs, some form of containers, etc. Because of that, processes such as BGP may have many file descriptors in different network namespaces. There were issues with file descriptor leaks, which resulted in userspace misbehaviour and it was challenging to find which process/fd prevents some network namespace from being destructed. It resulted years ago in a kernel patch that provides /proc/<pid>/fdns/... links for each socket to its corresponding network namespace.

But we are in 2024 and I don't want to have or maintain such a patch. The userspace is fully capable of figuring out all the needed details about the sockets. Initially, I wrote a stand-alone tool that allows joining and showing the information about the socket's network namespaces: 31f0717

But I thought it was worth giving it a chance and integrating it into existing tools.

masatake · 2024-09-17T08:18:12Z

This looks useful.

Let me review the change for lsfd. I'm thinking about writing a test case.
By the way, you may also want to extend lsns. I drew a figure: #3006. Maybe read_opened_namespaces is the function we should extend.

karelzak · 2024-09-17T10:35:58Z

lsfd-cmd/sock-xinfo.c

+	if (pidfd < 0)
+		return;
+
+	sk = syscall(SYS_pidfd_getfd, pidfd, fd, 0);


Please see (and include) include/pidfd-utils.h. It seems we need to add pidfd_getfd() there.

Nice! Thanks, going to use.

karelzak · 2024-09-17T11:01:04Z

sys-utils/nsenter.c

@@ -119,6 +122,7 @@ static void __attribute__((__noreturn__)) usage(void)
 }

 static pid_t namespace_target_pid = 0;
+static int sock_fd = -1;


It seems this global variable is unnecessary.

Yeah, that's what I initially intended to do, but noticed all those *_fd getopt() variables, thought it's a codestyle.
Going to change that back :-)

sys-utils/nsenter.c

0x7f454c46 · 2024-09-17T15:35:18Z

This looks useful.

Let me review the change for lsfd. I'm thinking about writing a test case.

Thank you!

By the way, you may also want to extend lsns. I drew a figure: #3006. Maybe read_opened_namespaces is the function we should extend.

Yeah, let me take a look and see what I can do with lsns.

masatake · 2024-09-18T17:17:00Z

I'm adding "foreign-socket" factory to test_mkfds.
The factory does:

make a child process and do unshare(NETNS),
let the child process make a socket (foreign socket), and
let the child process send the socket to the parent process.

When we observe the parent process with lsfd, we can see the usefulness of this pull request.

$ sudo ./test_mkfds foreign-socket
$ pidof test_mkfds
2292812
$ git checkout master; make
$ sudo ./lsfd -p 2292812 -o COMMAND,PID,ASSOC,TYPE,NAME,SOCK.NETNS,ENDPOINTS -Q '(STTYPE == "SOCK")'
COMMAND        PID ASSOC        TYPE NAME              SOCK.NETNS ENDPOINTS
test_mkfds 2292812     5 UNIX-STREAM socket:[88661560]            
test_mkfds 2292812     6 UNIX-STREAM socket:[88661561]
$ git checkout sock-netns; make
$ sudo ./lsfd -p 2292812 -o COMMAND,PID,ASSOC,TYPE,NAME,SOCK.NETNS,ENDPOINTS -Q '(STTYPE == "SOCK")'
COMMAND        PID ASSOC        TYPE NAME            SOCK.NETNS ENDPOINTS
test_mkfds 2292812     5 UNIX-STREAM state=connected 4026538651 2292812,test_mkfds,6rw
test_mkfds 2292812     6 UNIX-STREAM state=connected 4026538651 2292812,test_mkfds,5rw

I want people to see not only SOCK.NETNS but also ENDPOINTS.
This pull request adds a killer feature to lsfd.
I will polish the "foreign-socket" factory.

masatake · 2024-09-18T17:21:46Z

lsfd-cmd/lsfd.c

@@ -882,13 +882,17 @@ static struct file *collect_file_symlink(struct path_cxt *pc,
 	else if (assoc >= 0) {
 		/* file-descriptor based association */
 		FILE *fdinfo;
+		struct stat lsb;


I took time to understand the relationship between lsb and sb.
Instead of adding lsb as a local var, adding bool is_socket as a local variable looks more straightforward:

else if (assoc >= 0) { /* file-descriptor based association */ FILE *fdinfo; bool is_socket = (sb.st_mode & S_IFMT) == S_IFSOCK; if (ul_path_stat(pc, &sb, AT_SYMLINK_NOFOLLOW, name) == 0) f->mode = sb.st_mode; if (is_nsfs_dev(f->stat.st_dev)) load_sock_xinfo(pc, name, f->stat.st_ino); if (is_socket) load_fdsk_xinfo(proc, assoc);

@masatake thanks!

Fair enough, I think it could be even more simplified, what do you think about the following:

/* file-descriptor based association */ FILE *fdinfo; if (is_nsfs_dev(f->stat.st_dev)) { if (ul_path_stat(pc, &sb, AT_SYMLINK_NOFOLLOW, name) == 0) f->mode = lsb.st_mode; load_sock_xinfo(pc, name, f->stat.st_ino); } else if ((sb.st_mode & S_IFMT) == S_IFSOCK) { load_fdsk_xinfo(proc, assoc); } fdinfo = ul_path_fopenf(pc, "r", "fdinfo/%d", assoc); if (fdinfo) { read_fdinfo(f, fdinfo); fclose(fdinfo); } }

(yet have to test it)

[currently in the process of patching lsns, will update the PR shortly]

@masatake thanks!

Fair enough, I think it could be even more simplified, what do you think about the following:

/* file-descriptor based association */ FILE *fdinfo; if (is_nsfs_dev(f->stat.st_dev)) { if (ul_path_stat(pc, &sb, AT_SYMLINK_NOFOLLOW, name) == 0) f->mode = lsb.st_mode; load_sock_xinfo(pc, name, f->stat.st_ino); } else if ((sb.st_mode & S_IFMT) == S_IFSOCK) { load_fdsk_xinfo(proc, assoc); } fdinfo = ul_path_fopenf(pc, "r", "fdinfo/%d", assoc); if (fdinfo) { read_fdinfo(f, fdinfo); fclose(fdinfo); } }

(yet have to test it)

[currently in the process of patching lsns, will update the PR shortly]

Actually, we probably need to update f->mode for non-namespace fds, so it's not going to work.
I'll use your suggestion with is_socket.

0x7f454c46 · 2024-09-18T18:00:06Z

v2.1 updates (v2 went off when I forgot to rebase with a fixup pending):

Address reviews by @karelzak and @masatake (thanks a lot!)
in v1 I mistakenly seem to add lsk binary from the PR description, now removed
wired up lsns, the output now lists more network namespaces, previously "invisible" (suggested-by @masatake)

Somewhat arguably in v2 I omit #ifdef UL_HAVE_PIDFD as the helpers in pidfd-utils.h ifdef-guards around them. But I see unshare/kill use the guards with UL_HAVE_PIDFD, maybe to issue less syscalls - which is not the case here.

0x7f454c46 · 2024-09-18T19:13:50Z

v3: fix syscall ifdef guard:

-#  ifndef HAVE_PIDFD_OPEN
+#  ifndef HAVE_PIDFD_GETFD

…ther netns This is for testing PR util-linux#3200. Signed-off-by: Masatake YAMATO <yamato@redhat.com>

This is for testing PR util-linux#3200. Signed-off-by: Masatake YAMATO <yamato@redhat.com>

masatake · 2024-09-18T20:15:50Z

The failure (lsns/filter) on rpm-build:fedora-rawhide-ppc64le is an independent issue from this PR. Fixing the issue is the task on my stack.

I wrote a test case https://github.com/masatake/util-linux/commits/sock-netns-with-tests/.

$ make test_mkfds                                 
$ sudo tests/ts/lsfd/mkfds-foreign-sockets        
         lsfd: SOCK.NETNS and ENDPOINTS for sockets made in another netns ... OK
$ sudo tests/ts/lsns/netns-from-sock      
         lsns: find an isolated net namespace via socket ... OK
$ sudo ./test_mkfds foreign-sockets 9 10
2393108 4026539263
[return]

test_mkfds is a helper command.

./test_mkfds foreign-sockets 9 10 makes an isolated net namespace that can be reached only via fd 9 and 10.
2393108 is pid that opens 9 and 10. 9 and 10 are made in netns 4026539263. The process making a socket is already gone. So lsns and lsfd without this pull request cannot find 4026539263.

Till typing [reutrn], test_mkfds keeps the sockets and the net namespace.

I have a TODO item in masatake@e9150d7. After solving it, I will make a pull request.
I wonder where I should send the pull request including the test cases to.

0x7f454c46 · 2024-09-18T21:17:52Z

@masatake thank you!

Regarding the test: I'm not sure if you need to send fd with a UNIX socket. It's up to you, if you prefer.
For my rough non-automated manual testing I did something like:

old_ns = open("/proc/self/ns/net");
unshare(CLONE_NEWNET);
sk = socket(...);
setns(old_ns, CLONE_NEWNET);

Here is my rough test, that I based on kernel selftests (no plans to merge that anywhere):
0x7f454c46/linux@49d4c4a

Up to you if you want to simplify your test for util-linux :-)
And thanks for heads up on fedora-rawhide-ppc64le build.

masatake · 2024-09-19T00:23:58Z

@0x7f454c46 Thank you. I could not find such a simple solution. Based on your idea, I will rewrite the "foreign-sockets".

…ther netns This is for testing PR util-linux#3200. Signed-off-by: Masatake YAMATO <yamato@redhat.com>

This is for testing PR util-linux#3200. Signed-off-by: Masatake YAMATO <yamato@redhat.com>

masatake · 2024-09-19T07:45:08Z

include/pidfd-utils.h

+#  ifndef HAVE_PIDFD_GETFD
+static inline int pidfd_getfd(int pidfd, int targetfd, unsigned int flags)
+{
+	return syscall(SYS_pidfd_open, pidfd, targetfd flags);


return syscall(SYS_pidfd_getfd, pidfd, targetfd, flags);

?

Wow, I'm surprised how I missed this copy'n'paste. I'm pretty sure I test every time before pushing, but somehow that slipped in. Thanks!

This is for testing PR util-linux#3200. Signed-off-by: Masatake YAMATO <yamato@redhat.com>

…ther netns This is for testing PR util-linux#3200. Signed-off-by: Masatake YAMATO <yamato@redhat.com>

This is for testing PR util-linux#3200. Signed-off-by: Masatake YAMATO <yamato@redhat.com>

…ther netns This is for testing PR util-linux#3200. Signed-off-by: Masatake YAMATO <yamato@redhat.com>

0x7f454c46 · 2024-09-19T13:36:53Z

v4: s/syscall(SYS_pidfd_open/syscall(SYS_pidfd_getfd/ thanks to @masatake

Also rebased on the updated master.

This is for testing PR util-linux#3200. Signed-off-by: Masatake YAMATO <yamato@redhat.com>

…ther netns This is for testing PR util-linux#3200. Signed-off-by: Masatake YAMATO <yamato@redhat.com>

This is for testing PR util-linux#3200. Signed-off-by: Masatake YAMATO <yamato@redhat.com>

…ther netns This is for testing PR util-linux#3200. Signed-off-by: Masatake YAMATO <yamato@redhat.com>

karelzak · 2024-09-23T08:39:23Z

I guess the last question from my side is should it be -N for nsenter or should I just choose some other letter?

-N is fine.

Maybe rename --sock-net to --net-socket (as we already have --net as a generic option).

0x7f454c46 · 2024-09-23T16:05:27Z

v6: rename --sock-net to --net-socket (per @karelzak suggestion).

0x7f454c46 · 2024-09-23T16:56:30Z

The compat failure seems to be expected? (judging by other PRs)
But I'm somewhat confused with lsns test failure. If I understood the test correctly, it failed to output the PID, but it did show the proper line on another filtered request?

+lsns_expr: NS == 4026532222 && NPROCS == 1
+pid: 
+PID: 100573
+inode: 4026532222
+lsfd:
+ABC 100573 runner user ------ REG nsfs 0 4026532222 user:[4026532222]
+lsns:NS == 4026532222 && NPROCS == 1
+4026532222 user 1 100573 runner /home/runner/work/util-linux/util-linux/util-linux-2.40/_build/sub/test_mkfds\x20--comm\x20ABC\x20userns\x204

Doesn't quite seem related, and it does work on my manual exercise:

./lsns -Q 'NS == 4026532784 && NPROCS == 1' -o PID --raw -n
151571

Let's see the re-run after the renaming, I guess?

masatake · 2024-09-23T21:45:25Z

But I'm somewhat confused with lsns test failure. If I understood the test correctly, it failed to output the PID, but it did show the proper line on another filtered request?

This is a misterous bug I'm tracking at #3205
You can ignore the failure of lsns/filter. It is nothing to do with this pull request.

…ade in the ns This is for testing PR util-linux#3200. Signed-off-by: Masatake YAMATO <yamato@redhat.com>

This is for testing PR util-linux#3200. Signed-off-by: Masatake YAMATO <yamato@redhat.com>

…ther netns This is for testing PR util-linux#3200. Signed-off-by: Masatake YAMATO <yamato@redhat.com>

The network namespace of a socket can be different from the target process. Previously there were some userspace issues where a net-namespace was held alive by a socket leak. For this purpose Arista's linux kernel has a patch to provide socket => netns map by procfs pid/fd directory links. Add nsenter option to join the network namespace of a target process' socket. Signed-off-by: Dmitry Safonov <0x7f454c46@gmail.com>

A sample of the output before (with SOCK.NETNS): COMMAND PID USER ASSOC XMODE TYPE SOURCE MNTID INODE NAME SOCK.NETNS [..] > tmp_ipv4 114075 root 0 rw---- CHR pts:7 27 10 /dev/pts/7 > tmp_ipv4 114075 root 1 rw---- CHR pts:7 27 10 /dev/pts/7 > tmp_ipv4 114075 root 2 rw---- CHR pts:7 27 10 /dev/pts/7 > tmp_ipv4 114075 root 3 r----- REG nsfs 3 4026531840 net:[4026531840] > tmp_ipv4 114075 root 4 r----- REG nsfs 3 4026532537 net:[4026532537] > tmp_ipv4 114075 root 5 r----- REG nsfs 3 4026532864 net:[4026532864] > tmp_ipv4 114075 root 6 r----- REG nsfs 3 4026532537 net:[4026532537] > tmp_ipv4 114075 root 7 r----- REG nsfs 3 4026532947 net:[4026532947] > tmp_ipv4 114075 root 8 rw---- TCP sockfs 10 100750 state=listen laddr=10.0.254.1:7010 4026532947 > tmp_ipv4 114075 root 9 r----- REG nsfs 3 4026533109 net:[4026533109] > tmp_ipv4 114075 root 10 rw---- TCP sockfs 10 100763 socket:[100763] > tmp_ipv4 114075 root 11 rw---- TCP sockfs 10 100776 state=listen laddr=10.0.254.1:7012 4026533109 > tmp_ipv4 114075 root 12 r----- REG nsfs 3 4026533271 net:[4026533271] > tmp_ipv4 114075 root 13 rw---- TCP sockfs 10 100789 socket:[100789] > tmp_ipv4 114075 root 14 rw---- TCP sockfs 10 100802 state=listen laddr=10.0.254.1:7014 4026533271 > tmp_ipv4 114075 root 15 r----- REG nsfs 3 4026532537 net:[4026532537] > tmp_ipv4 114075 root 16 r----- REG nsfs 3 4026532783 net:[4026532783] > tmp_ipv4 114075 root 17 rw---- TCP sockfs 10 100815 state=listen laddr=10.0.254.1:7015 4026532783 > tmp_ipv4 114075 root 18 r----- REG nsfs 3 4026533511 net:[4026533511] > tmp_ipv4 114075 root 19 rw---- TCP sockfs 10 100828 socket:[100828] > tmp_ipv4 114075 root 20 rw---- TCP sockfs 10 100841 state=listen laddr=10.0.254.1:7017 4026533511 > tmp_ipv4 114075 root 21 r----- REG nsfs 3 4026533673 net:[4026533673] > tmp_ipv4 114075 root 22 rw---- TCP sockfs 10 100854 socket:[100854] > tmp_ipv4 114075 root 23 rw---- TCP sockfs 10 100867 state=listen laddr=10.0.254.1:7019 4026533673 > tmp_ipv4 114075 root 24 r----- REG nsfs 3 4026532537 net:[4026532537] > tmp_ipv4 114075 root 25 r----- REG nsfs 3 4026533754 net:[4026533754] > tmp_ipv4 114075 root 26 rw---- TCP sockfs 10 100880 state=listen laddr=10.0.254.1:7020 4026533754 > tmp_ipv4 114075 root 27 r----- REG nsfs 3 4026532504 net:[4026532504] > tmp_ipv4 114075 root 28 rw---- TCP sockfs 10 100893 socket:[100893] > tmp_ipv4 114075 root 29 rw---- TCP sockfs 10 100906 state=listen laddr=10.0.254.1:7022 4026532504 > tmp_ipv4 114075 root 30 r----- REG nsfs 3 4026533999 net:[4026533999] > tmp_ipv4 114075 root 31 rw---- TCP sockfs 10 100919 socket:[100919] > tmp_ipv4 114075 root 32 rw---- TCP sockfs 10 100932 state=listen laddr=10.0.254.1:7024 4026533999 > tmp_ipv4 114075 root 33 r----- REG nsfs 3 4026532537 net:[4026532537] > tmp_ipv4 114075 root 34 r----- REG nsfs 3 4026534080 net:[4026534080] > tmp_ipv4 114075 root 35 rw---- TCP sockfs 10 100945 state=listen laddr=10.0.254.1:7025 4026534080 > tmp_ipv4 114075 root 36 r----- REG nsfs 3 4026534242 net:[4026534242] > tmp_ipv4 114075 root 37 rw---- TCP sockfs 10 100958 socket:[100958] > tmp_ipv4 114075 root 38 rw---- TCP sockfs 10 100971 state=listen laddr=10.0.254.1:7027 4026534242 > tmp_ipv4 114075 root 39 r----- REG nsfs 3 4026534404 net:[4026534404] > tmp_ipv4 114075 root 40 rw---- TCP sockfs 10 100984 socket:[100984] > tmp_ipv4 114075 root 41 rw---- TCP sockfs 10 100997 state=listen laddr=10.0.254.1:7029 4026534404 > tmp_ipv4 114075 root 42 r----- REG nsfs 3 4026532537 net:[4026532537] > tmp_ipv4 114075 root 43 r----- REG nsfs 3 4026534484 net:[4026534484] > tmp_ipv4 114075 root 44 rw---- TCP sockfs 10 101010 state=listen laddr=10.0.254.1:7030 4026534484 > tmp_ipv4 114075 root 45 r----- REG nsfs 3 4026534646 net:[4026534646] > tmp_ipv4 114075 root 46 rw---- TCP sockfs 10 101023 socket:[101023] > tmp_ipv4 114075 root 47 rw---- TCP sockfs 10 101036 state=listen laddr=10.0.254.1:7032 4026534646 > tmp_ipv4 114075 root 48 r----- REG nsfs 3 4026534808 net:[4026534808] > tmp_ipv4 114075 root 49 rw---- TCP sockfs 10 101049 socket:[101049] > tmp_ipv4 114075 root 50 rw---- TCP sockfs 10 101062 state=listen laddr=10.0.254.1:7034 4026534808 > tmp_ipv4 114075 root 51 r----- REG nsfs 3 4026532537 net:[4026532537] > tmp_ipv4 114075 root 52 r----- REG nsfs 3 4026534889 net:[4026534889] > tmp_ipv4 114075 root 53 rw---- TCP sockfs 10 101075 state=listen laddr=10.0.254.1:7035 4026534889 > tmp_ipv4 114075 root 54 r----- REG nsfs 3 4026535051 net:[4026535051] > tmp_ipv4 114075 root 55 rw---- TCP sockfs 10 101088 socket:[101088] > tmp_ipv4 114075 root 56 rw---- TCP sockfs 10 101101 state=listen laddr=10.0.254.1:7037 4026535051 > tmp_ipv4 114075 root 57 r----- REG nsfs 3 4026535213 net:[4026535213] > tmp_ipv4 114075 root 58 rw---- TCP sockfs 10 101114 socket:[101114] > tmp_ipv4 114075 root 59 rw---- TCP sockfs 10 101127 state=listen laddr=10.0.254.1:7039 4026535213 > tmp_ipv4 114075 root 60 r----- REG nsfs 3 4026532537 net:[4026532537] > tmp_ipv4 114075 root 61 r----- REG nsfs 3 4026535294 net:[4026535294] > tmp_ipv4 114075 root 62 rw---- TCP sockfs 10 101140 state=listen laddr=10.0.254.1:7040 4026535294 [..] A sample of the output after: > COMMAND PID USER ASSOC XMODE TYPE SOURCE MNTID INODE NAME SOCK.NETNS [..] > tmp_ipv4 114075 root 0 rw---- CHR pts:7 27 10 /dev/pts/7 > tmp_ipv4 114075 root 1 rw---- CHR pts:7 27 10 /dev/pts/7 > tmp_ipv4 114075 root 2 rw---- CHR pts:7 27 10 /dev/pts/7 > tmp_ipv4 114075 root 3 r----- REG nsfs 3 4026531840 net:[4026531840] > tmp_ipv4 114075 root 4 r----- REG nsfs 3 4026532537 net:[4026532537] > tmp_ipv4 114075 root 5 r----- REG nsfs 3 4026532864 net:[4026532864] > tmp_ipv4 114075 root 6 r----- REG nsfs 3 4026532537 net:[4026532537] > tmp_ipv4 114075 root 7 r----- REG nsfs 3 4026532947 net:[4026532947] > tmp_ipv4 114075 root 8 rw---- TCP sockfs 10 100750 state=listen laddr=10.0.254.1:7010 4026532947 > tmp_ipv4 114075 root 9 r----- REG nsfs 3 4026533109 net:[4026533109] > tmp_ipv4 114075 root 10 rw---- TCP sockfs 10 100763 state=listen laddr=10.0.254.1:7011 4026533028 > tmp_ipv4 114075 root 11 rw---- TCP sockfs 10 100776 state=listen laddr=10.0.254.1:7012 4026533109 > tmp_ipv4 114075 root 12 r----- REG nsfs 3 4026533271 net:[4026533271] > tmp_ipv4 114075 root 13 rw---- TCP sockfs 10 100789 state=listen laddr=10.0.254.1:7013 4026533190 > tmp_ipv4 114075 root 14 rw---- TCP sockfs 10 100802 state=listen laddr=10.0.254.1:7014 4026533271 > tmp_ipv4 114075 root 15 r----- REG nsfs 3 4026532537 net:[4026532537] > tmp_ipv4 114075 root 16 r----- REG nsfs 3 4026532783 net:[4026532783] > tmp_ipv4 114075 root 17 rw---- TCP sockfs 10 100815 state=listen laddr=10.0.254.1:7015 4026532783 > tmp_ipv4 114075 root 18 r----- REG nsfs 3 4026533511 net:[4026533511] > tmp_ipv4 114075 root 19 rw---- TCP sockfs 10 100828 state=listen laddr=10.0.254.1:7016 4026533430 > tmp_ipv4 114075 root 20 rw---- TCP sockfs 10 100841 state=listen laddr=10.0.254.1:7017 4026533511 > tmp_ipv4 114075 root 21 r----- REG nsfs 3 4026533673 net:[4026533673] > tmp_ipv4 114075 root 22 rw---- TCP sockfs 10 100854 state=listen laddr=10.0.254.1:7018 4026533592 > tmp_ipv4 114075 root 23 rw---- TCP sockfs 10 100867 state=listen laddr=10.0.254.1:7019 4026533673 > tmp_ipv4 114075 root 24 r----- REG nsfs 3 4026532537 net:[4026532537] > tmp_ipv4 114075 root 25 r----- REG nsfs 3 4026533754 net:[4026533754] > tmp_ipv4 114075 root 26 rw---- TCP sockfs 10 100880 state=listen laddr=10.0.254.1:7020 4026533754 > tmp_ipv4 114075 root 27 r----- REG nsfs 3 4026532504 net:[4026532504] > tmp_ipv4 114075 root 28 rw---- TCP sockfs 10 100893 state=listen laddr=10.0.254.1:7021 4026533835 > tmp_ipv4 114075 root 29 rw---- TCP sockfs 10 100906 state=listen laddr=10.0.254.1:7022 4026532504 > tmp_ipv4 114075 root 30 r----- REG nsfs 3 4026533999 net:[4026533999] > tmp_ipv4 114075 root 31 rw---- TCP sockfs 10 100919 state=listen laddr=10.0.254.1:7023 4026533918 > tmp_ipv4 114075 root 32 rw---- TCP sockfs 10 100932 state=listen laddr=10.0.254.1:7024 4026533999 > tmp_ipv4 114075 root 33 r----- REG nsfs 3 4026532537 net:[4026532537] > tmp_ipv4 114075 root 34 r----- REG nsfs 3 4026534080 net:[4026534080] > tmp_ipv4 114075 root 35 rw---- TCP sockfs 10 100945 state=listen laddr=10.0.254.1:7025 4026534080 > tmp_ipv4 114075 root 36 r----- REG nsfs 3 4026534242 net:[4026534242] > tmp_ipv4 114075 root 37 rw---- TCP sockfs 10 100958 state=listen laddr=10.0.254.1:7026 4026534161 > tmp_ipv4 114075 root 38 rw---- TCP sockfs 10 100971 state=listen laddr=10.0.254.1:7027 4026534242 > tmp_ipv4 114075 root 39 r----- REG nsfs 3 4026534404 net:[4026534404] > tmp_ipv4 114075 root 40 rw---- TCP sockfs 10 100984 state=listen laddr=10.0.254.1:7028 4026534323 > tmp_ipv4 114075 root 41 rw---- TCP sockfs 10 100997 state=listen laddr=10.0.254.1:7029 4026534404 > tmp_ipv4 114075 root 42 r----- REG nsfs 3 4026532537 net:[4026532537] > tmp_ipv4 114075 root 43 r----- REG nsfs 3 4026534484 net:[4026534484] > tmp_ipv4 114075 root 44 rw---- TCP sockfs 10 101010 state=listen laddr=10.0.254.1:7030 4026534484 > tmp_ipv4 114075 root 45 r----- REG nsfs 3 4026534646 net:[4026534646] > tmp_ipv4 114075 root 46 rw---- TCP sockfs 10 101023 state=listen laddr=10.0.254.1:7031 4026534565 > tmp_ipv4 114075 root 47 rw---- TCP sockfs 10 101036 state=listen laddr=10.0.254.1:7032 4026534646 > tmp_ipv4 114075 root 48 r----- REG nsfs 3 4026534808 net:[4026534808] > tmp_ipv4 114075 root 49 rw---- TCP sockfs 10 101049 state=listen laddr=10.0.254.1:7033 4026534727 > tmp_ipv4 114075 root 50 rw---- TCP sockfs 10 101062 state=listen laddr=10.0.254.1:7034 4026534808 > tmp_ipv4 114075 root 51 r----- REG nsfs 3 4026532537 net:[4026532537] > tmp_ipv4 114075 root 52 r----- REG nsfs 3 4026534889 net:[4026534889] > tmp_ipv4 114075 root 53 rw---- TCP sockfs 10 101075 state=listen laddr=10.0.254.1:7035 4026534889 > tmp_ipv4 114075 root 54 r----- REG nsfs 3 4026535051 net:[4026535051] > tmp_ipv4 114075 root 55 rw---- TCP sockfs 10 101088 state=listen laddr=10.0.254.1:7036 4026534970 > tmp_ipv4 114075 root 56 rw---- TCP sockfs 10 101101 state=listen laddr=10.0.254.1:7037 4026535051 > tmp_ipv4 114075 root 57 r----- REG nsfs 3 4026535213 net:[4026535213] > tmp_ipv4 114075 root 58 rw---- TCP sockfs 10 101114 state=listen laddr=10.0.254.1:7038 4026535132 > tmp_ipv4 114075 root 59 rw---- TCP sockfs 10 101127 state=listen laddr=10.0.254.1:7039 4026535213 > tmp_ipv4 114075 root 60 r----- REG nsfs 3 4026532537 net:[4026532537] > tmp_ipv4 114075 root 61 r----- REG nsfs 3 4026535294 net:[4026535294] > tmp_ipv4 114075 root 62 rw---- TCP sockfs 10 101140 state=listen laddr=10.0.254.1:7040 4026535294 [..] Signed-off-by: Dmitry Safonov <0x7f454c46@gmail.com>

While parsing process's fds, check the network namespace of the socket. That will provide fuller list of namespaces in the system. Signed-off-by: Dmitry Safonov <0x7f454c46@gmail.com>

masatake · 2024-09-23T22:01:42Z

@0x7f454c46 Could you rebase this pr on the latest master branch?
My branch (#3202) for testing this pull request conflicts with the master branch where my changes for test_mkfds were merged.

0x7f454c46 · 2024-09-23T22:11:50Z

@0x7f454c46 Could you rebase this pr on the latest master branch? My branch (#3202) for testing this pull request conflicts with the master branch where my changes for test_mkfds were merged.

I just did it. Thanks again for your testing work, I appreciate it a lot.

…ade in the ns This is for testing PR util-linux#3200. Signed-off-by: Masatake YAMATO <yamato@redhat.com>

This is for testing PR util-linux#3200. Signed-off-by: Masatake YAMATO <yamato@redhat.com>

…ther netns This is for testing PR util-linux#3200. Signed-off-by: Masatake YAMATO <yamato@redhat.com>

masatake · 2024-09-24T01:42:19Z

#3202, the branch for testing, is rebased on the latest #3200.