Skip to content

fix: bound OS threads stranded by checks on an unresponsive mount - #1654

Open
Looka149 wants to merge 1 commit into
juicedata:masterfrom
Looka149:fix/thread-leak-on-unresponsive-mount
Open

Looka149 wants to merge 1 commit into
juicedata:masterfrom
Looka149:fix/thread-leak-on-unresponsive-mount

Conversation

@Looka149

@Looka149 Looka149 commented Aug 19, 2026 •

Copy link
Copy Markdown
Contributor

Resolves #1653

DoPathWithTimeout is DoWithTimeout with a cap of 8 in-flight calls per path. Once a path reaches the cap, the next call returns an error instead of stranding another goroutine. A slot is freed when its call returns, so a mount that recovers needs no cleanup.

Applied to the 23 call sites that only read a path. umount stays uncapped, since it has to work on a mount whose checks are all stuck. GetDiskUsage had no timeout at all and now takes one.

Verified in kind with one hung mount and fd passing off, same base image one commit apart:

without the cap with the cap
OS threads 42 to 107 16 to 24
observed 372s, still increasing 906s, no further increase

A syscall on such a mount never returns and DoWithTimeout abandons the goroutine
that made it, so every retry strands one OS thread. DoPathWithTimeout refuses to
start a check once maxInflightPerPath calls on the same path are still running.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[BUG] Node plugin exits with fatal error: newosproc when a mount stops answering

1 participant