unslothai/unsloth · error · RuntimeError

Subprocess error: {error_msg}

Error message

Subprocess error: {error_msg}

What it means

Raised by _wait_response in the orchestrator when the inference subprocess replies with a response of type 'error' while the backend was waiting for some other expected response type. The message embeds the worker-side error string, so the real failure happened inside the subprocess (e.g. during model load, weight download, or generation) and is merely relayed here. It is a generic relay envelope, not a diagnosis itself.

Source

Thrown at studio/backend/core/inference/orchestrator.py:594

        while time.monotonic() < deadline:
            remaining = max(0.1, deadline - time.monotonic())
            resp = self._read_resp(timeout = min(remaining, 1.0))

            if resp is None:
                # Check subprocess health
                if not self._ensure_subprocess_alive():
                    raise RuntimeError(self._subprocess_crash_message("wait"))
                continue

            rtype = resp.get("type", "")

            if rtype == expected_type:
                return resp

            if rtype == "error":
                error_msg = resp.get("error", "Unknown error")
                raise RuntimeError(f"Subprocess error: {error_msg}")

            if rtype == "status":
                logger.info("Subprocess status: %s", resp.get("message", ""))
                # Reset deadline — subprocess is still alive and working
                deadline = time.monotonic() + timeout
                continue

            if rtype == "stall":
                msg = resp.get("message", "Download stalled")
                logger.warning("Subprocess reported stall: %s", msg)
                raise DownloadStallError(msg)

            # Other response types during wait — skip
            logger.debug(
                "Skipping response type '%s' while waiting for '%s'",
                rtype,
                expected_type,
            )

View on GitHub (pinned to 203007d190)

Solutions

1. Read the embedded error_msg — it names the actual worker-side exception; fix that root cause.
2. Check backend logs for the worker traceback that accompanied the subprocess 'error' response.
3. If the error mentions CUDA memory, unload other models / free VRAM and retry the load.
4. If it mentions missing files, verify the model snapshot under the HF cache and re-download.
5. As a last resort, restart the backend so the inference subprocess is respawned clean.

Example fix

// before
resp = orchestrator._wait_response("loaded", timeout=600)
// after
try:
    resp = orchestrator._wait_response("loaded", timeout=600)
except RuntimeError as e:
    if str(e).startswith("Subprocess error:"):
        logger.error("worker failed: %s", e)
    raise

try:
    orchestrator.load_model(name)
except RuntimeError as e:
    if str(e).startswith("Subprocess error:"):
        # worker-side failure; inspect embedded message and logs
        handle_worker_failure(e)
    raise

When it happens

Trigger: Any orchestrator command whose worker handler raises: load_model / generate / TTS requests that hit an exception in the subprocess and are answered with {'type': 'error', 'error': ...} instead of the expected 'loaded'/'audio_done' response.

Common situations: Corrupt or incompatible model weights, CUDA OOM inside the worker, missing model files on disk, an unsloth/transformers patch failing at load time, or a Python exception in worker-side generation code surfaced after a model switch.

Related errors

• Timeout waiting for '{expected_type}' response (no activity
• The current inference worker did not exit and still holds GP
• Inference subprocess is not running
• No export subprocess running
• Failed to send command to subprocess: {exc}

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