3 ms·

Prompt 1C: Create a Go package named dbpftrace with a README and docs, then create a cli utility named dbpftrace to: parse pid and descendents' fs syscall even

• deemkeen 1y ago
  Thanks for the thoughtful pointers — super helpful. Where diffwatch is today: it’s a portable directory watcher (fsnotify → inotify/FSEvents/ReadDirectoryChangesW) that coalesces events and renders live unified diffs in a tiny TUI. What I’m planning based on your suggestions (and others here): 1. Two-tier design Default (no admin): keep the current directory-watch mode for quick, portable use. Power mode (attach): diffwatch attach --pid <PID> | --cmd "<…>" to trace a process and its children and feed any touched paths into the same diff UI. 2. Per-OS backends for “attach” Linux: eBPF/bpftrace when available; fallback to strace -ff -e trace=file for zero extra deps. macOS: opensnoop / fs_usage (DTrace-based). Windows: ETW (Kernel File provider) via a tiny helper (e.g., KrabsETW) that streams JSON events. 3. Admin rights caveat macOS (DTrace) and Windows (ETW kernel) typically require admin. I’ll keep the default dir-watch mode as the “no-admin” path, and document the elevated-rights requirement clearly for “attach”. 4. Normalized event stream All backends emit a common JSON line: {"ts": "...", "pid": 1234, "op": "create|write|rename|unlink|close", "path": "..."} Then a short stability window (debounce + retry on transient ENOENT) before reading to diff. 5. Scalability & ergonomics Handle editor/atomic-save tempfiles gracefully. Respect .gitignore and add --exclude/--include globs. Guardrails for watch count limits; skip non-regular files; optional --record (NDJSON) and --save-patch. 6. Containers / agents Nice follow-on: diffwatch attach --cmd ... inside a container (or attach by PID in the container namespace) to confine the blast radius for agent runs. Ask: I’d love help and pointers to minimal tracer scripts: A small bpftrace/DTrace snippet that reliably captures opens/writes/renames for a PID(+children). A tiny Windows ETW consumer example focused on File I/O, filtered by PID, emitting JSON. Repo: https://github.com/deemkeen/diffwatch https://github.com/deemkeen/diffwatch I’ll open issues for: “Attach mode” backends (Linux/macOS/Windows) .gitignore/globs Event coalescing + transient ENOENT handling JSON recording / patch export If you or anyone wants to collaborate, I’ll tag them good first issue / help wanted and am happy to review PRs quickly. Thanks again for the nudge to go beyond plain FS events — the PID/container “attach” mode should make agent debugging much more robust.
  • westurner 1y ago
    Np. Distributed tracing tools for containers already do this but none have a --diff feature for logging what changed in changed files. Does this command also track renames? sudo dtrace -n 'vfs::*:entry { printf("%-16s %-6d %s", execname, pid, probefunc); }' Isn't it just a list of syscalls instead of vfs:*? Actually, re: Dtrace on MacOS with SIP and apparently without sufficient symbols installed to trace kernel syscalls these days: https://news.ycombinator.com/item?id=38909715 https://news.ycombinator.com/item?id=38909715 It looks like there's a utility called dtruss which wraps Dtrace on OSX: https://www.google.com/search?q=dtruss https://www.google.com/search?q=dtruss "Misadventures in DTrace: how to debug the macOS kernel" (2025) https://jade.fyi/blog/misadventures-in-dtrace/ https://jade.fyi/blog/misadventures-in-dtrace/ : > My advice, and what I actually did, is to put macOS in a UTM.app VM with nothing of value in it, disable SIP in the VM, and do all further testing in there. > Once inside a VM with SIP disabled (or with dtrace enabled as a fine-grained policy), DTrace works. dtruss gives some output like the following: FWIU it is possible to trace Linux containers on Mac OS with e.g. cilium, only if the Linux containers are hosted in a Linux VM.