dtrace(8)

πŸ“¦ version 2.0.7, in ubuntu resolute, ubuntu stonking

πŸ’– dtrace(8) β€” Linux Programmer's Manual πŸ’–

okay bestie, sit down, we're reading the dtrace(8) page together and honestly? it's giving essential sysadmin lore. πŸ¦‹


✨ NAME ✨

dtprobed β€” the USDT-tracking daemon. yes that's the whole name section, she's lowkey humble about it πŸ’…


✨ SYNOPSIS ✨

dtprobed [-Fd] [-d devname] [-t timeout]

(yes, <pink>-d</pink> shows up twice in there, and no that's not a typo on my part, that's literally what the page says, keep scrolling and it'll make sense, i promise 🫢)


✨ DESCRIPTION ✨

So. dtprobed is a whole component of the DTrace system, and her job β€” her entire main character job β€” is keeping track of USDT probes inside running processes. She parses the DOF those processes hand over and stores it, so that dtrace proper can come along later and consume it. That's the vibe. πŸŽ€

dtprobed should be started as soon as possible after startup, and she should always be kept running. Periodt. The reason is kinda important bestie: processes that start before her might not have usable USDT probes. 😭 On systemd systems this is usually done automatically for you. (And restarting on upgrade should also be handled for you by the packaging system, so you don't have to think about it. slay.)

The following options are supported:

  • -F β€” puts dtprobed into the foreground: log output goes to stderr instead of the syslog. (systemd uses this one routinely, so it's very much a normal thing to see.)
  • -d β€” enables debugging: logs extra output, and disables sandboxing of the DOF parser. πŸ‘€
  • -n devname β€” names the CUSE device something other than the default dtrace/helper. Important caveat here, bestie: DOF-containing processes will not connect to this instance unless they're pointed at it via the DTRACE_DOF_INIT_DEVNAME environment variable. You need this option if for some reason (maybe debugging?) you want to have two dtprobeds running at once. (They'll still share a state directory though, so DTrace will know about all the probes discovered by all the running dtprobeds. teamwork πŸ’–)
  • -t timeout β€” the timeout, in seconds, for DOF reads from the parser child. Any DOF that takes longer than this to parse gets discarded. The default is 5 seconds and honestly it's probably always reasonable. But heads up: set it too low and you might cause legitimate DOF to be thrown away 😬, set it too high and faulty DOF might block dtprobed, which prevents registration of new probes. It's a whole balancing act.

✨ ENVIRONMENT VARIABLES ✨

Ignoring the internal testing-only variables, dtprobed herself doesn't accept any environment variables. But the programs that talk to her β€” meaning any program that contains USDT probes β€” do accept some. so it's a them thing, not a her thing. 🀷

  • DTRACE_DOF_INIT_DEBUG β€” outputs debugging messages to standard error if set (to anything at all, doesn't matter what).
  • DTRACE_DOF_INIT_DEVNAME β€” the full name of the helper device to send registration requests on. By default that's /dev/dtrace/helper. dtprobed is listening on the other end of this device. 🎧
  • DTRACE_DOF_INIT_DISABLE β€” disables DOF registration entirely. just. off. πŸ’€

✨ FILES ✨

  • /run/dtrace/stash β€” private stash of DOF. (a stash!! like a little treasure box πŸ“)
  • /run/dtrace/probes β€” parsed representations of every probe. Here's the tea: that parsed representation is shared between dtrace(8) and dtprobed, and it can change between releases. So on upgrade, dtprobed should be restarted, and she'll regenerate any parsed DOF that's needed β€” which means dtraces started after the upgrade will still work. (Still-running dtraces from before the upgrade may become unable to see newly-added probes though. sad but true. 😭)

✨ SEE ALSO ✨


quick recap bestie: start her early, never stop her, and if you're upgrading β€” restart her. that's the whole assignment. 🫢

and that's the page!! this one came from Oracle Linux, dated 22 Oct 2023. iconic. no cap. πŸ’…βœ¨πŸŒΈ

πŸ“¦ where this page comes from