1Demonstrations of solisten.py, the Linux eBPF/bcc version.
2
3
4This tool traces the kernel function called when a program wants to listen
5for TCP connections. It will not see UDP neither UNIX domain sockets.
6
7It can be used to dynamically update a load balancer as a program is actually
8ready to accept connexion, hence avoiding the "downtime" while it is initializing.
9
10# ./solisten.py --show-netns
11PID    COMM         NETNS        PROTO  BACKLOG  ADDR                                    PORT
123643   nc           4026531957   TCPv4  1        0.0.0.0                                 4242
133659   nc           4026531957   TCPv6  1        2001:f0d0:1002:51::4                    4242
144221   redis-server 4026532165   TCPv6  128      ::                                      6379
154221   redis-server 4026532165   TCPv4  128      0.0.0.0                                 6379
166067   nginx        4026531957   TCPv4  128      0.0.0.0                                 80
176067   nginx        4026531957   TCPv6  128      ::                                      80
186069   nginx        4026531957   TCPv4  128      0.0.0.0                                 80
196069   nginx        4026531957   TCPv6  128      ::                                      80
206069   nginx        4026531957   TCPv4  128      0.0.0.0                                 80
216069   nginx        4026531957   TCPv6  128      ::                                      80
22
23This output show the listen event from 3 programs. Netcat was started twice as
24shown by the 2 different PIDs. The first time on the wilcard IPv4, the second
25time on an IPv6. Netcat being a "one shot" program. It can accept a single
26connection, hence the backlog of "1".
27
28The next program is redis-server. As the netns column shows, it is in a
29different network namespace than netcat and nginx. In this specific case
30it was launched in a docker container. It listens both on IPv4 and IPv4
31with up to 128 pending connections.
32
33Determining the actual container is out if the scope of this tool. It could
34be derived by scrapping /proc/<PID>/cgroup. Note that this is racy.
35
36The overhead of this tool is negligeable as it traces listen() calls which are
37invoked in the initialization path of a program. The operation part will remain
38unaffected. In particular, accept() calls will not be affected. Neither
39individual read() and write().
40
41