OllamaをsystemdでサービスとしてLinuxに常時起動させる方法|override.confで本番運用する

宮崎智広 この記事の監修:宮崎智広(Linux実務・教育歴20年以上・受講者3,100名超)
HOMELinux技術 リナックスマスター.JP(Linuxマスター.JP)ローカルLLM > OllamaをsystemdでサービスとしてLinuxに常時起動させる方法|override.confで本番運用する
「Ollamaを再起動のたびに手動で起動し直しているが、無人運用にしたい」
「systemctl editでoverride.confを書けると聞いたが、[Service]セクションの書き方がわからない」

そんな悩みを抱える常時起動・無人運用したいインフラ屋・サーバー管理者は多いはずです。この記事では、OllamaをLinuxのsystemdサービスとして恒久化し、override.confを使ってリッスンアドレス・モデル保存先・起動パラメータを本番向けに制御する手順を解説します。デフォルトのユニットファイルの構造確認から、OLLAMA_HOST・OLLAMA_MODELSの設定方法、journalctlによるトラブルシュートまでをカバーします。

この記事のポイント

・sudo systemctl edit ollama でoverride.confを作成しデフォルト設定を上書きできる
・Environment="OLLAMA_HOST=0.0.0.0:11434" でLAN全体にAPIを公開できる
・OLLAMA_MODELSでモデル保存先を専用ストレージに分離してディスク管理を独立させる
・起動失敗時は journalctl -u ollama -n 50 でログを確認するのが最初の一手


OllamaをsystemdでサービスとしてLinuxに常時起動させる方法|override.confで本番運用する

「このままじゃマズい」と感じていませんか?
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
図解60P/登録10秒/解除も3秒 / 詳細はこちら

なぜOllamaをsystemdサービス化するのか

Ollamaの公式インストールスクリプト(`curl -fsSL https://ollama.com/install.sh | sh`)を実行すると、`ollama.service` というsystemdユニットファイルが自動作成され、サーバー再起動後も自動起動する状態になります。しかしデフォルト設定のままでは本番運用に不十分なケースが多い。

主な不満ポイントを整理します。
・デフォルトはlocalhost(127.0.0.1)のみリッスン。チーム共有サーバーや別サービスからのAPI呼び出しができない
・モデルの保存先がOllamaシステムユーザーのホームディレクトリ固定。大容量モデルをOSボリュームに積みたくない
・`Restart=always` の動作確認や再起動タイミングのチューニングをしていない
・ログの出力先が把握できておらず、障害時に確認できない

これらを解決するのが、systemdの「Drop-In」設定ファイル(override.conf)です。デフォルトのユニットファイルを直接編集すると、Ollamaのアップデート時に設定が上書きされるリスクがあります。override.confを使えばユニットファイルに手を加えずに設定を追加・上書きできるため、アップデート耐性のある構成が実現できます。

なお、Ubuntu Server上でのOllama初期構築(インストール・ファイアウォール・外部公開設計)については Ubuntu ServerでローカルLLMを構築する方法|Ollamaで機密データを外に出さず業務AIを動かす完全ガイド で解説しています。本記事はそのsystemd設定を深掘りします。

デフォルトのsystemdユニットファイルを確認する

設定をカスタマイズする前に、デフォルトのユニットファイルの中身を把握しておきます。override.confは「デフォルトに何かを追加・上書きするファイル」です。まずデフォルトを把握することが、設定ミスを防ぐ最初の一歩になります。

1. ユニットファイルの場所と内容を確認する

`systemctl cat` コマンドを使うと、ユニットファイルの内容をそのまま表示できます。

# Ollamaのsystemdユニットファイルを確認 $ systemctl cat ollama # /etc/systemd/system/ollama.service [Unit] Description=Ollama Service After=network-online.target [Service] ExecStart=/usr/local/bin/ollama serve User=ollama Group=ollama Restart=always RestartSec=3 Environment="PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" Environment="HOME=/usr/share/ollama" [Install] WantedBy=default.target

各設定の意味を整理します。
・`User=ollama` / `Group=ollama`:専用のシステムユーザーとして動作する(root権限不要)
・`Restart=always`:クラッシュ時や手動停止時も自動で再起動する
・`RestartSec=3`:再起動前に3秒待機する
・`Environment="HOME=/usr/share/ollama"`:Ollamaユーザーのホームディレクトリ。デフォルトではこの下の `.ollama/models/` にモデルが保存される

2. サービスの現在の状態を確認する

