agent hit a timeout when it tried to run remote update install

TL;DR

Remote installs and exec timeouts are fundamentally mismatched: a cumulative update can run 45 minutes, while SSH and WinRM defaults assume commands finish in minutes. Decouple launch from wait: start the install as a detached job on the host (nohup, a scheduled task, or the patch tool own agent), return immediately with a job handle, and poll a status file or the service state until completion.

agent hit a timeout when it tried to run remote update install

Use this when

• The agent logs a timeout on the install step, then marks the host failed, but the update is installed when checked later.
• Worse, killed sessions leave dpkg or the Windows installer in a broken state.
• Small updates succeed; only large cumulative updates or service packs time out.

Not for this skill when

• The install truly hangs (no progress in its own log). Detaching will not fix a hung installer; that is a host problem.
• The timeout is on a quick probe command. That indicates host overload, not a long install.

Steps

1. Measure real install durations per patch class from host logs. Verify: you have a duration range showing installs exceeding the exec timeout
2. Change the launch pattern: write a small runner script to the host that starts the install detached, logs to a known file, and writes an exit-code file on completion. Verify: the launch command returns in seconds with the job started
3. Poll the exit-code file or the log tail at intervals with a deadline based on the measured worst case. Verify: the agent observes completion and reads the real exit code
4. Make the poll crash-safe: if the agent restarts, it can find the job state file and reattach. Verify: a mid-install agent restart still resolves the host correctly
5. Apply the same detached pattern to other long steps (reboots excluded; they have their own flow). Verify: no exec call in the wave has a duration expectation over the channel timeout

Variant phrasings

remote install longer than ssh timeout detach and poll

The pattern phrasing.

winrm timeout cumulative update install agent

The Windows variant phrasing.

nohup install job exit code file polling agent

The Linux implementation phrasing.

Compatibility: Compatibility: SSH and WinRM exec channels; Windows pattern uses scheduled tasks or the built-in update agent, Linux uses nohup or systemd-run.

Why it happens

Exec channels are request-response tools built for short commands, and their timeouts exist to catch hangs. A patch install is neither short nor hung, so the timeout fires spuriously. Worse, killing the session can orphan the installer or interrupt it mid-transaction, converting a slow success into a real failure. Detach-and-poll aligns the agent model with how the work actually runs.

Edge cases / pitfalls

• systemd-run with a transient unit is cleaner than nohup on modern Linux: it survives session teardown and gives you status and logs through journalctl.
• On Windows, prefer triggering the native update agent or a scheduled task over a remote interactive installer for the same detach reason.
• Poll intervals of 30 to 60 seconds are plenty; aggressive polling adds load to a host already busy installing.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_xtw-9N4qJdThflV8qPb6fw