Hacker News Reader

Comment by anonfordays | Hacker News Reader

>As for eBPF with respect to DTrace, I would say that they are different systems with different goals and approaches

For sure. Different systems, different times.

>rather than one eclipsing the other.

It does seem that DTrace has been eclipsed though, at least in Linux (which runs the vast majority of the world's compute). Is there a reason to use DTrace over eBPF for tracing and observability in Linux?

>There are certainly many things that DTrace can do that eBPF/BCC cannot

This may be true, but that gap is closing. There are certainly many things that eBPF can do that DTrace cannot, like Cilium.

View on HN

Perhaps familiarity with the syntax of DTrace if coming from Solaris-heavy enterprise background. But then again, too many years have passed since Solaris was a major mainstream platform. Oracle ships and supports DTrace on (Oracle) Linux by the way, but DTrace 2.0 on Linux is a scripting frontend that gets compiled to eBPF under the hood.

Back when I tried to build xcapture with DTrace, I could launch the script and use something like /pid$oracle::func:entry/ but IIRC the probe was attached only to the processes that already existed and not any new ones that were started after loading the DTrace probes. Maybe I should have used some lower level APIs or something - but eBPF on Linux automatically handles both existing and new processes.

> eBPF on Linux automatically handles both existing and new processes

Without knowing your particular case, DTrace does too - it’d certainly be tricky to use if you’re trying to debug software that “instantly crashes on startup” if it couldn’t do that. “execname” (not “pid”) is where I’d look, or perhaps that part of the predicate is skipable; regardless, should be possible.

For example I used something like "pid:module:funcname:entry" probe for userspace things (not pid$123 or pid$target, just pid to catch all PIDs using the module/funcname of interest). And back when I tested, it didn't automatically catch any new PIDs so these probes were not fired for them unless I restarted my DTrace script (but it was probably year <2010 when I last tested it).

Execname is a variable in DTrace and not a probe (?), so how would it help with automatically attaching to new PIDs? Now that I recall more details, there was no issue with statically defined kernel "fbt" probes nor "profile", but the userspace pid one was where I hit this limitation.

> Execname is a variable in DTrace and not a probe (?), so how would it help with automatically attaching to new PIDs?

You're correct, and I may have provided "a solution" to a misunderstanding of your problem - I don't think the "not matching new procs/pids" is inherent in DTrace, so indeed you might have run into an implementation issue (as it was 15 years ago). I misunderstood you as perhaps using a predicate matching a specific pid; my fault.

Reply on news.ycombinator.com