[savvyadmin] 0:home1:processes2:recipes3:explain4:archive linux & server reference since 2007
david@web-1:~$ man ollama

OLLAMA(7) Savvy Admin Process Reference OLLAMA(7)

NAME

ollama — Local LLM server: ollama serve loads models on demand and answers an unauthenticated HTTP API on 127.0.0.1:11434 by default; whoever can reach that port can run models, and read or feed them anything.

kind: ai agent · package: ollama (install script → /usr/local/bin/ollama; on systemd hosts the installer also creates the ollama user and ollama.service) · binary: ollama — one static binary; ollama serve is the server, every other subcommand is a client talking to it over HTTP · config: /etc/systemd/system/ollama.service (Environment= lines, edit with systemctl edit ollama.service), /usr/share/ollama/.ollama/models (service install), ~/.ollama/ (keys and models for a server you start by hand) · updated 2026-10-20

docs last verified 2026-10-20 — 0 days ago

SAFE TO KILL?

VERDICT A normal daemon: systemctl stop ollama or kill -TERM ends it cleanly; in-flight generations are lost, nothing on disk is harmed. If memory is the problem, unload the model with ollama stop <model> and keep the server; if the port is the problem, fix OLLAMA_HOST, because the process will come back on the next systemd restart with the same bind.

SYMPTOMS

· RSS of several GB and every core busy: a model is loaded and generating; ollama ps names it, and it stays resident for keep_alive (5 minutes by default) after the last request
· port 11434 listening on 0.0.0.0 or *: OLLAMA_HOST was set to expose it, and the API has no authentication of its own
· GPU memory stays allocated after use: the model is parked until keep_alive expires or ollama stop unloads it

WHAT IT CAN DO

Run any model you pulled, with your files as context if a client sends them. The API is plain HTTP without auth: /api/version, /api/tags, /api/generate, /api/chat and the OpenAI-compatible /v1 routes. Exposure is decided entirely by OLLAMA_HOST (default 127.0.0.1:11434) and by OLLAMA_ORIGINS for browser clients (127.0.0.1 and 0.0.0.0 allowed by default). Models live under OLLAMA_MODELS; OLLAMA_KEEP_ALIVE sets how long a model stays in memory.

LISTENS ON

11434/tcp default bind 127.0.0.1 — OLLAMA_HOST=0.0.0.0:11434 opens it to every interface; the API has no authentication

DIAGNOSE

$ ss -tlnp | grep 11434 127.0.0.1:11434 is the default and means local clients only; 0.0.0.0:11434 or *:11434 means every interface, with no authentication in front$ ollama ps which models are loaded, their size, whether they run on CPU or GPU, and when they expire (UNTIL)$ curl -s http://127.0.0.1:11434/api/version is the server answering, and which version; {"version":"0.40.6"} at the time of writing$ ps -eo pid,user,rss,etime,comm,args | grep -E '[o]llama' which user runs it (ollama for the service install, you for a hand-started one) and how much memory the server plus the loaded model take$ systemctl cat ollama the unit file and any Environment= overrides, which is where an OLLAMA_HOST=0.0.0.0 usually hides

FIX

1. Unload a model without stopping the server. Frees RAM or VRAM immediately. OLLAMA_KEEP_ALIVE in the unit's Environment= changes the default idle time (a duration such as 10m, 0 to unload at once, a negative value to keep a model loaded for good).

$ ollama stop llama3.2

2. Move the model store off the system disk. Set OLLAMA_MODELS to the new directory in the service environment; with the standard Linux install the ollama user must own it: sudo chown -R ollama:ollama <directory>.

HARDEN

1. Keep it on loopback. Make sure the override contains no OLLAMA_HOST=0.0.0.0 line, or set Environment="OLLAMA_HOST=127.0.0.1:11434" explicitly, then systemctl daemon-reload and systemctl restart ollama. ss -tlnp | grep 11434 must show 127.0.0.1.

$ sudo systemctl edit ollama.service

2. If other machines need it, put authentication in front, not a wider bind. A reverse proxy with auth, an SSH tunnel, or Tailscale between the client and 127.0.0.1:11434 keeps the API private; the docs themselves list ngrok and Cloudflare Tunnel as the ways to expose it. If you do bind to the LAN, restrict the port to the client addresses in the firewall.

3. Watch what reaches it from browsers. OLLAMA_ORIGINS widens the CORS allowlist; the default is 127.0.0.1 and 0.0.0.0. Adding chrome-extension://* or * means any page in your browser can drive the server.

4. Run it as the ollama user, not yourself. The installer's systemd unit already does that. A hand-started ollama serve under your account exposes your home directory to whatever a client sends as context.

IMPOSTORS

$ readlink /proc/$(pgrep -x ollama | head -1)/exe the installer puts the binary at /usr/local/bin/ollama; a process called ollama running from /tmp, /dev/shm or a dot-directory is a miner that borrowed a believable name for a GPU hog$ ollama --version prints the server (and client) version; a fake has nothing to say

DISTRIBUTIONS

any curl -fsSL https://ollama.com/install.sh | sh installs /usr/local/bin/ollama and, on systemd hosts, a service running as the ollama user with models under /usr/share/ollama/.ollama/models. The script needs zstd; without systemd (containers, WSL without systemd) it leaves you to start ollama serve yourself, and models then go to ~/.ollama.

APPLIES TO

Ollama 0.4x on Linux (checked against the FAQ and a fresh install on 2026-10-20).

SEE ALSO

SOURCES

1. Ollama docs — FAQ (OLLAMA_HOST, OLLAMA_ORIGINS, OLLAMA_MODELS, keep_alive, ollama ps), fetched 2026-10-20
2. Ollama Linux install script, fetched 2026-10-20
Machine-readable: /process/ollama.json · changelog 2026-10-20: first version; the installer now requires zstd and, without systemd, creates neither the ollama user nor the unit

Ubuntu 26.04 · Ollama 0.40.6 via install.sh (serve, ss, /api/version, ollama ps, OLLAMA_HOST bind test) 2026-10-20 OLLAMA(7)
Manual page ollama(7) (END)