Ollama не запускается: причины и решение

MAATRIX

ollama run отвечает Error: could not connect to ollama app, is it running?, а systemctl status ollama светится красным. Причин, по которым Ollama не стартует, ровно пять, и различаются они за минуту — по коду выхода в журнале systemd. Ниже — как отличить занятый порт от OOM-kill, сломанные права от слетевшего драйвера, и что делать в каждом случае.

Сначала журнал, потом конфиги

Под «не запускается» скрываются три состояния. Пока не знаете, какое у вас, правка конфига — гадание. Три команды:

systemctl is-active ollama
sudo journalctl -u ollama -n 80 --no-pager
sudo ss -ltnp 'sport = :11434'

Состояние A — failed. Процесс не поднялся вообще. В systemctl status ollama:

Active: failed (Result: exit-code) since Wed 2026-08-26 11:04:12 UTC; 8s ago
Process: 1841 ExecStart=/usr/local/bin/ollama serve (code=exited, status=1/FAILURE)

Половина диагноза — в поле status=. 1/FAILURE — процесс стартовал и вышел сам, текст ошибки строкой выше. 203/EXEC — systemd не нашёл бинарник. 217/USER — нет пользователя, под которым запускаться. 9/KILL — процесс убили извне, почти всегда OOM-killer ядра.

Состояние B — active (running), но ollama list отдаёт could not connect to ollama app. Сервис жив, это проблема адреса — разбор ниже, в абзаце про OLLAMA_HOST.

Состояние C — вечный рестарт. В штатном юните стоит Restart=always: упавший процесс поднимается каждые 3 секунды, в журнале копится Scheduled restart job, restart counter is at 14. Сервис вроде «работает», но ни один запрос не доживает до ответа.

Проверка живости в одну строку — curl -s http://127.0.0.1:11434/api/version. Ответ вида {"version":"0.12.11"} — сервер поднят и слушает, curl: (7) Failed to connect to 127.0.0.1 port 11434 — нет.

Порт 11434 уже занят

Самая частая причина status=1/FAILURE. В журнале — одна строка:

Error: listen tcp 127.0.0.1:11434: bind: address already in use

Ollama не делит порт: занят — сервер молча выходит с кодом 1. Занимают его забытый в tmux ollama serve, контейнер docker run -d -p 11434:11434 ollama/ollama или второй юнит, если ставили и скриптом, и пакетом дистрибутива. Кто держит порт, покажет ss:

State  Recv-Q Send-Q  Local Address:Port  Peer Address:Port Process
LISTEN 0      4096      127.0.0.1:11434        0.0.0.0:*    users:(("ollama",pid=1462,fd=3))

Дальше ps -o pid,user,cmd -p 1462 скажет, чей это процесс, а docker ps --filter publish=11434 — не контейнер ли. Решение: оставить один экземпляр — sudo systemctl stop ollama, pkill -f "ollama serve", sudo systemctl start ollama. Если два инстанса нужны намеренно, второму задайте OLLAMA_HOST=127.0.0.1:11435 и свой OLLAMA_MODELS — иначе подерутся и за каталог моделей.

Грабля с OLLAMA_HOST. Переменная управляет и сервером, и клиентом. Прописали export OLLAMA_HOST=0.0.0.0:11434 в ~/.bashrc, чтобы открыть сервер наружу, — и ollama list в той же сессии пойдёт на 0.0.0.0 как на адрес назначения, выдав could not connect при живом сервисе. Серверу адрес задают в юните, шеллу оставляют 127.0.0.1:11434.

Пользователь, путь к бинарнику и права на модели

status=217/USER, в журнале Failed to determine user credentials: No such process. Юнит запускает User=ollama, а такого пользователя нет: перенесли юнит с другой машины или ставили из tgz руками. Создайте его так же, как установщик:

sudo useradd -r -s /bin/false -U -m -d /usr/share/ollama ollama
sudo systemctl daemon-reload && sudo systemctl restart ollama

status=203/EXEC, в журнале Failed to locate executable /usr/local/bin/ollama: No such file or directory. Официальный скрипт кладёт бинарник в /usr/local/bin/ollama, пакеты дистрибутива — в /usr/bin/ollama; сверьте command -v ollama с ExecStart.

Права на каталог моделей. Модели живут в /usr/share/ollama/.ollama/models и принадлежат ollama:ollama. Классика: качали модель под root, часть блобов осталась с владельцем root, и сервис получает:

