「サーバーでプログラムを動かす」と言われても、自分のパソコンでアプリを開く感覚とどう違うのか、はっきりしないまま進んでいる人は多いはずです。ターミナルでコマンドを打てばプログラムは動きます。でも、そのターミナルを閉じたら止まるのではないか、夜中に落ちたら誰が起こすのか、サーバーを再起動したらどうなるのか。こうした疑問の答えが、この記事で扱う「プロセス」「サービス（デーモン）」「systemd」です。Linux のサーバーでは、プログラムは人が画面の前にいなくても動き続けるように、systemd という管理役に任されています。この記事では、その仕組みを公式のマニュアルを根拠に整理し、困ったときにログを見る入口（journalctl）までを押さえます。
この記事の結論
- プロセスとは、ディスクに置かれたプログラムを実行している最中のもので、1つずつに PID という番号が付きます。
- サービス（デーモン）とは、人の操作を待たずに裏で動き続け、頼まれごとを待ち受けるプロセスのことです。
- 多くの Linux では systemd が PID 1 として最初に起動し、サービスの起動・停止・見張りを受け持ちます。
- systemctl start は「いま起動する」、systemctl enable は「次にサーバーが起動したときも自動で起動する」ための操作で、別のものです。
- サービスのログは systemd の journal に集まり、journalctl -u サービス名 でそのサービスのものだけを見られます。
プロセスとは（実行中のプログラム）
READ ALSO — 未経験向け・段0 土台
黒い画面の読み方｜ターミナルで「いまどこにいて、何ができるか」を知る
プロセスとは、実行されている最中のプログラムのことです。料理にたとえると、プログラムはレシピ（手順を書いた紙）で、プロセスはそのレシピを見ながら実際に調理している最中の状態です。同じレシピで同時に何皿も作れるように、同じプログラムからいくつものプロセスを同時に動かせます。
たとえ話から正確な言葉に戻すと、次のように整理できます。
| 言葉 | 何か | どこにあるか | 例 |
|---|---|---|---|
| プログラム | 手順を書いたファイル | ディスク | /usr/bin/python3 |
| プロセス | プログラムを実行している最中のもの | メモリ（動いている間だけ） | PID 1234 の python3 |
| サービス（デーモン） | 裏で動き続けるように管理されているプロセス | systemd の管理下 | sshd、Web サーバー |
PID と ps
Linux はプロセスの1つずつにPID（プロセス ID）という番号を付けて区別します。いま動いているプロセスの一覧は ps コマンドで見られます。
ps aux # 動いているプロセスをすべて表示する
ps aux | grep sshd # その中から sshd を含む行だけを探す
止まらなくなったプロセスを終わらせるときも、この PID を使います。「どのプログラムが」ではなく「どのプロセスが」と考えるのが、サーバーを扱うときの基本の見方です。
ターミナルから起動したプロセスの弱点
ターミナルでコマンドを打って起動したプロセスは、そのターミナル（ログインした接続）に結びついています。接続を閉じると、一緒に終わってしまうことがあります。夜中に落ちたときに起こし直してくれる人もいません。サーバーのプログラムを人の手で起動して見張り続けるのは、現実的ではありません。そこで次の章の「サービス」と、その管理役が要ります。
CHECK 1ここまでの確認
「プログラム」と「プロセス」の違いとして正しいのはどれ?
答えと解説
答え: 1. プログラムはディスクに置かれたファイル、プロセスはそれを実行している最中のもの
プログラムは手順を書いたファイルで、それを動かし始めるとプロセスになります。同じプログラムから同時にいくつもプロセスを作れます。最初の章の「レシピと調理中」のたとえを読み直してください。
サービス（デーモン）とは何か？
デーモンとは、人の操作を待たずに裏で動き続け、頼まれごとを待ち受けるプロセスのことです。SSH の接続を待つ sshd、Web のリクエストを待つ Web サーバー、ログを集める journald などがそうです。名前の最後の「d」は daemon の d であることが多く、名前を見ただけで「裏で動き続けるものだ」と見当がつきます。
FROM POWER ON TO SERVICE起動の順番
サービスは人ではなくsystemd が起動する
-
電源を入れる
機械が動き出す
-
カーネル
Linux の中心が起動
-
systemd
最初のプロセス（PID 1）
-
サービス
登録されたものを順に起動
-
待ち受け
頼まれごとを待つ
サーバーは「頼まれる側」の機械です。頼まれたときに応えるためには、応える係のプロセスが、誰も見ていない間もずっと起きていなければなりません。デーモンはその係です。
同じものを、systemd の側からはサービスと呼びます。性質で呼ぶと「デーモン」、systemd が起動・停止・再起動の面倒を見る単位として呼ぶと「サービス」です。systemd の設定ファイルの単位はユニットと呼ばれ、サービスはそのうちの1種類（サービスユニット、名前の最後が .service）です。
| 比べるところ | ターミナルから起動したプロセス | systemd のサービス |
|---|---|---|
| 誰が起動するか | 打った人 | systemd |
| 接続を閉じたら | 一緒に終わることがある | 動き続ける |
| 落ちたら | 誰かが気づいて起動し直す | 設定しておけば systemd が起動し直す |
| サーバーの再起動後 | 止まったまま | enable してあれば自動で起動する |
| ログ | 画面に流れて消える | journal に残る |
CHECK 2ここまでの確認
サーバーで Web サーバーのプログラムを「ログアウトしても動き続ける」ようにするとき、ふつう誰に任せる?
答えと解説
答え: 2. systemd にサービスとして登録して、起動と見張りを任せる
ターミナルから起動したプログラムは、そのターミナルとの結びつきが残ります。サーバーのプログラムは systemd がサービスとして起動し、落ちたときの扱いまで決めておきます。
systemd は何をしているのか？
systemd は、Linux の「システムとサービスの管理役」です。公式のマニュアルは、systemd が PID 1 として動き、残りのシステムを起動していくものだと説明しています。電源を入れてカーネル（Linux の中心）が動き出したあと、最初に起動するプロセスが systemd で、ほかのサービスはすべてその後に systemd から起動されます。AWS の Amazon Linux 2023 も、ログの扱いを systemd の journal に寄せていることが公式ドキュメントに書かれています（最後の章で扱います）。
サービスの「設計図」＝ユニットファイル
systemd にサービスを任せるときは、ユニットファイルという設定ファイルに「何を・どう動かすか」を書きます。最小の形はこのくらいです。
[Unit]
Description=サンプルの Web アプリ
[Service]
ExecStart=/usr/local/bin/myapp
Restart=on-failure
[Install]
WantedBy=multi-user.target
ExecStart=は、起動するときに実行するコマンドです。Restart=は、プロセスが終わったり止められたりしたときに、起動し直すかどうかです。[Install]のWantedBy=は、enable したときに「どの起動の段階で一緒に起動するか」を決めます。
落ちたら起こし直す（Restart=）
systemd のマニュアルによると、Restart= は既定では no（起動し直さない）です。値には on-failure や always などがあり、長く動き続けるサービスには、エラーで終わったときに起動し直す on-failure を勧めています。ただし、起動し直しは無制限ではありません。短い時間に何度も落ちると、StartLimitIntervalSec= と StartLimitBurst= の決まりで起動が止められます。設定の誤りで起動に失敗し続けるサービスを、延々と起こし続けないためです。
RESTART ON FAILURE落ちたら起こす
Restart= を書けば、落ちたサービスを systemd が起こす
systemd
見張って起こす
- サービスが動く
- エラーで落ちる落ち続けたら止まる
- systemd が気づく
- 起動し直す
RULE 1
既定は起こし直さない
Restart= の既定は no
RULE 2
長く動くものは on-failure
エラーで終わったときだけ起こし直す
RULE 3
止まったら人がログを読む
journalctl -u サービス名
systemctl ＝ systemd への頼みごと
systemd への指示は systemctl コマンドで出します。よく使うものを表にします（多くの操作は管理者の権限が要るので、sudo を付けて打ちます）。
| コマンド | 何をするか | いつ効くか |
|---|---|---|
| systemctl start サービス名 | いま起動する | いま |
| systemctl stop サービス名 | いま止める | いま |
| systemctl restart サービス名 | 止めてから起動し直す（設定を読み直させたいとき） | いま |
| systemctl status サービス名 | 動いているか・直近のログを見る | 見るだけ |
| systemctl enable サービス名 | サーバーの起動のたびに自動で起動するよう登録する | 次の起動のとき |
| systemctl disable サービス名 | 自動で起動する登録を外す | 次の起動のとき |
NOW OR NEXT BOOTstart と enable
start はいま、enable は次の起動のときに効く
systemctl start
いま起動する
- すぐに動き出す
- サーバーを再起動すると止まったまま
- 試しに動かすとき
systemctl enable
起動のたびに動くよう登録する
- いまは動かさない
- 次の起動から自動で動く
- ずっと動かすサービスに
start と enable は別のものです。start だけでは、サーバーを再起動したあとに止まったままになります。enable だけでは、登録はされてもいまは動いていません。両方を一度にしたいときは systemctl enable --now サービス名 と書けます。「さっきまで動いていたのに、再起動したら動かない」という相談の多くは、この違いから来ます。
CHECK 3ここまでの確認
systemctl の start と enable の違いとして正しいのはどれ?
答えと解説
答え: 1. start は「いま起動する」、enable は「次にサーバーが起動したときも自動で起動する」ように登録する
start だけだと、サーバーを再起動したあとは止まったままです。enable は起動のたびに動くように登録するだけで、いま動かすわけではありません。表「いま」と「次の起動のとき」を読み直してください。
ログはどこで見ればよいのか？
サービスは画面の前に誰もいない状態で動くので、何が起きたかはログに残してもらうしかありません。systemd の仕組みでは、サービスの出力やシステムのメッセージは systemd-journald というサービスが集めて、journal（ジャーナル）という記録にまとめます。これを読むコマンドが journalctl です。
journalctl -u nginx.service # nginx のサービスのログだけを見る
journalctl -u nginx.service -f # 新しいログを流しっぱなしで見る（Ctrl-C で終わる）
journalctl -b # いまの起動からのログを見る
journalctl のマニュアルによると、-u はそのユニット（サービス）のメッセージだけを表示し、-f は最新のものを表示したあと、追加されるたびに表示し続けます。困ったときの最初の一手は、systemctl status サービス名 で状態と直近の数行を見て、足りなければ journalctl -u サービス名 で前後を読む、の2段です。
/var/log/messages が無いサーバーもある
古い資料には「ログは /var/log/messages を見る」と書かれていることがあります。これは rsyslog という別のログの仕組みが文字のファイルに書き出していたものです。AWS の公式ドキュメントによると、Amazon Linux 2023 は rsyslog を既定では入れておらず、ログは systemd の journal に集まるので journalctl で見る、とされています。どのサーバーでも同じ場所にログがあるとは限らない、という前提で探すのが安全です。
| 探し方 | 見るもの | 向いている場面 |
|---|---|---|
| systemctl status サービス名 | 動いているか・直近の数行 | 最初の確認 |
| journalctl -u サービス名 | そのサービスのログ全体 | 原因を読むとき |
| journalctl -u サービス名 -f | いま出ているログ | 設定を直して起動し直すのを見届けるとき |
| /var/log/ の下のファイル | アプリが自分で書くログ、rsyslog が入っているサーバーのログ | アプリがファイルに書く設定のとき |
ログを1台ずつ見に行くのは、台数が少ないうちの方法です。台数が増えたら、ログを1か所に集めて見る仕組みが要ります。それは監視やログの設計で扱います。
CHECK 4ここまでの確認
サービスが起動しないとき、最初に見る場所として適切なのはどれ?
答えと解説
答え: 1. journalctl でそのサービスのログを見る
systemd が起動したサービスの出力は journal に集まります。journalctl -u サービス名 で、そのサービスのログだけを見られます。作り直す前に、まず理由を読みます。
まとめ
プログラムはディスク上のファイルで、実行している最中のものがプロセスです。そのうち、人の操作を待たずに裏で動き続け、頼まれごとを待ち受けるものがデーモンで、systemd が面倒を見る単位として呼ぶとサービスになります。
systemd は PID 1 として最初に起動し、ユニットファイルに書かれたとおりにサービスを起動し、Restart= の設定に従って落ちたサービスを起こし直します。systemctl の start は「いま」、enable は「次の起動のとき」に効く別の操作です。
サービスは誰も見ていないところで動くので、何が起きたかは journal に残ります。まず systemctl status、次に journalctl -u サービス名。この2つを打てるようになると、「動かない」と言われたときに、作り直す前に理由を読めるようになります。
参照ソース
- systemd(1)（Linux manual page） — systemd がシステムとサービスの管理役で、PID 1 として動いて残りのシステムを起動すること（2026年9月時点の掲載版）
- systemd.service(5)（Linux manual page） — ExecStart=・Restart= の意味、Restart= の既定が no で長く動くサービスには on-failure を勧めていること、StartLimitIntervalSec= と StartLimitBurst= による制限（2026年9月時点の掲載版）
- systemctl（systemd 公式マニュアル） — start / stop / restart / status / enable / disable の意味（latest の版、2026年9月時点）
- journalctl（systemd 公式マニュアル） — -u（ユニットごとの表示）と -f（追いかけて表示）の意味（latest の版、2026年9月時点）
- systemd journal replaces rsyslog（Amazon Linux 2023 ユーザーガイド） — Amazon Linux 2023 は rsyslog を既定で入れておらず、ログは journalctl で見ること（2026年9月時点の記載）
