tcpaccept.bt(8)
β¨ 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_BPFbpftrace
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, inHH:MM:SSformat.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
- debian bookworm: bpftrace 0.17.0-1 Β· Apache-2.0
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms