Oct 13, 2026

Ollama "bind: address already in use" on Port 11434? Stop Killing Processes and Read This First (2026)

Q: Why does the error come back 3 seconds after I kill the process?

That's systemd's `Restart=always` + `RestartSec=3` doing its job. Stop the service with `sudo systemctl stop ollama` instead of killing the process.

By RunAIHome Team · 11 min read

ollamatroubleshootinglocal-llmhome-serverai

TL;DR: bind: address already in use means an Ollama server (or something else) is already listening on port 11434 — on Linux that’s almost always the systemd service the installer set up, which you never needed to bypass with ollama serve. Check with ollama list first: if it answers, your server is fine and the error is noise. Only when a second instance or another app genuinely holds the port do you stop the service properly or move Ollama with OLLAMA_HOST.

What you’ll be able to do:

Tell in one command whether the “conflict” is actually a working server you can just use
Find and stop whatever holds port 11434 on Linux, macOS, Windows, and Docker — without the kill-respawn loop systemd puts you in
Move Ollama to another port or expose it on your LAN the supported way, so the error never comes back

Honest take: this is the rare error that usually means nothing is wrong. The Linux installer enables Ollama as an always-on service, so ollama serve in a terminal is guaranteed to collide with it. Nine times out of ten the fix is to close your terminal and keep using the server that was already running.

You type ollama serve and get:

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

On Windows the same failure reads:

Error: listen tcp 127.0.0.1:11434: bind: Only one usage of each socket
address (protocol/network address/port) is normally permitted.

And if you’re starting Ollama in Docker, it surfaces one layer up:

Error starting userland proxy: listen tcp4 0.0.0.0:11434: bind: address already in use

All three say the same thing: port 11434 — Ollama’s default, bound to 127.0.0.1 (official FAQ) — already has a listener, so the new server you’re launching can’t start. People have been filing this since issue #707 in December 2023, and it’s common enough that the Linux README’s port-conflict section got its own documentation fix. The error is real, but the usual reaction — hunt down the process and kill -9 it — is wrong more often than it’s right.

Why a fresh install hits this immediately

On Linux, the official install script does three things that matter here, all visible in install.sh: it writes a systemd unit to /etc/systemd/system/ollama.service with ExecStart=/usr/bin/ollama serve, runs systemctl enable ollama, and restarts the service as its final act before exiting. The unit it writes carries Restart=always and RestartSec=3 (Linux docs).

So the moment the installer finishes, a server is already running, owns port 11434, and starts again at every boot. The ollama serve command that half the tutorials on the internet tell you to run next has nowhere to bind. That’s the whole bug.

Restart=always is also why the kill-first instinct backfires: kill the service’s process and systemd respawns it within 3 seconds, usually fast enough to reclaim the port before your manual ollama serve gets there — or worse, just after, so now the service is the one logging bind errors on a loop.

The desktop apps behave the same way. On macOS and Windows, installing Ollama puts it in the menu bar / system tray and registers it to start at login, server included. As of Ollama v0.40.3 (released October 11, 2026, releases page), the macOS app doesn’t yet tell you when a port conflict is why it’s stuck on “Loading…” — the fix for that is still an open pull request, #16619. Until it merges, the app can sit there silently while a leftover server holds the port.

First check: do you even have a problem?

Before touching any process, ask the existing listener who it is:

ollama list

If that prints your models, a healthy Ollama server is already up — the CLI just connected to it. ollama run, ollama pull, Open WebUI, and anything else pointed at http://localhost:11434 will work right now. You never needed ollama serve; it’s only for running the server by hand in a foreground terminal, which the service already does for you. Close the terminal and move on.

You can confirm over HTTP, too:

curl http://localhost:11434
# Ollama is running

If instead you get a connection refused or something that clearly isn’t Ollama answers, then you have a genuine squatter on the port. Identify it:

# Linux
sudo ss -ltnp | grep 11434
# or
sudo lsof -i :11434

# macOS
sudo lsof -i :11434

# Windows (PowerShell or cmd)
netstat -ano | findstr 11434
tasklist /FI "PID eq <PID-from-netstat>"

