サービス管理の基本（systemd）
サーバ上で常時動き続けるプログラムは「サービス（デーモン）」と呼ばれ、RHEL/MiracleLinux系では systemd が一括管理します。systemctl start で起動、stop で停止、status で稼働状況を確認します。一度きりの起動と、OS起動時に自動で立ち上げる enable は別物で、本番では両方を設定するのが定石です。サービス名は nginx・httpd・sshd のように .service を省いて指定できます。
サーバとは、ほかのコンピュータにWebページ・ファイル共有・名前解決といった機能を提供し続ける側のコンピュータだ。あなたがログアウトして家に帰っても、そのサーバ上のWebサイトは翌朝も生きている。
なぜそんなことができるのか。提供役のプログラムが、人のログインとは関係なく、電源が入っているあいだじゅう裏で動き続けているからだ。
このように画面やシェルを介さず、システムが直接起動して常駐し続けるプログラムをサービスと呼ぶ。背後で静かに働き続ける姿から、伝統的にデーモン（daemon）とも呼ばれてきた。
プロセス名の末尾に d が付くものが多いのは、この daemon の頭文字に由来する。sshd・httpd・firewalld などがその例だ。
サーバを構築するという作業は、煎じ詰めれば「必要なサービスを導入し、起動し、止まらないように設定し、状態を監視する」ことに尽きる。だからサービス管理は、サーバ管理者にとって最初に身につけるべき土台になる。
種類もばらばらなこれらのサービスを、誰が束ねて面倒を見ているのか。RHEL系やMiracleLinuxでは、systemd という1つの仕組みが一括して管理する。
systemd は「サービスを管理するためのサービス」で、OSの起動から終了まで動き続ける。ps aux | head -2 の先頭に /usr/lib/systemd/systemd が見え、そのプロセス番号（PID）が 1 になっていることがその証拠だ。
PID 1 はシステムが最初に立ち上げるプロセスで、ほかのすべてのサービスはここから派生して起動する。
サービスの種類が違っても操作方法が統一されているのが systemd の利点だ。Webサーバでもデータベースでも、同じコマンドで起動・停止・状態確認ができる。一度この共通の作法を覚えれば、相手のサービスが何であっても通用する。
🔍 サービスの状態を見る systemctl status
systemd が管理するサービスを操作する窓口が systemctl コマンドだ。最初に覚えるべきは状態確認で、systemctl status sshd のように使う。
サービス名は本来 sshd.service だが、末尾の .service は省いて指定できる。
出力でいちばん重要なのは Active: の行だ。active (running) なら正常に動いており、止まっていれば inactive (dead)、起動に失敗していれば failed と表示される。
あわせて Loaded: の行に enabled / disabled が出る。これは後述する自動起動の設定を表す。Main PID にはそのサービスの実プロセス番号が示される。
status の表示が画面に収まらないときは、less と同じ操作で読め、q を押すと終了する。この Active: の一行を読めるようになることが、これから続くすべての操作の出発点になる。
🎛 動かす・止める・入れ直す start / stop / restart / reload
状態が読めたら、次は動きを与える番だ。サービスを今すぐ起動するには systemctl start nginx、停止するには systemctl stop nginx、いったん止めてから起動し直すには systemctl restart nginx を使う。
これらシステムに影響する操作には管理者権限が必要だ。一般ユーザでは sudo systemctl start nginx のように sudo を付けて実行する。
ここで一つ落とし穴がある。設定ファイルを書き換えただけではサービスには反映されず、restart か reload が要る。
restart と reload の違いはこうだ。restart は一度プロセスを止めてから起動するため、もし新しい設定に誤りがあると停止したまま起動できなくなる恐れがある。
一方 reload はサービスを止めずに設定だけ読み直す。設定にミスがあっても反映されず、それまでの設定で動作を続ける。安全に設定を反映したいときは reload が向いている、と覚えておくとよい。
🔁 「いま動く」と「次も動く」は別物 enable / disable
ここが初学者のつまずきどころだ。systemctl start で起動したのだから、サーバを再起動しても勝手に立ち上がる――そう思い込むと痛い目を見る。
systemctl start はあくまで「いま、この場で起動する」操作にすぎない。サーバを再起動すると、そのサービスは止まったままになる。
OSの起動時にも自動で立ち上げたいなら、systemctl enable nginx を別に実行して自動起動を有効にする必要がある。enable すると、OS起動のターゲットにリンクが張られた、という主旨のメッセージが表示される。
逆に自動起動を外すには systemctl disable nginx だ。
本番のサーバでは「いま起動する start」と「次回以降も自動で起動する enable」の両方を設定するのが定石だ。これを忘れると、ふだんは正常なのにサーバを再起動した瞬間にサービスが上がってこない、という事故につながる。
両方をまとめて行いたいときは systemctl enable --now nginx と書けば、自動起動の設定と即時起動を一度に済ませられる。
⚠ つまずいたら、まずこれ
サービスが起動しないとき、いきなり設定をいじるのは遠回りだ。まず systemctl status で Active: と直近のログ行を読み、必要なら journalctl -u サービス名 で詳しいログを追うのが基本動作になる。
よくある失敗は3つある。enable を忘れて再起動後にサービスが消えるケース。設定変更後に reload / restart を打ち忘れて「直したのに変わらない」と悩むケース。そして sudo を付け忘れて権限エラーになるケースだ。
実務では、Webサーバ（nginx や httpd）・SSHサーバ（sshd）・ファイアウォール（firewalld）はいずれも systemd 管理下のサービスだ。本章で学ぶ status / start / stop / restart / reload / enable / disable の7つの操作が、そのままサーバ運用の共通言語になる。
まず status で現状を確かめ、start と enable で起動と自動起動をそろえ、設定を変えたら reload で反映する――この一連の流れを身体で覚えることが、サーバ構築の第一歩だ。