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