[matthyx]

Summary

RuleManager.monitorContainer leaked one goroutine per container remove→add cycle that happened faster than its 5s polling ticker, because it re-derived its own liveness from shared mutable state instead of a registration-scoped signal. This gives each registration its own done channel so a goroutine can only be stopped by the removal that owns it.

Overview

RuleManager.monitorContainer used to re-derive its own liveness by polling rm.trackedContainers.Contains(k8sContainerID) on a 5s ticker instead of watching for its own registration's removal. If a container was removed and re-added faster than one tick, the stale goroutine's poll saw the ID "tracked again" (from the new Add) and looped forever, while ContainerCallback spawned a brand-new monitorContainer goroutine for the same ID — leaking one goroutine per such remove→add cycle, permanently, for the life of the process.

This gives each ContainerCallback EventTypeAddContainer its own scoped done chan struct{}, stored in a new RuleManager.trackedContainerDone map and passed directly into startRuleManager/monitorContainer as a parameter. monitorContainer now blocks on that channel (or rm.ctx.Done()) instead of polling shared state, and EventTypeRemoveContainer closes + clears the current registration's channel. Because the goroutine holds its channel via closure rather than re-reading a shared ID-keyed map at wake time, only the removal that owns a given registration can stop it — a sibling/later registration's channel has no effect on it. This closes the race structurally rather than narrowing the polling window, and also makes container-removal shutdown immediate instead of waiting up to 5s.

The now-unused syscallPeriod ticker and its container.Mntns == 0 debug check were removed along with the polling loop.

Additional Information

Added docs/features/rulemanager-monitor-container-lifecycle.md documenting the bug, the fix, and the observable behavior change.

How to Test

go test -race ./pkg/rulemanager/... -run 'TestMonitorContainer|TestContainerCallback' -v

New tests in pkg/rulemanager/containercallbacks_test.go:

• TestMonitorContainer_ExitsOnDoneChannel — exits when its own channel closes.
• TestMonitorContainer_IgnoresSiblingDoneChannel — does not exit when an unrelated channel closes.
• TestContainerCallback_FastRemoveAddDoesNotLeakGoroutine — reproduces the Add→Remove→Add race end-to-end through ContainerCallback and asserts the stale registration's channel is closed while the current registration's channel stays open and is a distinct channel.

Related issues/PRs:

• Fixes RuleManager.monitorContainer leaks a goroutine per container remove+add cycle faster than the 5s syscallTicker (TOCTOU on trackedContainers) #919

AI-skills: none | cmds: /oh-my-claudecode:autopilot

[coderabbitai]

Warning

Review limit reached

Next included review available in 57 minutes.

View limit details

Limit details: You’ve used the included review currently available.

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

Learn how review limits work.

Review configuration:

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: d10c2828-ddc1-4968-ac13-f79e65677309

📥 Commits

Reviewing files that changed from the base of the PR and between de4676b and 6ab4261.

📒 Files selected for processing (4)

• docs/features/rulemanager-monitor-container-lifecycle.md
• pkg/rulemanager/containercallbacks.go
• pkg/rulemanager/containercallbacks_test.go
• pkg/rulemanager/rule_manager.go

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/rulemanager-monitor-container-goroutine-leak-919

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

Performance Benchmark Results

Node-Agent Resource Usage

Metric	BEFORE	AFTER	Delta
Avg CPU (cores)	0.157	0.148	-5.7%
Peak CPU (cores)	0.164	0.154	-6.0%
Avg Memory (MiB)	333.147	272.233	-18.3%
Peak Memory (MiB)	335.398	278.984	-16.8%

Dedup Effectiveness

No data available.