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.

Sources and references

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