| Demonstrations of solisten.py, the Linux eBPF/bcc version. |
| |
| |
| This tool traces the kernel function called when a program wants to listen |
| for TCP connections. It will not see UDP neither UNIX domain sockets. |
| |
| It can be used to dynamically update a load balancer as a program is actually |
| ready to accept connexion, hence avoiding the "downtime" while it is initializing. |
| |
| # ./solisten.py --show-netns |
| PID COMM NETNS PROTO BACKLOG ADDR PORT |
| 3643 nc 4026531957 TCPv4 1 0.0.0.0 4242 |
| 3659 nc 4026531957 TCPv6 1 2001:f0d0:1002:51::4 4242 |
| 4221 redis-server 4026532165 TCPv6 128 :: 6379 |
| 4221 redis-server 4026532165 TCPv4 128 0.0.0.0 6379 |
| 6067 nginx 4026531957 TCPv4 128 0.0.0.0 80 |
| 6067 nginx 4026531957 TCPv6 128 :: 80 |
| 6069 nginx 4026531957 TCPv4 128 0.0.0.0 80 |
| 6069 nginx 4026531957 TCPv6 128 :: 80 |
| 6069 nginx 4026531957 TCPv4 128 0.0.0.0 80 |
| 6069 nginx 4026531957 TCPv6 128 :: 80 |
| |
| This output show the listen event from 3 programs. Netcat was started twice as |
| shown by the 2 different PIDs. The first time on the wildcard IPv4, the second |
| time on an IPv6. Netcat being a "one shot" program. It can accept a single |
| connection, hence the backlog of "1". |
| |
| The next program is redis-server. As the netns column shows, it is in a |
| different network namespace than netcat and nginx. In this specific case |
| it was launched in a docker container. It listens both on IPv4 and IPv4 |
| with up to 128 pending connections. |
| |
| Determining the actual container is out if the scope of this tool. It could |
| be derived by scrapping /proc/<PID>/cgroup. Note that this is racy. |
| |
| The overhead of this tool is negligeable as it traces listen() calls which are |
| invoked in the initialization path of a program. The operation part will remain |
| unaffected. In particular, accept() calls will not be affected. Neither |
| individual read() and write(). |
| |
