[Bug] Linux: empty systemd scopes keep polling and stall the Web UI for over 100 seconds

[seoeaa]

Summary

On Linux, a long-running dsh web process accumulated 246 empty user-systemd scopes that remained ActiveState=active, TasksCurrent=0. The subprocess owner continued polling these scopes through systemctl show. A live CPU profile identified this polling path as the dominant sampled hotspot, while local HTTP requests and the Web UI were severely delayed.

Observed impact: root HTML frequently took approximately 12–15 seconds, and a fresh authenticated Chromium page took 115.5 seconds to render the UI. It initially remained on Loading plugins….

Reproduction / observed workload

1. Run @deepseek-ai/dsh@0.2.0-rc.2 with the Web profile on Linux with user systemd.
2. Keep the same host process running while agent sessions execute command tools and command-based PreToolUse hooks. The affected host had been running for approximately two days.
3. Inspect dsh-subprocess-<harness-pid>-*.scope units and their ActiveState and TasksCurrent.
4. When many empty active scopes have accumulated, open a fresh authenticated browser and time root/static/API requests.
5. Capture a short host CPU profile and inspect callers of querySystemctl.

This is an observed workload reproduction. The exact initial race/exit condition that first leaves a scope empty and active has not yet been reduced to a deterministic minimal reproducer. No plugin-free reproduction or runtime execution on alpha.1 is claimed.

Read-only commands for collecting the relevant systemd evidence:

systemctl --user list-units --all 'dsh-subprocess-<harness-pid>-*.scope'
systemctl --user show <one-listed-scope> --property=LoadState,ActiveState,TasksCurrent

Current behavior and measured evidence

Scope snapshot:

{
  "total_scopes": 247,
  "active_scopes_with_TasksCurrent_0": 246,
  "active_scopes_with_TasksCurrent_68": 1
}

The remaining populated scope was kept separate from the empty scopes; no cleanup or shutdown was performed during diagnosis.

CPU profile: 10,713 ms sampled duration, with 9,738 ms (90.9% of sampled time) in native spawn on this stack:

timer / waitForExit observation
  → SystemdScopeOwner.rangeActive
  → querySystemctl
  → child_process.execFile
  → child_process.spawn
  → native spawn

rangeActive queries LoadState, ActiveState, and TasksCurrent. Its polling loop backs off to a maximum of five seconds per owner, but hundreds of lingering owners still cause repeated process launches from the host.

HTTP/browser observations:

• Repeated authenticated root HTML requests: 13.01 s, 12.916 s, 11.933 s; another request took 14.591 s.
• Successful pluginInventory/list RPC: 6.808 s. All 190 enabled components were active; this was not a required-plugin startup failure.
• Fresh Chromium UI: 115,524 ms to the observed rendered controls; a preceding 65-second observation still showed Loading plugins….
• No JavaScript exceptions or failed HTTP requests were recorded during that browser observation. Some initial API requests were still pending when controls appeared.
• During a responsive interval, the same root returned in about 1 ms, and already-served plugin JS bundles in 1–11 ms. Therefore this is intermittent host-side starvation rather than consistently slow static-file transfer.
• Approximately 66.5 GiB of RAM was available, with no substantial CPU/IO pressure reported for the machine as a whole during the diagnostic snapshot.

The detailed local CPU profile, scope snapshot, browser observation, and HTTP measurements were preserved. The figures above are measured observations, not estimates from source inspection.

Investigation

The installed @deepseek-ai/dsh-subprocess-local file is byte-for-byte identical to the npm 0.2.0-rc.2 file. The npm 0.2.1-alpha.1 lib/index.js also matched that file during comparison; alpha.1 itself was not run.

In linux-scope.ts at the inspected upstream revision, emptyRange requires terminationRequested in addition to zero tasks and the existing direct-process/request-consumption check:

return this.terminationRequested && tasksCurrent === 0
  && (!this.direct.running() || !existsSync(this.startup.files.requestPath))

Consequently, an empty unit that remains active can keep its polling owner alive unless that termination flag was set. This condition is consistent with the accumulated scopes and observed profiler stack. The initial cause of those empty active units still needs investigation.

Expected behavior

Once a managed range is proven to have completed and cannot receive its initial payload later, its observation should end and any leftover empty transient scope should be released, including natural-completion paths. This must preserve the existing startup-race protection and must not stop scopes containing live tasks or background descendants.

The Web host should remain responsive independently of the number of command/hook invocations that have already completed. A restart may temporarily discard observers but does not address the lifecycle defect.

Environment

• Observed on 2026-10-09.
• @deepseek-ai/dsh: 0.2.0-rc.2.
• @deepseek-ai/dsh-subprocess-local: 0.2.0-rc.2, unmodified npm implementation.
• Node.js: v25.2.1.
• Ubuntu 24.04.3 LTS, x86_64; kernel 7.0.0-34-generic.
• systemd 255.4-1ubuntu8.17, user-systemd scopes.
• Web profile listening on loopback port 3080, with command-based PreToolUse hooks and additional plugins.

No provider requests, session contents, credentials, or local private logs are included in this report. The diagnosis did not modify the runtime or restart the host.

[skelviper]

I ran into similar Web UI performance issues and wanted to share my troubleshooting findings and a possible fix for reference.

Environment: Linux, DSH 0.2.1-rc.2.

Initially, the Web UI was extremely slow when accessed remotely, and sometimes failed to load entirely. After further investigation, I found that even requests to 127.0.0.1:3080 from the server itself were timing out.

I discovered 184 DSH scopes that were still marked as active despite having no running processes: TasksCurrent=0, populated=0 in the corresponding cgroups, and empty cgroup.procs files. DSH was continuously polling these scopes via systemctl.

After verifying and cleaning up these empty scopes, responsiveness improved significantly without restarting DSH. All 60 subsequent local requests succeeded, with a median response time of approximately 2 ms.

Looking through the code, I noticed that the existing cleanup condition for empty scopes depends on terminationRequested. In other words, this cleanup path is only triggered when termination has been explicitly requested. If a task finishes naturally but leaves behind an active, empty scope, DSH may continue polling it indefinitely.

I've prepared a small patch that removes the requirement for a prior termination request while preserving the following safeguards:

1. Before querying, either the direct client has already exited or the bootstrap process has read the launch request.
2. The query result explicitly confirms TasksCurrent === 0.
3. If background subprocesses are still running, or the process count is unknown, continue waiting.

I'm not an expert in this area, so please treat this patch as a suggestion rather than a definitive fix. Hopefully, it can serve as a useful reference.

dsh-empty-scope-source.patch