Ollama Service: systemd starten und prüfen

TL;DR

Der Ollama Service ist unter Linux die systemd-Unit ollama.service. Die Herstellerdoku legt sie unter /etc/systemd/system/ollama.service an, startet ollama serve als User ollama und empfiehlt Restart=always. Danach daemon-reload, enable, start und status. Logs: journalctl -e -u ollama. Variablen wie OLLAMA_HOST gehören in systemctl edit ollama oder in /etc/systemd/system/ollama.service.d/override.conf. Gelesen in Linux-Doku und FAQ am 2026-10-09. Windows und macOS nutzen keinen systemd-Dienst.

Dienst, Binary und Container sind drei Schichten

IT-Leiter suchen „ollama service“, wenn der Prozess nach dem Boot fehlt, nach einem Update nicht mehr läuft oder systemctl status rot ist — nicht, wenn nur die Binary fehlt. Die Erstinstallation bleibt auf Ollama unter Ubuntu und Ollama Download. Das Nachziehen der Engine steht in Ollama Update. Dieser Text behandelt nur den Linux-Dienst.

Kein Weg ist ein Ranking. Dieselbe API auf Port 11434, nur der Startmechanismus unterscheidet sich.

Unit anlegen (manueller Linux-Pfad)

Die Linux-Dokumentation, Abschnitt „Adding Ollama as a startup service (recommended)“. Zuerst User und Gruppe:

sudo useradd -r -s /bin/false -U -m -d /usr/share/ollama ollama
sudo usermod -a -G ollama $(whoami)

Dann die Datei /etc/systemd/system/ollama.service — Wortlaut der Doku:

[Unit]
Description=Ollama Service
After=network-online.target

[Service]
ExecStart=/usr/bin/ollama serve
User=ollama
Group=ollama
Restart=always
RestartSec=3
Environment="PATH=$PATH"

[Install]
WantedBy=multi-user.target

Restart=always und RestartSec=3 stehen in dieser Unit. Das ist kein SLA und keine Verfügbarkeitszusage, nur der Restart-Block der Vorlage. WantedBy=multi-user.target hängt den Dienst an den normalen Multi-User-Boot.

Das Installationsskript curl -fsSL https://ollama.com/install.sh | sh richtet den Dienst in der Regel mit ein. Der manuelle Block gilt, wenn Sie den Tarball nach /usr entpackt haben und ollama serve sonst nur in einer interaktiven Shell läuft.

Enable, Start, Status

Dieselbe Linux-Seite, direkt nach der Unit:

sudo systemctl daemon-reload
sudo systemctl enable ollama

Start und Prüfung stehen im Abschnitt „Start Ollama“:

sudo systemctl start ollama
sudo systemctl status ollama

enable setzt den Autostart. start hebt den Prozess jetzt. Ohne daemon-reload nach einer neuen Unit-Datei sieht systemd die Datei nicht. status muss active (running) zeigen, sonst ist der nächste Schritt das Journal, nicht ein zweites Installationsskript.

Logs der Startup-Service-Variante:

journalctl -e -u ollama

Das steht unter „Viewing logs“. -e springt ans Ende. Filter nach einem Zeitpunkt mit --since, wenn Sie nur den letzten Restart sehen wollen — das ist systemd-Handwerk, keine Ollama-Sonderoption.

Override statt Unit überschreiben

Anpassungen gehören nicht in die von einem späteren Installer überschriebene Hauptdatei. Die Doku nennt zwei Wege.

systemctl edit ollama öffnet den Editor. Die FAQ (Linux) verlangt danach:

