feat(build): ship netprobe eBPF object in the bundle + load it from the unit (#3425) #3486

Merged

mfreeman451 merged 2 commits from feat/netprobe-ebpf-object-delivery into staging

2026-06-01 04:29:35 +00:00

mfreeman451 commented

2026-06-01 03:56:02 +00:00

Owner

Summary

The missing piece for netprobe to actually capture as a delivered add-on. After the "Phase 3 eBPF cutover", rust/netprobe/src/main.rs refuses to start continuous capture without --ebpf-object, and IPC config can't enable it afterward — but neither the base-agent launch path nor the add-on bundle provisioned the object, so a delivered netprobe would boot in Disabled mode and never do flow→process attribution.

This ships the eBPF object with the bundle so it travels to the agent, and loads it from the unit.

Changes

defs.bzl: bundles now ship optional data_entries (runtime data files) flat next to the binary — same plumbing as manifest/unit entries.
addon_inventory.bzl: the netprobe bundle ships //rust/netprobe/ebpf:netprobe_ebpf_object as netprobe_ebpf.o (arch-independent CO-RE BPF bytecode — one object for both linux arches).
serviceradar-netprobe.service: ExecStart now passes --config (the agent-written bootstrap carrying the capture interfaces the eBPF runtime attaches to at startup, persisted across systemd restarts) and --ebpf-object pointing at the staged current/netprobe_ebpf.o.
netprobe_systemd_unit_test.go: pins the staged eBPF-object path to the verbatim-install staging layout alongside the binary.

Validation

darwin: Go contract test + gofmt clean; bazel query shows the netprobe bundle now depends on //rust/netprobe/ebpf:netprobe_ebpf_object + the unit; the assembler ships netprobe_ebpf.o flat at 0644 in the per-arch tarball next to the 0755 binary.

Linux box (sr-test-pve04, kernel 6.8, a live agent host): confirmed the real agent release-root is /var/lib/serviceradar/agent — matching the unit's hardcoded staging base. (An eBPF-object compile on the box is running as an extra check; the cross-compile + full bundle build are otherwise CI's job.)

Critical-path context

This unblocks capture. Remaining to actually run the eBPF flow→process test end-to-end: publish the netprobe bundle on Linux CI (the lane auto-includes it — push_all_native_addons picks up the auto-generated netprobe_addon_bundle_push, and the eBPF object builds as a bundle dependency) → import → approve → assign to a scratch agent rolled to a build that includes the §2.2 cutover (#3482/#3483) → it fetches/stages/setcaps/enables the unit → netprobe loads the object + captures. sr-test-pve04 is the natural scratch agent for that e2e.

🤖 Generated with Claude Code

## Summary The missing piece for netprobe to actually **capture** as a delivered add-on. After the "Phase 3 eBPF cutover", `rust/netprobe/src/main.rs` refuses to start continuous capture without `--ebpf-object`, and IPC config can't enable it afterward — but **neither the base-agent launch path nor the add-on bundle provisioned the object**, so a delivered netprobe would boot in `Disabled` mode and never do flow→process attribution. This ships the eBPF object *with* the bundle so it travels to the agent, and loads it from the unit. ## Changes - **`defs.bzl`**: bundles now ship optional **`data_entries`** (runtime data files) flat next to the binary — same plumbing as manifest/unit entries. - **`addon_inventory.bzl`**: the netprobe bundle ships `//rust/netprobe/ebpf:netprobe_ebpf_object` as `netprobe_ebpf.o` (arch-independent CO-RE BPF bytecode — one object for both linux arches). - **`serviceradar-netprobe.service`**: `ExecStart` now passes `--config` (the agent-written bootstrap carrying the capture interfaces the eBPF runtime attaches to at startup, persisted across systemd restarts) and `--ebpf-object` pointing at the staged `current/netprobe_ebpf.o`. - **`netprobe_systemd_unit_test.go`**: pins the staged eBPF-object path to the verbatim-install staging layout alongside the binary. ## Validation **darwin:** Go contract test + gofmt clean; `bazel query` shows the netprobe bundle now depends on `//rust/netprobe/ebpf:netprobe_ebpf_object` + the unit; the assembler ships `netprobe_ebpf.o` flat at 0644 in the per-arch tarball next to the 0755 binary. **Linux box (`sr-test-pve04`, kernel 6.8, a live agent host):** confirmed the real agent release-root is `/var/lib/serviceradar/agent` — matching the unit's hardcoded staging base. (An eBPF-object compile on the box is running as an extra check; the cross-compile + full bundle build are otherwise CI's job.) ## Critical-path context This unblocks **capture**. Remaining to actually run the eBPF flow→process test end-to-end: publish the netprobe bundle on Linux CI (the lane auto-includes it — `push_all_native_addons` picks up the auto-generated `netprobe_addon_bundle_push`, and the eBPF object builds as a bundle dependency) → import → approve → assign to a scratch agent **rolled to a build that includes the §2.2 cutover** (#3482/#3483) → it fetches/stages/setcaps/enables the unit → netprobe loads the object + captures. `sr-test-pve04` is the natural scratch agent for that e2e. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

mfreeman451 added 1 commit

2026-06-01 03:56:02 +00:00

feat(build): ship netprobe eBPF object in the bundle + load it from the unit (#3425 )

lint / lint (push) Successful in 1m33s

Details

Golang Tests / test-go (push) Successful in 2m6s

Details

Secret Scan / gitleaks (pull_request) Successful in 22s

Details

lint / lint (pull_request) Successful in 1m19s

Details

CI / build (pull_request) Failing after 4m14s

Details

27d883ab08

migrate-netprobe §1.3 follow-up — the missing piece for actual capture. After the
"Phase 3 eBPF cutover", netprobe's continuous capture refuses to start without
`--ebpf-object` (rust/netprobe/src/main.rs), and IPC config can't enable it later — yet
neither the base-agent launch path nor the add-on bundle provisioned the object. So a
delivered netprobe would boot in Disabled mode and never do flow->process attribution.

Deliver the eBPF object with the bundle so it travels to the agent:
- defs.bzl: bundles now ship optional `data_entries` (runtime data files) flat next to the
binary, same as manifest/unit entries.
- addon_inventory.bzl: the netprobe bundle ships `//rust/netprobe/ebpf:netprobe_ebpf_object`
as `netprobe_ebpf.o` (arch-independent CO-RE BPF bytecode, one object for both linux arches).
- serviceradar-netprobe.service: ExecStart now passes `--config` (the agent-written bootstrap
with the capture interfaces the eBPF runtime attaches to at startup) and `--ebpf-object`
pointing at the staged `current/netprobe_ebpf.o`.
- netprobe_systemd_unit_test.go: pins the staged eBPF-object path to the verbatim-install
staging layout alongside the binary.

Validation (darwin): Go contract test + gofmt clean; `bazel query` shows the netprobe bundle
now depends on `//rust/netprobe/ebpf:netprobe_ebpf_object` + the unit; the assembler ships
`netprobe_ebpf.o` flat at 0644 in the per-arch tarball next to the 0755 binary. The eBPF
object cross-compile + the full bundle build are Linux-only (validated on a Linux box).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

mfreeman451 reviewed

2026-06-01 04:03:42 +00:00

mfreeman451 left a comment

lgtm

mfreeman451 added 1 commit

2026-06-01 04:29:02 +00:00

Merge branch 'staging' into feat/netprobe-ebpf-object-delivery

Secret Scan / gitleaks (pull_request) Successful in 28s

Details

Rust Add-on Interop Test / interop (push) Successful in 1m50s

Details