Troubleshooting — Server Will Not Start

The message on the server row is classified, not generic. Find yours below.

First: read the log

Show Log on the row. The log is the authoritative account; the row’s message is a classification of it. The panel stays open across a status change, so open it before starting.

Out of memory

GPU ran out of memory while loading the model.

In order of likelihood:

1. Another process holds VRAM. Check the Dashboard’s GPU panel — a previous engine that did not exit, or someone’s notebook. Lifeboat sizes against live free memory, so that memory is genuinely gone.
2. Another Lifeboat server took the card. The engine pre-allocates its cache to whatever ceiling it is given, so a generous first server does not leave room for a second. Put both on Auto and restart them. See Memory and sizing.
3. Too many server rows. Lifeboat reserves memory for servers that might start, capped at 40% of the card. Three stale or duplicate rows can hold back a quarter of the GPU. Delete rows you do not use.
4. It genuinely does not fit. Reduce context length, use a quantized checkpoint, or raise tensor parallelism if you have another GPU.

insufficient_shared_memory

Only with tensor parallelism above 1. The GPUs communicate through /dev/shm and the container’s default is too small.

Raise LIFEBOAT_SHM_SIZE (or shmSize in Helm) and recreate the container — it is fixed at creation and a restart will not do it. Automatic restarts are disabled for this failure, because retrying cannot succeed.

Lifeboat checks this before launching, which is why you get this message instead of an unexplained “NCCL unhandled system error”.

gpu_incompatible

The GPU is older than the engine supports. Not fixable by configuration; retries are disabled.

model_too_large

Refused before launch, based on live free VRAM rather than the card’s nameplate. Free memory, reduce context length, or use a smaller or quantized model.

Skipped for GGUF servers, which stream layers and can legitimately run a model larger than VRAM.

unsupported_model

The model cannot be served as it is:

• A sharded GGUF on the tensor engine — merge it into one file first.
• A GGUF architecture neither engine implements.
• Speculative decoding configured without a draft model for an algorithm that requires one.

A parser the model cannot support

a reasoning parser is configured, but this model’s tokenizer does not encode the think-end token as a single token

Clear Reasoning Parser and Tool Call Parser in Advanced. They only shape generated text and are never right for an embedding or reranker model — which is where this most often appears.

invalid_extra_args

Something in Extra Arguments is malformed. The field is split like a shell command line, so JSON must be in single quotes — otherwise the double quotes are stripped and the engine dies with a bare parse error naming nothing useful.

llamacpp_load_failed

The GGUF engine could not load the file: a corrupt or unsupported quantization, a sharded set missing shards, or a vision model whose projector is missing or mismatched. The server log carries the engine’s own error line.

llamacpp_remote_unsupported

GGUF servers run on the control-plane node only. Deploy it locally.

port_in_use

Something else holds the port. Pick another, or stop what holds it.

402 license_required

Not a server fault. The 24-hour grace period elapsed and no licence is active. The console keeps working — activate from the License page. See Licensing.

It says “starting” and never finishes

Usually correct. The engine loads weights and then captures execution graphs, which takes minutes on a large model and logs a line per shape. Lifeboat only treats it as stuck after 15 minutes and 5 minutes of silence in the log.

Open the log. If lines are still appearing, it is working.

Windows, pip package only

Three failures are specific to pip install lifeboat on Windows. None applies to the desktop installer or the container image.

OSError: [WinError 87] — the console will not start

File "...\control_plane\server_manager.py", in _is_alive
    os.kill(pid, 0)
OSError: [WinError 87] The parameter is incorrect
ERROR:    Application startup failed. Exiting.

While starting, the control plane checks whether each server it knows about is still alive. It uses a POSIX idiom that is invalid on Windows, so once a server has been started successfully, the console cannot start again — every attempt exits here, including on a fresh pip install that inherits an existing data directory.

There is no setting that avoids it. Either leave lifeboat up running rather than restarting it, or clear the data directory and begin again:

Remove-Item -Recurse -Force $env:LOCALAPPDATA\Lifeboat

Your model is not affected: the engine keeps serving on its own port. It is the console that stops.

UnicodeEncodeError — the console will not start

Set PYTHONIOENCODING=utf-8 before lifeboat up. See pip Quickstart → Windows.

PermissionError on a .dll during lifeboat engine install

PermissionError: [Errno 13] Permission denied:
  '...\Lifeboat\engines\llama.cpp\ggml-vulkan.dll'

An engine from an earlier run is still executing out of that folder, and Windows will not let the unpack overwrite a loaded DLL. The download succeeds and the extraction fails part way, which can leave the engine directory half written.

Get-Process llama-server -ErrorAction SilentlyContinue | Stop-Process -Force

Then run lifeboat engine install again. Check lifeboat doctor first — if the GGUF engine line already shows a path and usable, you do not need to reinstall it at all.

Sources and references

• Lifecycle: Server lifecycle
• Sizing: Memory and sizing
• Embedding models: Embedding and reranker servers