[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"

systemctl daemon-reload
systemctl restart ollama

Oder die Datei /etc/systemd/system/ollama.service.d/override.conf von Hand. Das Beispiel der Linux-Doku setzt Debug, nicht den Host:

[Service]
Environment="OLLAMA_DEBUG=1"

Standard laut FAQ: Ollama bindet 127.0.0.1:11434. OLLAMA_HOST ändert Bind-Adresse und Port. Firewall, LAN-Freigabe und der Hinweis, dass der lokale Server keine eingebaute Anmeldung mitbringt, stehen in Ollama Port 11434. Hier nur der Dienst-Hebel.

Weitere Variablen aus derselben FAQ, ebenfalls über Environment= im Override, wenn Sie sie brauchen:

• OLLAMA_MODELS — anderes Modellverzeichnis. Der User ollama braucht Schreibrecht; die FAQ nennt sudo chown -R ollama:ollama auf das Ziel.
• OLLAMA_KEEP_ALIVE — wie lange ein Modell im Speicher bleibt. Ohne Override gilt laut FAQ fünf Minuten.
• OLLAMA_CONTEXT_LENGTH — Standard laut FAQ 4096 Token.
• OLLAMA_NO_CLOUD=1 — Cloud-Funktionen aus, siehe FAQ.

Das sind Dokumentationswerte vom 2026-10-09, keine Betriebs-SLA.

Modelle liegen unter Linux laut FAQ in /usr/share/ollama/.ollama/models — passend zum Home /usr/share/ollama aus useradd. Ein Dienst, der als User ollama läuft, sieht genau dieses Verzeichnis. Ein ollama serve in Ihrer eigenen Shell nutzt ~/.ollama Ihres Login-Users. Zwei Verzeichnisse, eine typische „Modelle weg“-Falle.

Docker und Desktop sind nicht diese Unit

Docker startet das Image, nicht ollama.service auf dem Host. Compose und GPU-Passthrough stehen in Ollama Docker. systemctl status ollama auf dem Host ist dann leer oder zeigt eine zweite, unerwünschte Instanz — beide wollen Port 11434.

Windows und macOS: Die FAQ beschreibt Login-Items und die Tray- bzw. Menüleisten-App, nicht systemd. Autostart abschalten über „Startup apps“ (Windows) bzw. „Login Items“ (macOS). WSL2 kann die Linux-Unit im Distro-systemd haben; das ist der Linux-Pfad, nicht die Windows-App. GPU unter Windows bleibt Ollama Windows GPU.

Clients gegen einen laufenden Dienst: Ollama Python. Ohne active (running) liefert der Client einen Verbindungsfehler, kein stilles Fallback.

Dienst entfernen

Linux-Doku, Abschnitt Uninstall — nur der Service-Teil:

sudo systemctl stop ollama
sudo systemctl disable ollama
sudo rm /etc/systemd/system/ollama.service

Danach Binary, Bibliotheken, User, Gruppe und /usr/share/ollama nur, wenn Sie Ollama wirklich deinstallieren. rm auf das Modellverzeichnis löscht die Gewichte. Ein reiner Dienst-Neustart braucht das nicht.

Override-Dateien unter ollama.service.d/ nach dem Löschen der Unit ebenfalls entfernen, sonst bleibt ein totes Drop-in liegen.

Typische Brüche

Unit geschrieben, kein daemon-reload. systemd kennt die Datei nicht. status bleibt „not-found“.

enable ohne start. Nach dem nächsten Boot ist der Dienst da. Jetzt fehlt er, bis Sie start ausführen oder neu booten.

ollama serve in einer SSH-Session und zusätzlich die Unit. Beide wollen 11434. Eine Instanz beenden.

Override in der Hauptdatei statt systemctl edit. Das nächste Installationsskript kann die Unit ersetzen. Drop-in bleibt.

Dienst läuft, Client spricht den falschen User-Pfad an. Modelle liegen beim User ollama. ollama list als root oder als anderer User ohne Gruppenmitgliedschaft wirkt leer.

Docker und Host-Unit parallel. Dieselbe API-Adresse, zwei Prozesse. Eine Seite stoppen.

FAQ

Reicht ollama serve statt des Dienstes?

Für einen Test in der aktuellen Shell ja. Nach Logout oder Reboot ist der Prozess weg. Die Doku markiert die Startup-Service-Variante als empfohlen.

Ändert der Dienst den Port von selbst?

Nein. Bind-Adresse bleibt OLLAMA_HOST. Ohne Override gilt 127.0.0.1:11434.

Wo sehe ich, dass systemd den Prozess neu gestartet hat?

journalctl -u ollama und systemctl status ollama. Restart=always in der Unit erklärt kurze Lücken nach einem Absturz, nicht die Ursache.

Kann ich den Dienst auf eine feste Binary-Version halten?

Die Version setzt das Installationsskript über OLLAMA_VERSION, nicht die Unit. Ablauf in Ollama Update. Die Unit zeigt weiter auf /usr/bin/ollama.

Müssen Modelle nach einem Dienst-Neustart neu gezogen werden?

Die gelesene Doku beschreibt das nicht. Vorhandene Blobs bleiben unter /usr/share/ollama/.ollama/models, solange Sie das Verzeichnis und OLLAMA_MODELS nicht ändern. Nach dem Start hält die FAQ Modelle standardmäßig fünf Minuten im Speicher; ein leerer Generate-Request lädt ein Modell vor.

Fazit

„Ollama Service“ ist unter Linux die systemd-Unit: User ollama, ollama serve, enable plus start, Prüfung über status und journalctl. Overrides für Host und Modellpfad, nicht die Hauptdatei überschreiben. Docker und die Desktop-Apps sind andere Startwege. Hardware-Kauf gehört nicht in diesen Schritt.