# サービスの稼働状態と自動起動設定を確認 $ systemctl status ollama * ollama.service - Ollama Service Loaded: loaded (/etc/systemd/system/ollama.service; enabled; preset: enabled) Active: active (running) since Mon 2026-06-22 08:00:00 JST; 1h 30min ago Main PID: 1234 (ollama) Tasks: 12 (limit: 9517) Memory: 1.2 G CGroup: /system.slice/ollama.service └─1234 /usr/local/bin/ollama serve # 自動起動が有効かどうか確認 $ systemctl is-enabled ollama enabled

`Loaded:` 行に `enabled` が表示されていれば、サーバー再起動後も自動起動します。`disabled` の場合は `sudo systemctl enable ollama` で有効化してください。`Active: active (running)` が正常稼働状態です。

systemctl edit でoverride.confを作成する手順

override.confはsystemdの「Drop-In」という仕組みを使います。`systemctl edit ollama` を実行すると `/etc/systemd/system/ollama.service.d/override.conf` が自動的に作成・編集されます。デフォルトのユニットファイルと合わせて読み込まれ、override.confの設定が優先されます。

1. systemctl edit ollama を実行する

# override.confを新規作成・編集する(sudoが必要) $ sudo systemctl edit ollama

このコマンドを実行するとデフォルトのエディタ(通常はnano)が開き、`/etc/systemd/system/ollama.service.d/override.conf` の編集画面になります。ファイルが存在しない場合は新規作成されます。vimを使いたい場合は環境変数で指定します。

# vimを使う場合(SYSTEMD_EDITORを指定) $ sudo SYSTEMD_EDITOR=vim systemctl edit ollama

2. override.confに設定を記述する

エディタが開いたら以下の形式で記述します。`[Service]` セクションヘッダーは必須です。省略するとsystemdがセクションを認識できずエラーになります。

# override.confの記述例(エディタに入力する内容) [Service] Environment="OLLAMA_HOST=0.0.0.0:11434" Environment="OLLAMA_MODELS=/data/ollama/models"

`Environment=` 行は1変数1行で記述します。複数の環境変数を設定する場合は行を追加します。ダブルクォートで囲む形式(`Environment="KEY=VALUE"`)が正式な書き方です。クォートを省略すると後述のパースエラーの原因になります。

3. daemon-reloadしてサービスを再起動する

ファイルを保存してエディタを閉じたら、systemdに変更を認識させてOllamaを再起動します。

# systemdの設定を再読み込み $ sudo systemctl daemon-reload # Ollamaサービスを再起動 $ sudo systemctl restart ollama # 環境変数が反映されているか確認 $ systemctl show ollama | grep -i environment Environment=PATH=... HOME=/usr/share/ollama OLLAMA_HOST=0.0.0.0:11434 OLLAMA_MODELS=/data/ollama/models

`systemctl show ollama | grep -i environment` の出力に設定した環境変数が含まれていれば、override.confが正しく読み込まれています。設定全体を確認したい場合は `systemctl cat ollama` でデフォルトのユニットファイルとoverride.confの内容をまとめて表示できます。

# ユニットファイルとoverride.confを一括確認 $ systemctl cat ollama # /etc/systemd/system/ollama.service [Unit] ...(デフォルトの内容) # /etc/systemd/system/ollama.service.d/override.conf [Service] Environment="OLLAMA_HOST=0.0.0.0:11434" Environment="OLLAMA_MODELS=/data/ollama/models"

OLLAMA_HOSTでリッスンアドレスを変更する

デフォルトのOllamaは `127.0.0.1:11434` のみでリッスンします。同一サーバー上のクライアントからしかAPIを呼べません。チーム共有サーバーとして使う場合や、DockerコンテナやKubernetes Podからのリクエストを受け付ける場合は、リッスンアドレスを変更する必要があります。

1. リッスンアドレスを全インターフェースに変更する

# override.confの[Service]セクションに追記(sudo systemctl edit ollamaで開く) [Service] Environment="OLLAMA_HOST=0.0.0.0:11434"

`0.0.0.0` を指定すると、サーバーのすべてのネットワークインターフェースでリッスンします。特定のIPアドレスのみに限定する場合は `Environment="OLLAMA_HOST=192.168.1.100:11434"` のように指定します。設定反映後、別ホストからの疎通確認をします。

