Skip to content

feat(pssh): support inactivity_timeout in exec_cmd_list - #318

Open
speriaswamy-amd wants to merge 3 commits into
speriaswamy/xdit-04-pssh-session-retryfrom
speriaswamy/xdit-05-pssh-inactivity-timeout
Open

feat(pssh): support inactivity_timeout in exec_cmd_list#318
speriaswamy-amd wants to merge 3 commits into
speriaswamy/xdit-04-pssh-session-retryfrom
speriaswamy/xdit-05-pssh-inactivity-timeout

Conversation

@speriaswamy-amd

Copy link
Copy Markdown
Contributor

Part 5 of 12 in a stack that replaces #184. Base: #317.

Why

exec() already accepts inactivity_timeout (a per-line silence timer). timeout is parallel-ssh's read_timeout — a total wall-clock cap that activity does not reset. exec_cmd_list only 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_list accepts inactivity_timeout and disables read_timeout when it is set.
  • MultiProcessPssh.exec_cmd_list threads it through both the direct and the sharded worker path, so behaviour is identical regardless of host count.
  • Docstring spells out the difference between the two parameters.

Defaults to None; existing timeout callers are unaffected.

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. Happy to add one here if reviewers want it before merge.

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>
Comment thread cvs/lib/parallel/pssh.py
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.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

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.

2 participants