I've investigated why the test fails. On my system, the test fails with an assertion error showing that a child SSH session process is returned instead of the parent SSH daemon:
---- test_consistency stdout ----
thread 'test_consistency' (100783) panicked at tests/integration.rs:26:9:
assertion `left == right` failed
left: Process { pid: 848, name: "sshd-session", path: "/usr/libexec/sshd-session" }
right: Process { pid: 813, name: "sshd", path: "/usr/sbin/sshd" }
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
The assertion compares the process expected (the parent SSH daemon) with the actual result (a child sshd-session), and fails because their PIDs and names differ.
When I inspect active TCP sockets using sockstat, I observe multiple processes associated with the same local port. For example, two sshd-session processes reference the same connection port as the parent sshd process. This indicates that child processes handling client connections can have the same local socket endpoint as their parent.
USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS
root sshd-sessi 851 4 tcp4 10.88.111.22:22 10.88.111.19:61795
root sshd-sessi 848 4 tcp4 10.88.111.22:22 10.88.111.19:61795
root sshd 813 7 tcp6 *:22 *:*
root sshd 813 8 tcp4 *:22 *:*
A similar behavior is observed with nginx on my PfSense system. Multiple nginx worker processes each have their own PID but listen on the same ports, showing that it is common for server processes to have multiple child processes or workers associated with the same listening sockets.
USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS
root sshd 29912 4 tcp4 10.88.111.25:22 10.88.111.19:53844
root nginx 36999 5 tcp4 *:443 *:*
root nginx 36999 6 tcp6 *:443 *:*
root nginx 36999 7 tcp4 *:80 *:*
root nginx 36999 9 tcp6 *:80 *:*
root nginx 36943 5 tcp4 *:443 *:*
root nginx 36943 6 tcp6 *:443 *:*
root nginx 36943 7 tcp4 *:80 *:*
root nginx 36943 9 tcp6 *:80 *:*
root nginx 36739 5 tcp4 *:443 *:*
root nginx 36739 6 tcp6 *:443 *:*
root nginx 36739 7 tcp4 *:80 *:*
root nginx 36739 9 tcp6 *:80 *:*
unbound unbound 60275 4 tcp6 *:53 *:*
unbound unbound 60275 6 tcp4 *:53 *:*
unbound unbound 60275 7 tcp4 127.0.0.1:953 *:*
root sshd 7420 3 tcp6 *:22 *:*
root sshd 7420 4 tcp4 *:22 *:*
This behavior explains why the test fails: the code assumes a one-to-one mapping between a socket and a process, but in reality, multiple processes can be associated with the same socket, especially for server daemons and their child sessions.
So technically, get_process_by_port should return a list of processes rather than a single object.
I've investigated why the test fails. On my system, the test fails with an assertion error showing that a child SSH session process is returned instead of the parent SSH daemon:
The assertion compares the process expected (the parent SSH daemon) with the actual result (a child sshd-session), and fails because their PIDs and names differ.
When I inspect active TCP sockets using
sockstat, I observe multiple processes associated with the same local port. For example, two sshd-session processes reference the same connection port as the parent sshd process. This indicates that child processes handling client connections can have the same local socket endpoint as their parent.A similar behavior is observed with
nginxon my PfSense system. Multiplenginxworker processes each have their own PID but listen on the same ports, showing that it is common for server processes to have multiple child processes or workers associated with the same listening sockets.This behavior explains why the test fails: the code assumes a one-to-one mapping between a socket and a process, but in reality, multiple processes can be associated with the same socket, especially for server daemons and their child sessions.
So technically,
get_process_by_portshould return a list of processes rather than a single object.