# 同一ホスト上で起動確認 $ curl http://localhost:11434 Ollama is running # 別ホストから確認(192.168.1.100 がOllamaサーバーのIPアドレス) $ curl http://192.168.1.100:11434 Ollama is running # REST APIでモデルにリクエストを送信 $ curl http://192.168.1.100:11434/api/generate \ -d '{"model":"gemma3:4b","prompt":"Linuxのjournalctlコマンドの基本は?","stream":false}' {"model":"gemma3:4b","response":"journalctlはsystemdのジャーナルを参照するコマンドです..."}

2. UFWでポートを開放する

`OLLAMA_HOST=0.0.0.0:11434` を設定しても、UFW(Uncomplicated Firewall)が有効な場合はポートを別途開ける必要があります。

# UFWで11434ポートを許可(全IPから) $ sudo ufw allow 11434/tcp Rule added Rule added (v6) # セキュアな設定:社内サブネットからのみ許可 $ sudo ufw allow from 192.168.1.0/24 to any port 11434 Rule added # ファイアウォール状態を確認 $ sudo ufw status Status: active To Action From -- ------ ---- 11434/tcp ALLOW Anywhere

社内でChatGPTの利用が制限されているケースでOllamaをチーム共有APIサーバーとして活用する背景については、社内でChatGPTが使えないときの代替手段|機密データを守るローカルLLMという選択肢 でも解説しています。

OLLAMA_MODELSでモデル保存先を変更する

LLMモデルは1つあたり数GB~数十GBの容量を消費します。Gemma 3:4bで約3.3GB、`llama3.3:70b-instruct-q4_0` で約43GBです。デフォルト保存先はOllamaシステムユーザーのホームディレクトリ配下(`/usr/share/ollama/.ollama/models/`)で、OSボリュームに積み上がります。

専用ストレージにモデルを保管すると、ディスク管理・バックアップ・容量拡張をOS領域から独立して行えます。本番サーバーでは必ず分離しておくべき設定の一つです。

1. 専用ディレクトリを作成してollama所有者に設定する

# /dataマウントポイント配下に専用ディレクトリを作成 $ sudo mkdir -p /data/ollama/models # ollama ユーザー・グループに所有者を変更 $ sudo chown -R ollama:ollama /data/ollama # パーミッションを確認 $ ls -ld /data/ollama/models drwxr-xr-x 2 ollama ollama 4096 Jun 22 08:30 /data/ollama/models

`ollama` ユーザーが書き込める状態になっていることを確認してから、override.confに設定を追加します。注意:この確認を省くと後述の「permission denied」エラーで起動失敗します。

2. override.confにOLLAMA_MODELSを追記する

# sudo systemctl edit ollama で追記(全体の設定例) [Service] Environment="OLLAMA_HOST=0.0.0.0:11434" Environment="OLLAMA_MODELS=/data/ollama/models"

# daemon-reload + 再起動 $ sudo systemctl daemon-reload $ sudo systemctl restart ollama # モデルを取得して保存先を確認 $ ollama pull gemma3:4b pulling manifest pulling aabd4debf0c8... 100% ████████ 3.3 GB/3.3 GB success # 指定したディレクトリに保存されているか確認 $ ls -lh /data/ollama/models/blobs/ | head -5 total 3.3G -rw-r--r-- 1 ollama ollama 3.3G Jun 22 09:00 sha256-aabd4debf0c8...

既存のモデルが `/usr/share/ollama/.ollama/models/` にある場合は、`rsync -av` で新しいパスにコピーしてから `systemctl restart ollama` します。コピー完了後に再起動すれば既存モデルはそのまま使えます。モデルの種類・VRAMとモデルサイズの対応については、ローカルLLMのモデルを比較する方法|Llama3.3・Mistral・Gemma・Phi-4をUbuntuで使い分けるポイント を参照してください。

GPU割当とその他の主要環境変数

GPU関連の詳細設定(`OLLAMA_NUM_GPU`・`CUDA_VISIBLE_DEVICES` 等のGPU割当設定)は、NVIDIAドライバ・CUDAセットアップの手順と合わせて別記事で解説します。ここでは override.conf で設定できる代表的な環境変数を整理します。

よく使われる環境変数の一覧です。
・`OLLAMA_HOST`:リッスンするIPアドレスとポート。デフォルト `127.0.0.1:11434`
・`OLLAMA_MODELS`:モデル保存先ディレクトリ。デフォルトは `$HOME/.ollama/models`
・`OLLAMA_KEEP_ALIVE`:モデルをメモリ上に保持する時間。デフォルト `5m`。常駐させる場合は `-1` を指定
・`OLLAMA_MAX_LOADED_MODELS`:同時にメモリにロードする最大モデル数
・`OLLAMA_NUM_PARALLEL`:並列処理するリクエスト数。デフォルトはGPUメモリ量から自動判定
・`OLLAMA_DEBUG`:`1` に設定するとデバッグログが有効になる(通常はトラブルシュート時のみ)

