moca-egress: async bounded audit, and bounded conn_cap refusals per VM
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 48/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- go
- Domain
- backend, observability
Research direction
Read the #583 review discussion linked in the issue, then trace Audit.Emit, Unregister, abort(), and Close to see how audit writes interact with the proxy control socket. The issue proposes a bounded async audit queue with drop reporting, plus per-VM bounds and coalescing for conn_cap refusals. Done means audit stalls no longer block proxy operations and refusal handling stays bounded as described.
Written by the indexing model from the issue text.
Description
Follow-up from the #583 review (comment https://github.com/rossoctl/moca/pull/583#discussion_r4348544861), deferred out of that PR by agreement.
1. Cap refusals are unbounded. Each connection over MOCA_EGRESS_MAX_CONNS_PER_VM emits a conn_cap audit line and spawns a goroutine that holds the socket for up to ~2 s (writeAndClose: 1 s write plus 1 s drain). A guest connecting in a tight loop can:
- exhaust host-wide fds in this single shared process (
LimitNOFILE=65536); - flood stdout, so that journald's per-service rate limit (default 10000/30 s) drops other VMs' audit events.
Proposed: bound concurrent cap refusals per VM (close without drain on overflow), and coalesce conn_cap events per VM per interval.
2. Audit can stall the proxy. Audit.Emit writes synchronously to stdout and is called under pc.mu, including from abort() via Unregister. A stalled journald therefore blocks Unregister and Close, and with them the control socket. That contradicts the "auditing must not stall the proxy" comment.
Proposed: a bounded async queue with a drop counter, plus a periodic audit_dropped event when anything was dropped.
Related: #277, #583.
- Dominant language
- TypeScript
- Stars
- 4
- Forks
- 9
- Avg merge
- 9h 31m
- Merged PRs (30d)
- 139
Getting set up
- Ships a Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from rossoctl/moca
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 64/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Maintainers usually reply within 1 day
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
rossoctl/moca#421 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
Maintainers usually reply within 1 day
Similar issues
-
bug hacktoberfest help wanted
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
libredb/libredb-studio#1941 ·
Maintainers usually reply within 1 day
-
chore other
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
alastair-smith/card-games#308 ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 86/100
paperclipai/paperclip#17379 ·
Maintainers usually reply within 1 day
-
[good first issue, hacktoberfest] 🏯 Hacktoberfest Task - Add new Anime Quote 626 (good-first-issue)Opencommunity first-timers-only good first issue hacktoberfest help wanted low hanging fruit up-for-grabs
Difficulty 1/5 Under an hour Newbie friendliness 76/100
lingdojo/kana-dojo#33040 · 1 comment · 5 reactions ·
Maintainers usually reply within 1 day
-
bug mobile ui
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
Maintainers usually reply within 1 day