unslothai/unsloth · error · RuntimeError

installer timed out after {timeout_seconds}s

Error message

installer timed out after {timeout_seconds}s

What it means

Raised by the prebuilt-installer update flow after a watchdog timer fires and the installer subprocess is terminated. The flow runs the installer with a progress watchdog; when timed_out is set by the time proc.wait() returns, the job aborts with this RuntimeError naming the configured timeout_seconds. It indicates the installer process hung (e.g. stalled download, blocked prompt), not merely that it was slow.

Source

Thrown at studio/backend/utils/prebuilt/update_flow.py:411

                    announced.add(child_pid)
                else:
                    forget_pid(child_pid)
                    announced.discard(child_pid)
                continue
            m = PROGRESS_LINE_RE.search(line)
            if m is None:
                continue
            set_progress(min(float(m.group(1)) / 100.0, 1.0) * DOWNLOAD_PROGRESS_CEILING)
        returncode = proc.wait()
    finally:
        watchdog.cancel()
        if proc.poll() is not None:
            forget_pid(proc.pid)
        # Anything it started and never reported as stopped, whether it timed
        # out, exited nonzero, or died mid-line.
        _stop_announced()
    if timed_out.is_set():
        raise RuntimeError(f"installer timed out after {timeout_seconds}s")
    if returncode != 0:
        tail = "".join(tail_lines).strip()[-1500:]
        raise InstallerExit(returncode, f"installer exited {returncode}: {tail or 'no output'}")


def _new_phase_record(spec: dict) -> dict:
    """Initial breakdown entry for one phase of a chained job."""
    runnable = spec.get("run") is not None
    return {
        "state": PHASE_PENDING if runnable else PHASE_SKIPPED,
        "reason": None if runnable else spec.get("skip_reason"),
        "progress": None,
        "to_tag": None,
        "reload_required": None,
        "message": "",
        "error": None,
    }

View on GitHub (pinned to 203007d190)

Solutions

1. Check network connectivity/throughput to the installer download host and retry — transient stalls are the most common cause.
2. Inspect the captured tail_lines output logged just before the timeout to see where the installer stalled (progress percentage vs silent hang).
3. Increase timeout_seconds for the job if the artifact is legitimately large and the download is progressing (progress updates were advancing when killed).
4. On Windows, check whether antivirus/Defender is scanning the installer and exclude the studio install directory.

try:
    run_installer(spec)
except RuntimeError as e:
    if 'installer timed out' in str(e):
        log.warning('installer stalled; retrying once with fresh download')
        run_installer(spec, timeout_seconds=timeout_seconds * 2)
    else:
        raise

When it happens

Trigger: Running the prebuilt update flow where the installer subprocess exceeds timeout_seconds without exiting — the watchdog cancels and kills it, the finally block stops anything it announced (_stop_announced()), and this error propagates. Typical with a hung network connection mid-download or an installer waiting on interactive input.

Common situations: Slow or stalled network during a large model/runtime download, installer blocked on a prompt in a non-TTY environment, antivirus or disk I/O stalling the process on Windows, or a timeout_seconds configured too low for the payload size.

Understand the failure class

• Timeouts: ETIMEDOUT, deadlines, and hung requests — what actually expires when a request times out.

Related errors

• installer exited {returncode}: {tail or 'no output'}
• Timed out while installing the pinned {source_name} source
• Could not reach ChatGPT authentication.
• Timeout waiting for '{expected_type}' response (no activity
• llama-server embedder failed to become healthy. Last output:

AI-assisted analysis of unslothai/unsloth@203007d190 (2026-08-15). Data as JSON: /api/errors/e5fcbae4a14ce81e. Report an issue: GitHub.