How to run a model in the background as a persistent service
Ollama installed, model already pulled to local library
What this does
Converts the Ollama server into a background service that remains available across terminal sessions, reboots, and logout events. After this guide the model API will be accessible without manual intervention.
Steps
Launch the Ollama server with nohup backgrounding. Detaches the process from the controlling terminal so it persists after logout.
nohup ollama serve > /tmp/ollama.log 2>&1 &Expected output: A process ID printed by the shell.
Verify the server is listening. Confirms the server is accepting connections on port 11434.
ss -tlnp | grep 11434Expected output: A line showing LISTEN state on port 11434 with the Ollama PID.
Set up a systemd service for automatic startup. Creates a unit file that survives reboots.
sudo tee /etc/systemd/system/ollama.service << 'EOF' [Unit] Description=Ollama Server After=network-online.target Wants=network-online.target
[Service] ExecStart=/usr/local/bin/ollama serve Environment=OLLAMA_HOST=0.0.0.0 Restart=always RestartSec=3
[Install] WantedBy=multi-user.target EOF
4. **Enable and start the service.** Reloads systemd configuration, enables auto-start, and launches the server.
```bash
sudo systemctl daemon-reload && sudo systemctl enable ollama && sudo systemctl start ollama
Expected output: No errors; systemctl status shows "active (running)".
Verification
curl http://localhost:11434/api/tags
# Expected: JSON array containing model entries with "name" and "size" fields
Common failures
address already in use- Port 11434 is occupied by another process; kill it withfuser -k 11434/tcp.Environment=OLLAMA_HOST ignored- Variable placed in wrong systemd section; must be under[Service].permission denied- User lacks write access to the log directory; use/tmp/ollama.logor adjust permissions.service starts then dies- ExecStart path is incorrect; verify withwhich ollama.
Operator checkpoint
Before treating this as solved, write down the local runtime, model or package version, hardware/backend if relevant, and the verification output. This keeps the guide useful as a Will-It-Run style decision instead of a one-off command transcript.