[Bug] Linux: dsh-subprocess transient scopes accumulate and keep the user manager busy

[Kevin-McIsaac]

Environment

• dsh 0.2.2-rc.1, Node 24.19.0
• Debian 12 container under ChromeOS Crostini, kernel 6.6, systemd 252.36 (cgroup v1 hybrid)
• dsh web --no-open runs as a systemd --user unit (~/.config/systemd/user/dsh-web.service)

Summary

Each tool call creates a transient scope named dsh-subprocess-<server-pid>-<hash>.scope. On this host the scopes are not released. They stay active (running) after their command ends, and they survive the dsh server that created them. In about two days the user manager held 837 of them.

Observed

$ systemctl --user list-units --all | wc -l
940                      # 931 of 940 units reported active

$ systemctl --user list-units --type=scope --all | grep -c dsh-subprocess
837

$ systemctl --user show dsh-subprocess-3274-xxxx.scope -p LoadState -p ActiveState -p SubState
LoadState=loaded
ActiveState=active
SubState=running

The scope names carried server PIDs 3274, 6792, 17259, 18495 and 18898. Those servers had exited days earlier. The live server was PID 9142. So scopes from several dead server generations were still loaded and active.

Impact

The guest was not idle overnight. atop history shows systemd --user at about 20% of one core and the whole VM at about 0.6 cores, with no session active. The accumulated state also kept the host CPU out of its low-power states, so the host fan ran all night on an otherwise idle machine.

Workaround

systemctl --user stop 'dsh-subprocess-*.scope'

This released 844 units in one step. Loaded units fell from 940 to 93, and a 12 second /proc/stat sample fell from 0.66 to 0.06 busy cores. systemd --user then reported 0.0% in top.

Reproduction

1. Run dsh web from a systemd --user service on systemd 252.
2. Let the Linux native provider select the user-scope launch.
3. Use the agent normally for a day, then restart the service.
4. Count the dsh-subprocess-*.scope units. Scopes from old server PIDs remain loaded and active.

Code note

SystemdScopeOwner already has emptyRange() and releaseEmptyRange(), and systemd-run is called with --collect. For these units the release did not run. The owner was gone (server restart), or the unit never made the populated-to-empty transition. --collect only collects units that reach inactive or failed, so such a unit stays active.

Suggested fix

• Stop the scope when the owning provider disposes, including on server shutdown.
• At startup, stop every dsh-subprocess-<pid>-*.scope whose <pid> is not the current server. The PID in the unit name makes this cheap.
• Consider RuntimeMaxSec as a backstop.

I can reproduce on request and provide atop samples, systemctl show output, or a debug log.