複数の設定を組み合わせた本番向けoverride.confの例です。

# 本番運用向けのoverride.conf設定例(全体) [Service] Environment="OLLAMA_HOST=0.0.0.0:11434" Environment="OLLAMA_MODELS=/data/ollama/models" Environment="OLLAMA_KEEP_ALIVE=-1" Environment="OLLAMA_MAX_LOADED_MODELS=2"

`OLLAMA_KEEP_ALIVE=-1` はモデルをメモリから退避させない設定です。初回レスポンスのモデルロード時間がなくなりレスポンスが速くなりますが、その分メモリを常時占有します。RAMが潤沢なサーバーでバッチ処理や常時API呼び出しをする場合に有効です。メモリが逼迫するようなら `5m` や `30m` に戻してください。

起動失敗時のログ確認とトラブルシュート(journalctl)

override.confを編集後にOllamaが起動しない、または意図通りに動作しない場合はjournalctlでログを確認します。journalctlはsystemdが収集するすべてのサービスログを参照するコマンドです。Ollamaのサービスログはここに集約されており、エラーの原因を特定する最初の一手になります。

1. journalctlでOllamaのログを確認する

# Ollamaサービスのログを末尾50行表示 $ journalctl -u ollama -n 50 -- Logs begin at Mon 2026-06-22 00:00:00 JST. -- Jun 22 09:00:01 srv01 ollama[1234]: time=2026-06-22T09:00:01.000+09:00 level=INFO source=routes.go msg="Ollama version 0.6.8" Jun 22 09:00:01 srv01 ollama[1234]: time=2026-06-22T09:00:01.000+09:00 level=INFO source=routes.go msg="Listening on [::]:11434 (version 0.6.8)" # リアルタイムでログを追跡する(Ctrl+Cで終了) $ journalctl -u ollama -f # 最後の起動(ブート)からのログに絞る $ journalctl -u ollama --boot # 特定の時刻以降のログを表示 $ journalctl -u ollama --since "2026-06-22 09:00:00" # エラーレベル以上のログのみ抽出 $ journalctl -u ollama -p err

`level=INFO ... msg="Listening on [::]:11434"` が出ていれば正常起動です。`OLLAMA_HOST=0.0.0.0:11434` を設定したのに `Listening on 127.0.0.1:11434` のままの場合は、override.conf の設定が反映されていません。`daemon-reload` が漏れていないか確認してください。

2. よくある起動失敗パターンと対処法

起動失敗時にjournalctlに出やすいエラーパターンと対処法を整理します。

「failed to parse environment」が出る場合
override.confの文法エラーが原因です。`Environment=` の値は必ずダブルクォートで囲みます。

# NG:クォートなし(パースエラーになる) Environment=OLLAMA_HOST=0.0.0.0:11434 # OK:ダブルクォートで囲む Environment="OLLAMA_HOST=0.0.0.0:11434"

「permission denied: /data/ollama/models」が出る場合
指定したモデルパスを `ollama` ユーザーが書き込めない状態です。

# ollama ユーザーでアクセスできるか確認 $ sudo -u ollama ls /data/ollama/models ls: cannot open directory '/data/ollama/models': Permission denied # 所有者とパーミッションを修正 $ sudo chown -R ollama:ollama /data/ollama $ sudo systemctl restart ollama # 修正後のログで正常起動を確認 $ journalctl -u ollama -n 10 Jun 22 09:05:00 srv01 ollama[2000]: time=2026-06-22T09:05:00.000+09:00 level=INFO source=routes.go msg="Listening on [::]:11434 (version 0.6.8)"

「address already in use: 11434」が出る場合
11434ポートを別プロセスが使用中です。古いollamaプロセスが残っているケースが多い。

# 11434ポートを使っているプロセスを特定 $ sudo lsof -i :11434 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME ollama 5678 ollama 14u IPv4 98765 0t0 TCP *:11434 (LISTEN) # 古いプロセスが残っている場合はサービスを再起動して解消 $ sudo systemctl restart ollama # ポートの空きを確認 $ sudo ss -tlnp | grep 11434 LISTEN 0 4096 *:11434 *:* users:(("ollama",pid=2001,fd=14))