Typical healthy output, from a real report (issue #7540):

COMMAND PID   USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
ollama  226 ollama    3u  IPv4  25003      0t0  TCP localhost:11434 (LISTEN)

A process named ollama running as user ollama is the systemd service. A process with your username is a manual ollama serve you (or a script) left running. Anything else — another app chose the same port — skip to moving Ollama below.

Pick your fix by what’s holding the port

What `lsof`/`netstat` shows	What it is	The fix
`ollama` process, user `ollama`	The systemd service, working as designed	Use it — don’t run `ollama serve` at all
`ollama` process, your user	A stray manual `ollama serve`	Kill that one process, then use the service
`ollama` on macOS/Windows, no terminal open	The desktop app’s built-in server	Quit/use the app, not a second server
`docker-proxy` or a container	A container already publishing 11434	Stop the container or remap its port
Anything else	Unrelated app on 11434	Move Ollama to another port

Linux: stop the service properly, or don’t fight it

If you genuinely need the port free — say you want to run ollama serve in the foreground to watch debug output — stop the service through systemd so it doesn’t respawn:

sudo systemctl stop ollama      # frees the port until next boot
sudo systemctl disable ollama   # also stops it coming back at boot
ollama serve                    # now binds cleanly

systemctl stop is the piece most guides skip; pkill ollama alone loses the race against RestartSec=3. When you’re done debugging, hand the port back: sudo systemctl start ollama.

macOS: one server, pick which

Quit the menu bar app (click the llama icon → Quit Ollama) to free the port, or keep the app and simply don’t run ollama serve. If you installed via Homebrew as a service, the equivalent is brew services stop ollama. Remember the silent-conflict caveat above: an app stuck on “Loading…” after an update is, until PR #16619 ships, exactly what a port conflict looks like on macOS — run lsof -i :11434 before reinstalling anything.

Windows: the tray app got there first

Ollama autostarts at login, so by the time you open a terminal the port is taken. Right-click the tray icon → Quit Ollama, confirm with netstat -ano | findstr 11434 (no output = port free), then run what you wanted. If a zombie ollama.exe survives the quit, end it by PID:

taskkill /PID <PID> /F

To stop it claiming the port at every login: Task Manager → Startup apps → Ollama → Disable.

Docker: you’re running Ollama twice

The userland proxy variant means the host port 11434 is taken while Docker tries to publish a container on it. In issue #7540 that was a native Ollama service running on the same WSL2 host as a docker compose Ollama container — two servers, one port. Either stop the native one (sudo systemctl stop ollama) or publish the container somewhere else:

docker run -d -p 11435:11434 --name ollama ollama/ollama

Inside the container Ollama still binds 11434; your clients on the host now use http://localhost:11435. Running two Ollama containers has the same rule: each needs its own host port.

The 0.0.0.0 trap: the error echoes what you asked for, not what’s listening

A detail that costs people real time, documented in issue #14963: the bind error prints the address you requested, not the address of the process blocking you. A user with the service on the default 127.0.0.1:11434 ran OLLAMA_HOST=0.0.0.0 ollama serve and got:

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

Seeing 0.0.0.0 in the error, they assumed their LAN-exposure setting had taken effect somewhere and went looking for the wrong problem. It hadn’t — binding all interfaces includes loopback, so the service’s 127.0.0.1 listener blocks a 0.0.0.0 bind on the same port. The issue was closed without a behavior change in March 2026, so current builds still report it this way.

The practical rule: if you want Ollama reachable from other machines, don’t start a second server with OLLAMA_HOST=0.0.0.0. Reconfigure the one you have, the way the FAQ specifies:

# Linux
sudo systemctl edit ollama.service
# add under [Service]:
#   Environment="OLLAMA_HOST=0.0.0.0:11434"
sudo systemctl daemon-reload
sudo systemctl restart ollama

# macOS
launchctl setenv OLLAMA_HOST "0.0.0.0:11434"
# then quit and reopen the Ollama app

On Windows, set OLLAMA_HOST as a user environment variable (quit Ollama from the tray first, Settings → search “environment variables” → add it for your account, then relaunch from the Start menu).

Moving Ollama to a different port

Same mechanism, different value — there is no OLLAMA_PORT variable, despite what a few guides claim; the port rides along in OLLAMA_HOST as host:port (FAQ, and a longstanding ask in issue #2194):

Environment="OLLAMA_HOST=127.0.0.1:11435"

One catch: the CLI reads the same variable to find the server. With the service moved to 11435, a bare ollama list in a fresh shell still looks at 11434 and reports the server down. Match them:

OLLAMA_HOST=127.0.0.1:11435 ollama list
# or export it in your shell profile

Every client — Open WebUI, Continue, scripts using the API — needs the new port, too. That’s the price of dodging a conflict by moving; it’s usually cheaper to evict whatever else wandered onto 11434, since nothing else has a standing claim to it.

FAQ

Is it safe to just ignore the error if ollama run works? Yes — with one caveat. If models run, a server is up and serving. But make sure the server that’s up is the version and configuration you think it is: a stale manual ollama serve from before an update keeps running the old binary until it’s killed. ollama -v prints both client and server versions; if they disagree, restart the service.

Why does the error come back 3 seconds after I kill the process? That’s systemd’s Restart=always + RestartSec=3 doing its job. Stop the service with sudo systemctl stop ollama instead of killing the process.

Does kill -9 corrupt anything? No model files, no. But it skips graceful shutdown, and whatever was mid-generation is gone. There’s also no point: use systemctl stop (Linux), Quit (macOS/Windows tray), or docker stop and the port is released cleanly.

Can two Ollama servers share one machine? Yes, on different ports — e.g., the service on 11434 and a test build with OLLAMA_HOST=127.0.0.1:11435 ollama serve. Each loads its own copy of any model it runs, so VRAM is the real limit; if one instance keeps evicting the other’s models, that’s a different problem — see our model-reloading fix.

I freed the port, and now ollama run says it can’t connect. You stopped the only server. Start it again (sudo systemctl start ollama, or launch the app) — or run ollama serve in a terminal and leave it open. If the server is up but models fail to load or run on CPU, that’s beyond port binding: start with Ollama not using the GPU or the llama-runner timeout.

Sources

Last updated October 13, 2026. Commands verified against Ollama v0.40.3 documentation and the issues linked above; behavior may change in later releases.

Was this article helpful?

Get the numbers before you buy

New GPU and mini-PC benchmarks, VRAM thresholds, and price checks — sent when there's something worth acting on, not on a schedule. No spam, unsubscribe anytime.