feat(pssh): support inactivity_timeout in exec_cmd_list - #318
Open
speriaswamy-amd wants to merge 3 commits into
Open
feat(pssh): support inactivity_timeout in exec_cmd_list#318speriaswamy-amd wants to merge 3 commits into
speriaswamy-amd wants to merge 3 commits into
Conversation
exec() already accepts inactivity_timeout (a per-line silence timer, as opposed to timeout, which is parallel-ssh's read_timeout — a total wall-clock cap that activity does not reset). exec_cmd_list did not, so callers running different long commands per host had only the total cap available. That distinction matters for benchmark workloads: a run that legitimately takes 40 minutes but prints progress throughout is indistinguishable from a hang under a total cap, so the cap has to be set to the worst plausible runtime and a genuine hang then burns that full budget. Adds the parameter to Pssh.exec_cmd_list and threads it through MultiProcessPssh.exec_cmd_list on both the direct and sharded paths, so the behaviour is the same regardless of host count. Existing timeout callers are unaffected — the new parameter defaults to None. Known gap: no unit test covers the exec_cmd_list inactivity path specifically (the underlying per-line timer in _process_output is already exercised via exec). Worth adding before merge if reviewers want it in this PR. Co-Authored-By: Claude <noreply@anthropic.com>
…-pssh-inactivity-timeout (bring branch up to date)
amd-droy
reviewed
Aug 18, 2026
| command may run arbitrarily long as long as it keeps producing output, and | ||
| is aborted only after inactivity_timeout seconds of silence. When | ||
| inactivity_timeout is set, the underlying read_timeout is disabled so there | ||
| is no total cap. Pass at most one of the two. |
Contributor
There was a problem hiding this comment.
Docstring says “Pass at most one of the two,” but if a caller passes both, inactivity_timeout silently wins and timeout is ignored. Consider either validating and raising ValueError, or adding a one-line note that inactivity_timeout takes precedence when both are set.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Part 5 of 12 in a stack that replaces #184. Base: #317.
Why
exec()already acceptsinactivity_timeout(a per-line silence timer).timeoutis parallel-ssh'sread_timeout— a total wall-clock cap that activity does not reset.exec_cmd_listonly had the latter, so callers running long per-host commands had no way to distinguish "still working" from "hung": the cap has to be set to the worst plausible runtime, and a genuine hang then burns that entire budget.What changed
Pssh.exec_cmd_listacceptsinactivity_timeoutand disablesread_timeoutwhen it is set.MultiProcessPssh.exec_cmd_listthreads it through both the direct and the sharded worker path, so behaviour is identical regardless of host count.Defaults to
None; existingtimeoutcallers are unaffected.Known gap
No unit test covers the
exec_cmd_listinactivity path specifically — the underlying per-line timer in_process_outputis already exercised viaexec. Happy to add one here if reviewers want it before merge.