tcpaccept.bt(8)

πŸ“¦ version 0.17.0, in debian bookworm

✨ tcpaccept.bt β€” the manual page, but make it cute ✨

ok so bestie, welcome to the tcpaccept.bt(8) page πŸ’– it lives in the System Manager's Manual (section 8, the sysadmin corner of the world) and it's about tracing TCP passive connections with bpftrace/eBPF. yes we're going there. grab a snack. πŸ“


🌸 NAME 🌸

tcpaccept.bt β€” trace TCP passive connections (accept()). Uses bpftrace/eBPF. no cap. πŸ”₯


πŸŽ€ SYNOPSIS πŸŽ€

tcpaccept.bt

that's it. that's the whole vibe. one command, no args, go off πŸ’…


πŸ’– DESCRIPTION πŸ’–

so this tool traces passive TCP connections β€” like, the ones that come in via an accept() syscall (meanwhile connect() is an active connection, different girl entirely). super useful for general troubleshooting when you wanna see what new connections your local server is actually accepting. main character energy for your netstat-adjacent feelings. πŸ‘‘

it works by dynamic tracing of the kernel inet_csk_accept() socket function (that's from tcp_prot.accept, iykyk), which means you'll need to modify it to match kernel changes. fr fr, kernels move, tools gotta move with them.

also important: this tool only traces successful TCP accept()s. connection attempts to closed ports? not shown. those get traced via other functions, sorry babe πŸ™ˆ

and since it uses BPF, only the root user can use this tool. periodt.


🌈 REQUIREMENTS 🌈

  • CONFIG_BPF
  • bpftrace

that's the whole list bestie, go check them βœ…


⭐ EXAMPLES ⭐

trace all passive TCP connections (aka accept()s):

# tcpaccept.bt

πŸ¦‹ FIELDS πŸ¦‹

ok so here's what all those columns mean, let me break it down 🫢

  • TIME(s) β€” time of the call, in HH:MM:SS format.
  • PID β€” process ID.
  • COMM β€” process name.
  • RADDR β€” remote IP address.
  • RPORT β€” remote port.
  • LADDR β€” local IP address.
  • LPORT β€” local port.
  • BL β€” current accept backlog vs maximum backlog.

πŸ’… OVERHEAD πŸ’…

so this traces the kernel inet_csk_accept function and prints output for each event. the rate of that depends entirely on your server application β€” it's giving your problem, not the tool's 😭

if it's a web or proxy server accepting many tens of thousands of connections per second, then the overhead of this tool may be measurable (although still a lot better than tracing every packet, bestie, that would be actual chaos πŸ’€). if it's less than a thousand a second, then the overhead is expected to be negligible.

test and understand this overhead before use. seriously. do the vibe check first. 🧚

πŸŽ€ SOURCE πŸŽ€

this is from bpftrace:

https://github.com/iovisor/bpftrace

also look in the bpftrace distribution for a companion _examples.txt file containing example usage, output, and commentary for this tool. it's basically the director's commentary track, obsessed 🌸

this is a bpftrace version of the bcc tool of the same name. the bcc tool may provide more options and customizations:

https://github.com/iovisor/bcc

🌈 OS 🌈

Linux 🐧


⚠️ STABILITY ⚠️

Unstable β€” in development.

it's in its experimental era, we support her journey πŸ’œ


πŸ‘‘ AUTHOR πŸ‘‘

Brendan Gregg, adapted for bpftrace by Dale Hamel ✨ legends, both of them.


🫢 SEE ALSO 🫢


ok that's the whole page bestie, you're basically a kernel tracing girlie now πŸ’–

this came out of the USER COMMANDS manual, dated 2018-10-24, and it's filed under tcpaccept.bt(8) β€” so if you ever forget it, that's where to find it. slay, go trace something. πŸŽ€βœ¨

πŸ“¦ where this page comes from