Error: open /usr/share/ollama/.ollama/models/manifests/registry.ollama.ai/library/llama3.1/latest: permission denied

Лечится строкой sudo chown -R ollama:ollama /usr/share/ollama/.ollama.

Та же история при переносе моделей на отдельный диск. Переменные задавайте не в /etc/systemd/system/ollama.service, а через drop-in: sudo systemctl edit ollama открывает /etc/systemd/system/ollama.service.d/override.conf:

[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"
Environment="OLLAMA_MODELS=/mnt/models"
Environment="OLLAMA_MAX_LOADED_MODELS=1"

Потом sudo chown -R ollama:ollama /mnt/models, sudo systemctl daemon-reload, sudo systemctl restart ollama. Почему drop-in: install.sh перезаписывает основной юнит при каждом обновлении, и переменные тихо исчезают, а override.conf он не трогает. Если на AlmaLinux или Rocky permission denied вылезает там, где ls -l выглядит правильно, виноват SELinux: sudo ausearch -m avc -ts recent | grep -i ollama.

Вечный рестарт: память и место на диске

code=killed, status=9/KILL, рядом ollama.service: Failed with result 'oom-kill'. Тут важна тонкость: сам ollama serve занимает при старте 30–60 МБ и поднимается на любой машине. Память съедает загрузка весов при первом запросе, и ядро убивает дочерний процесс-раннер. Со стороны это и выглядит как «сервис не стартует». Подтверждение — в журнале ядра: sudo dmesg -T | grep -i "killed process".

[Wed Aug 26 12:41:07 2026] Out of memory: Killed process 20431 (ollama) total-vm:9871264kB, anon-rss:6203108kB

anon-rss — сколько процесс успел занять перед смертью. 6,2 ГБ — ровно вес llama3.1:8b в Q4_K_M: Ollama не сломана, машине не хватило памяти под конкретную модель. Арифметика: размер файла из ollama list плюс 10–15% на KV-кэш при контексте 4k плюс гигабайт системе.

Что делать:

• взять модель меньше: ollama run llama3.2:3b — около 2 ГБ вместо 6;
• урезать контекст: Environment="OLLAMA_CONTEXT_LENGTH=2048" или /set parameter num_ctx 2048;
• добавить swap: sudo fallocate -l 8G /swapfile && sudo chmod 600 /swapfile && sudo mkswap /swapfile && sudo swapon /swapfile.

Честно про swap: от OOM-kill спасёт, от тормозов — нет. Модель, часть весов которой ушла в своп даже на NVMe, выдаёт доли токена в секунду. Дожить до апгрейда годится, как постоянная конфигурация — нет.

Второй сценарий вечного рестарта — кончившееся место:

Error: write /usr/share/ollama/.ollama/models/blobs/sha256-8eeb52dfb3bb-partial: no space left on device

Проверьте df -h /usr/share/ollama. Неочевидное: слой качается во временный файл -partial рядом с целевым, то есть нужно место под блоб и под копию. На диске 20 ГБ модель весом 9 ГБ может не влезть, хотя формально «свободно 11 ГБ». Место освобождает ollama rm, раздутый журнал — sudo journalctl --vacuum-size=200M.

GPU: сервис живой, а карты нет

Ещё один вид «не запустилось»: сервис active (running), а в журнале:

level=WARN source=gpu.go msg="error looking up nvidia GPU memory"
level=INFO source=routes.go msg="no compatible GPUs were discovered"

Всё считается на CPU. Если вы платите за GPU, это тот же сбой, только молчаливый. Первая проверка — nvidia-smi, классика после апдейта ядра:

Failed to initialize NVML: Driver/library version mismatch

Модуль ядра остался от старой версии драйвера, юзерспейс уехал вперёд; обычно лечится перезагрузкой. Если нет — sudo dkms status, ожидаемая строка вида nvidia/580.65.06, 6.8.0-79-generic, x86_64: installed. Не installed — модуль не собрался под новое ядро: sudo apt install --reinstall linux-headers-$(uname -r) nvidia-dkms-580.

Вторая проверка — перезапускали ли Ollama после установки драйверов: железо она опрашивает один раз при старте и в рантайме карту не подхватит. После рестарта в журнале должна появиться строка inference compute с именем карты и объёмом вида total="24.0 GiB". Третья — Docker: контейнер падает с could not select device driver "nvidia" with capabilities: [[gpu]], если не прописан nvidia-container-toolkit. Чинится парой sudo nvidia-ctk runtime configure --runtime=docker и sudo systemctl restart docker, запуск — обязательно с --gpus=all.

На CPU-серверах проверьте ещё AVX: grep -o 'avx[0-9_]*' /proc/cpuinfo | sort -u. Без него Ollama берёт базовый раннер — запускается, но считает заметно медленнее, а это уже другая тема.

Docker и тип виртуализации

В контейнере всё иначе: docker ps -a показывает Restarting (1) 4 seconds ago, systemd ни при чём, смотрите docker logs --tail 50 ollama. Три типовые причины:

• Лимит памяти контейнера. --memory=4g при модели на 6 ГБ даёт Error: llama runner process has terminated: signal: killed. Контейнерный OOM виден в dmesg, но systemctl status про него не знает; упор в лимит показывает docker stats.
• Не та архитектура образа. exec /bin/ollama: exec format error — amd64-образ на ARM-сервере или наоборот; лечится явным docker pull --platform linux/arm64 ollama/ollama.
• Права на том. При bind-mount -v /opt/ollama:/root/.ollama каталог на хосте принадлежит не тому пользователю: mkdir /root/.ollama: permission denied. Именованный том этим не болеет.

Отдельно — тип виртуализации, про который редко пишут, а решает всё: systemd-detect-virt. Ответ kvm — нормально. lxc или openvz означают контейнерный VPS, и здесь Ollama ведёт себя непредсказуемо:

• установщик падает на System has not been booted with systemd as init system (PID 1). Can't operate. — юнит ставить некуда, ollama serve придётся держать под supervisor, без автозапуска после ребута;
• /proc/meminfo показывает память ноды, а не ваш лимит: Ollama считает, что памяти вагон, грузит модель и ловит kill от cgroup — в логах ни слова о нехватке;
• на части конфигураций ломается отображение весов в память: error loading model: failed to mmap.

Вывод: под Ollama берите KVM или выделенный сервер — на контейнерном VPS вы чините не Ollama, а чужой гипервизор.

Какая конфигурация нужна под Ollama и где её брать

Больше половины случаев «Ollama не стартует» — не софт, а машина не под задачу. Вот честные цифры.

Минимум для модели 3B в Q4 — 2 vCPU, 8 ГБ RAM, 40 ГБ NVMe: стартует и отвечает, годится для прототипа. Скорость на CPU — единицы токенов в секунду.

Рабочий минимум для 8B в Q4 — 4 vCPU, 16 ГБ RAM, 80–100 ГБ NVMe. Именно на 8 ГБ и ловят oom-kill: 6,2 ГБ весов плюс контекст плюс система в восьмёрку не влезают, хотя формально «модель весит 4,7 ГБ». Диск считайте с запасом на -partial-копию.

Комфортный вариант — 8 vCPU, 32 ГБ RAM, от 200 ГБ NVMe: несколько моделей на диске и длинный контекст без свопа. Нужна не терпимая, а нормальная скорость — GPU с 16–24 ГБ VRAM, та же 8B ускоряется в десятки раз. Требования по моделям — в таблице RAM для Ollama.

Виртуализация у MAATRIX — KVM: /proc/meminfo показывает вашу память, systemd работает как положено, install.sh отрабатывает штатно и юнит встаёт с автозапуском — класс проблем из предыдущего раздела просто не возникает.

Локация — Лондон, и причина практическая: из российских сетей установка регулярно виснет на строке >>> Downloading Linux amd64 bundle и отваливается по curl: (28) Failed to connect to github.com port 443 after 130002 ms: Connection timed out, а пятигигабайтный слой модели обрывается на середине. С лондонской площадки реестр Ollama и релизы GitHub тянутся на полной скорости канала. Пинг до ЕС минимальный, сервер в GDPR-периметре — важно, если через модель проходят рабочие документы; из Москвы 40–60 мс, для чата незаметно. Если персональные данные обязаны оставаться в РФ, есть российская площадка.

Оплата — картой российского банка, по СБП, криптой или токеном MAAT. Разворачивается из готового образа с уже поднятым юнитом, дальше — собрать стек локальной LLM или разобраться, почему интерфейс не видит Ollama.

Частые вопросы