3. サービス起動の確認フロー

override.conf編集後の確認は以下の順序で進めると効率的です。

# Step1: override.confの文法チェック(再起動前に実施) $ sudo systemd-analyze verify ollama # Step2: daemon-reload + 再起動 $ sudo systemctl daemon-reload && sudo systemctl restart ollama # Step3: 稼働状態の確認 $ systemctl status ollama # Step4: 環境変数が反映されているか確認 $ systemctl show ollama | grep -i environment # Step5: journalctlで起動直後のログを確認 $ journalctl -u ollama -n 30

`systemd-analyze verify ollama` はoverride.confの文法エラーを事前に検出するコマンドです。`systemctl restart` する前に実行する習慣をつけると、設定ミスによる起動失敗を大幅に減らせます。

知人のインフラエンジニアが `OLLAMA_MODELS` のパスに誤字(`/dat/ollama/models` 等)を入れてしまい、サービスが起動しないまま30分悩んだ話を聞いたことがあります。`systemctl show ollama | grep -i environment` で環境変数の値を確認するひと手間で、こうした凡ミスはすぐに気づけます。`journalctl -u ollama -f` でリアルタイムにログを眺めながら `systemctl restart ollama` を叩くのが、現場での王道の切り分け方です。

本記事のまとめ|Ollama常時起動の設定早見表

Ollamaのsystemdサービスをoverride.confでカスタマイズする際の要点をまとめます。デフォルトのユニットファイルを直接編集せず override.conf で上書きする方法は、アップデートに耐性のある構成管理の基本です。

20年以上Linuxサーバーを運用してきた経験から言うと、`systemctl edit` を使わずにユニットファイルを直接 `vi /etc/systemd/system/ollama.service` で編集するインフラ屋は現場でも一定数います。アップデートのたびに設定が消えてもとに戻るトラブルを繰り返すことになるので、最初から override.conf の習慣を身につけるのが得策です。journalctl による切り分けも同様で、「サービスが起動しない→journalctlを見る」の反射を持っているかどうかで障害対応のスピードが変わります。
やりたいこと コマンド・設定 備考
override.confを作成・編集する sudo systemctl edit ollama /etc/systemd/system/ollama.service.d/override.conf が開く
LAN全体にAPIを公開する Environment="OLLAMA_HOST=0.0.0.0:11434" [Service]セクションに記述する
モデル保存先を変更する Environment="OLLAMA_MODELS=/data/ollama/models" ディレクトリをollama所有者に変更してから設定する
モデルをメモリに常駐させる Environment="OLLAMA_KEEP_ALIVE=-1" メモリ常時占有。RAMに余裕があるサーバー向け
設定変更を反映する sudo systemctl daemon-reload && sudo systemctl restart ollama daemon-reloadを忘れずに実行する
override.confの文法チェック sudo systemd-analyze verify ollama 再起動前に実行して文法エラーを事前検出する
起動ログを確認する journalctl -u ollama -n 50 起動失敗時の最初の確認コマンド
リアルタイムでログを監視する journalctl -u ollama -f 再起動後の動作確認や障害時の切り分けに使う
環境変数の反映を確認する systemctl show ollama | grep -i environment override.confの設定が効いているか確認
ユニットファイルとDrop-Inを一覧表示する systemctl cat ollama デフォルトとoverride.confの両方を確認できる

ローカルLLMのsystemd設定を2日間体験する

override.confの設定は手順通りに進めても、環境差異やパーミッション周りでつまずくことがあります。実機GPU環境で手を動かしながら習得したい方向けに、「ローカルAIマスターセミナー」を開催しています。
少人数(最大8名)ZOOMハンズオン形式で実施しています。

>> ローカルAIマスターセミナーの詳細を確認する
ローカルLLMの構築・運用に関する関連記事もあわせて参考にしてください。

Ubuntu ServerでローカルLLMを構築する方法|Ollamaで機密データを外に出さず業務AIを動かす完全ガイド
社内でChatGPTが使えないときの代替手段|機密データを守るローカルLLMという選択肢
ローカルLLMのモデルを比較する方法|Llama3.3・Mistral・Gemma・Phi-4をUbuntuで使い分けるポイント

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

登録10秒/合わなければ解除3秒 / 詳細はこちら

Linux無料マニュアル(図解60P) 名前とメールで30秒登録
宮崎 智広

この記事を書いた人

宮崎 智広(みやざき ともひろ)

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。