Summary
After upgrading to rmux 0.5.0, interactive panes become extremely laggy once I start a multi-pane / multi-agent CLI workload. The lag tracks rmux daemon FD growth, not worker CPU.
I suspect a PTY/FD leak (or missed PTY cleanup) in the attached daemon path under fork/exec-heavy pane activity.
Environment
- OS: Ubuntu 24.04
rmux: 0.5.0- comparison baseline:
tmux 3.4 on the same host
What I observe
On the problematic daemon (/tmp/rmux-1000/default), rmux currently has:
- 1 session / 2 panes
- about 15.7k open FDs
- almost all of them
/dev/ptmx
- about 845 MB RSS
- about 28% CPU
At a previous worse point on the same machine, I also observed:
- about 29k
/dev/ptmx
- about 1.5 GB RSS
- about 66% CPU
When this happens, Codex/OpenCode inside rmux becomes very laggy.
For comparison, I ran a similar 1 leader + 4 worker concurrent workload in tmux on the same host:
tmux server stayed at 26 open FDs- 15 PTY-related FDs
- about 57 MB RSS
- no lag
A useful contrast inside rmux itself
Another rmux daemon on the same host (/tmp/rmux-1000/cursor-pts-4) is healthy at the same time:
- 1 session / 5 panes
- 34 open FDs
- 17
/dev/ptmx
- about 122 MB RSS
So this does not look like a simple more panes => more FDs relationship. It looks more like something specific to the attached/default daemon path or PTY cleanup over time.
Workload shape
I have not reduced this to a pure minimal repro yet, but the workload has these characteristics:
- multiple panes
- long-lived attached session
- frequent shell helper / subprocess churn
- repeated pane observation / polling / task dispatch
- split/attach/detach style interaction
The accumulation becomes much worse once multi-agent orchestration starts.
Extra note
It also seems easier to trigger/persist when unrelated top-level sessions reuse the same default socket (/tmp/rmux-1000/default). I worked around that locally with per-TTY sockets, but that only reduces blast radius; it does not explain the PTY growth itself.
Question
Does this sound like a known issue in 0.5.0? If helpful, I can try to build a smaller reproduction focused on repeated pane activity / attach-detach / subprocess churn.
Summary
After upgrading to
rmux 0.5.0, interactive panes become extremely laggy once I start a multi-pane / multi-agent CLI workload. The lag tracksrmuxdaemon FD growth, not worker CPU.I suspect a PTY/FD leak (or missed PTY cleanup) in the attached daemon path under fork/exec-heavy pane activity.
Environment
rmux: 0.5.0tmux 3.4on the same hostWhat I observe
On the problematic daemon (
/tmp/rmux-1000/default),rmuxcurrently has:/dev/ptmxAt a previous worse point on the same machine, I also observed:
/dev/ptmxWhen this happens, Codex/OpenCode inside
rmuxbecomes very laggy.For comparison, I ran a similar
1 leader + 4 workerconcurrent workload intmuxon the same host:tmuxserver stayed at 26 open FDsA useful contrast inside
rmuxitselfAnother
rmuxdaemon on the same host (/tmp/rmux-1000/cursor-pts-4) is healthy at the same time:/dev/ptmxSo this does not look like a simple
more panes => more FDsrelationship. It looks more like something specific to the attached/default daemon path or PTY cleanup over time.Workload shape
I have not reduced this to a pure minimal repro yet, but the workload has these characteristics:
The accumulation becomes much worse once multi-agent orchestration starts.
Extra note
It also seems easier to trigger/persist when unrelated top-level sessions reuse the same default socket (
/tmp/rmux-1000/default). I worked around that locally with per-TTY sockets, but that only reduces blast radius; it does not explain the PTY growth itself.Question
Does this sound like a known issue in
0.5.0? If helpful, I can try to build a smaller reproduction focused on repeated pane activity / attach-detach / subprocess churn.