systemd入門 systemctl・journalctl解説

Linuxエンジニア養成講座 第13回｜全36回・フェーズ2「Linux基礎」の10回目です。
前回までに学んだこと: プロセスの概念、ps・top・killによるプロセスの確認と制御、ジョブ制御、ss・lsofによるポートとプロセスの紐付け（第12回）。
今回学ぶこと: systemd によるサービス管理、systemctl の主要サブコマンド、journalctl でのログ確認、サービスが起動しないときの切り分けパターン。

この記事を読み終えると、以下のことができるようになります。

• systemd の役割（PID 1、サービス管理の中核）を説明できる
• systemctl start/stop/restart/status でサービスの起動・停止・再起動・状態確認ができる
• systemctl enable/disable でサービスの自動起動を設定・解除できる
• systemctl is-active/is-enabled でサービスの現在状態と自動起動設定をワンライナーで確認できる
• journalctl -u サービス名 でサービスのログを確認できる
• サービスが起動しない場合の基本的な切り分けパターン（status → journalctl → 設定ファイル確認）を実行できる

alma-mainにSSH接続した状態で進めます。以降のコマンドはすべてalma-main上で実行します。

なぜ systemd を学ぶのか

前回の末尾で、「PID 1 として表示された systemd がサービス管理の中核」「sshd や crond は systemd が管理するサービスとして動いている」と予告しました。前回は ps や kill を使ってプロセスを手動で確認・終了しましたが、本番サーバーではOS起動時にサービスを自動で開始させ、異常終了時に自動で再起動させる仕組みが必要です。その仕組みが systemd です。

インフラエンジニアの日常業務で、「サービスの起動確認」「サービスの再起動」「ログの確認」は最も頻度の高い操作です。障害対応の連絡を受けたとき、最初に実行するのは systemctl status サービス名 です。今回学ぶコマンドは、この先の全回で繰り返し使うことになります。

systemd とは何か

PID 1 — すべてのプロセスの親

前回、ps -ef の出力で PID 1 のプロセスが systemd であることを確認しました。もう一度見てみます。

実行コマンド:

$ ps -ef | head -5

実行結果:

UID          PID    PPID  C STIME TTY          TIME CMD
root           1       0  0  3月28 ?      00:00:02 /usr/lib/systemd/systemd --switched-root --system --deserialize 31
root           2       0  0  3月28 ?      00:00:00 [kthreadd]
root           3       2  0  3月28 ?      00:00:00 [pool_workqueue_]
root           4       2  0  3月28 ?      00:00:00 [kworker/R-rcu_g]

PID 1 が systemd です。Linuxの起動時に最初に動くプロセスであり、他のすべてのサービスを起動・管理する役割を担います。前回の ps -ef で sshd（PID 802）の PPID が 1 だったことを思い出してください。sshd は systemd（PID 1）が起動した子プロセスです。

RHEL 7（2014年）より前の Linux では、SysVinit や Upstart と呼ばれる仕組みが PID 1 の役割を担っていました。現在の RHEL 系ディストリビューション（AlmaLinux 9 を含む）では systemd が標準です。古い記事やドキュメントで service コマンドや chkconfig コマンドが登場した場合、それは SysVinit 時代の管理方法です。今は systemctl を使います。

ユニットという管理単位

systemd が管理する対象を「ユニット（Unit）」と呼びます。ユニットにはいくつかの種類があります。

• service: サービス（sshd, crond など）。今回の主役
• target: 複数のユニットをまとめた起動レベル（multi-user.target など）
• timer: 定期実行（第24回で扱う）
• socket: ソケットによるサービス起動

今回は service ユニットに集中します。各ユニットには「ユニットファイル」と呼ばれる設定ファイルがあり、/usr/lib/systemd/system/ ディレクトリに格納されています。ユニットファイルはサービスの設計図のようなもので、「どのコマンドで起動するか」「異常終了時に再起動するか」といった情報が書かれています。ユニットファイルの詳しい書き方は第24回で扱います。今回は「読み方の基本」を押さえます。

systemctl — サービスを操作する

systemctl は systemd を操作するためのメインコマンドです。サブコマンドを組み合わせて使います。

サービスの状態を確認する（status）

最も使用頻度が高いサブコマンドです。sshd の状態を確認します。

実行コマンド:

$ systemctl status sshd

実行結果:

● sshd.service - OpenSSH server daemon
     Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; preset: enabled)
     Active: active (running) since Sat 2026-03-28 16:01:09 JST; 1 day 6h ago
       Docs: man:sshd(8)
             man:sshd_config(5)
   Main PID: 802 (sshd)
      Tasks: 1 (limit: 24743)
     Memory: 6.7M
        CPU: 3.155s
     CGroup: /system.slice/sshd.service
             └─802 "sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups"

出力の各行を読み解きます。

• Loaded 行: ユニットファイルのパス（/usr/lib/systemd/system/sshd.service）、自動起動の状態（enabled）、OS標準の設定（preset: enabled）
• Active 行: 現在の動作状態。active (running) は正常に動作中。他に inactive (dead)（停止中）、failed（起動失敗）がある
• Main PID: サービスのメインプロセスID。前回の ps aux | grep sshd で確認した PID 802 と一致する
• CGroup: サービスに属するプロセスのツリー

Main PID: 802 は、前回 ps aux で確認した sshd のPIDと同じです。前回はプロセスとして見ていたものを、今回は systemd が管理するサービスとして見ています。

状態だけを素早く確認したい場合は、is-active と is-enabled を使います。

実行コマンド:

$ systemctl is-active sshd

実行結果:

active

実行コマンド:

$ systemctl is-enabled sshd

実行結果:

enabled

is-active は active または inactive を、is-enabled は enabled または disabled を返します。1行で結果が返るため、シェルスクリプトで状態を判定するときに便利です（第14回で活用します）。

サービスを起動・停止・再起動する（start / stop / restart）

サービスの起動・停止・再起動は以下のサブコマンドで行います。

• systemctl start サービス名: サービスを起動する
• systemctl stop サービス名: サービスを停止する
• systemctl restart サービス名: サービスを再起動する（停止してから起動）
• systemctl reload サービス名: プロセスを止めずに設定ファイルを再読み込みする

restart と reload の違いは現場で重要です。restart はプロセスを一度停止してから再起動するため、一瞬サービスが止まります。reload はプロセスを止めずに設定だけを反映するため、サービスの中断が発生しません。本番サーバーでは、reload で済む場面では reload を使うのが原則です。ただし reload に対応していないサービスもあります。

前回学んだシグナルの SIGHUP を覚えていますか。「設定を再読み込みさせるシグナル」と説明しました。systemctl reload は内部的にこの SIGHUP をサービスに送ることで設定の再読み込みを実現しています。後ほどユニットファイルを読むときに、この仕組みを確認します。

crond で restart を体験してみます。まず現在の状態を確認します。

実行コマンド:

$ systemctl status crond

実行結果:

● crond.service - Command Scheduler
     Loaded: loaded (/usr/lib/systemd/system/crond.service; enabled; preset: enabled)
     Active: active (running) since Sat 2026-03-28 16:01:09 JST; 1 day 6h ago
   Main PID: 810 (crond)
      Tasks: 1 (limit: 24743)
     Memory: 1.3M
        CPU: 614ms
     CGroup: /system.slice/crond.service
             └─810 /usr/sbin/crond -n

Main PID が 810 であることを確認してください。次に restart を実行します。

実行コマンド:

$ sudo systemctl restart crond

実行コマンド:

$ systemctl status crond

Active 行の日時が更新され、Main PID の値が変わっているはずです。プロセスが一度停止し、新しいプロセスとして再起動されたことがわかります。

自動起動を設定する（enable / disable）

start はサービスを今すぐ起動するコマンドですが、OSを再起動するとサービスは停止したままです。OS起動時に自動でサービスを起動するには enable を使います。

• systemctl enable サービス名: OS起動時に自動でサービスを起動する設定を有効にする
• systemctl disable サービス名: 自動起動の設定を無効にする

ここで注意が必要です。enable は「次回のOS起動時から自動で起動する」という設定を行うだけで、今すぐサービスを起動するわけではありません。今すぐ起動もしたい場合は enable と start の両方が必要です。

実行コマンド:

$ sudo systemctl enable サービス名
$ sudo systemctl start サービス名

この2つを同時に行うショートカットもあります。

実行コマンド:

$ sudo systemctl enable --now サービス名

--now を付けると enable と start を同時に実行します。新しくサービスをインストールした後に使うパターンです。この先の回でWebサーバーやデータベースを構築するとき（第29回、第30回）に何度も使うことになります。

systemctl status の Loaded 行にある preset: enabled は、AlmaLinux のデフォルト設定です。sshd はOSインストール時点で自動起動が有効に設定されています。

start/stop と enable/disable の関係を整理すると、以下の4つの状態があります。

	enabled（自動起動ON）	disabled（自動起動OFF）
active（起動中）	動いていて、再起動後も自動で起動する	動いているが、再起動後は起動しない
inactive（停止中）	止まっているが、再起動後は自動で起動する	止まっていて、再起動後も起動しない

start/stop は「今この瞬間」の状態を変え、enable/disable は「次回OS起動時」の動作を変えます。この2つは独立した設定であり、start しても enable にはなりません。

一覧を確認する（list-units / list-unit-files）

「このサーバーで何が動いているか」を把握することは現場の基本動作です。実行中のサービス一覧を確認します。

実行コマンド:

$ systemctl list-units --type=service --state=running

実行結果:

  UNIT                     LOAD   ACTIVE SUB     DESCRIPTION
  auditd.service           loaded active running Security Auditing Service
  chronyd.service          loaded active running NTP client/server
  crond.service            loaded active running Command Scheduler
  dbus-broker.service      loaded active running D-Bus System Message Bus
  firewalld.service        loaded active running firewalld - dynamic firewall daemon
  getty@tty1.service       loaded active running Getty on tty1
  hypervkvpd.service       loaded active running Hyper-V KVP daemon
  hypervvssd.service       loaded active running Hyper-V VSS daemon
  irqbalance.service       loaded active running irqbalance daemon
  NetworkManager.service   loaded active running Network Manager
  polkit.service           loaded active running Authorization Manager
  rsyslog.service          loaded active running System Logging Service
  sshd.service             loaded active running OpenSSH server daemon
  systemd-journald.service loaded active running Journal Service
  systemd-logind.service   loaded active running User Login Management
  systemd-udevd.service    loaded active running Rule-based Manager for Device Events and Files
  user@1000.service        loaded active running User Manager for UID 1000

前回の ps aux で見た sshd、crond などのプロセスが、サービスとして一覧に並んでいます。hypervkvpd と hypervvssd は筆者の検証環境が Hyper-V のため表示されるサービスです。VirtualBoxなら vboxadd 系、VMwareなら vmtoolsd のように、仮想化ソフトによって表示されるサービスが異なります。物理サーバーやクラウド環境ではこれらは表示されません。

自動起動が有効なサービスの一覧を確認するには list-unit-files を使います。

実行コマンド:

$ systemctl list-unit-files --type=service --state=enabled

実行結果:

UNIT FILE                          STATE   PRESET
auditd.service                     enabled enabled
chronyd.service                    enabled enabled
crond.service                      enabled enabled
dbus-broker.service                enabled enabled
firewalld.service                  enabled enabled
getty@.service                     enabled enabled
irqbalance.service                 enabled enabled
kdump.service                      enabled enabled
lvm2-monitor.service               enabled enabled
mdmonitor.service                  enabled enabled
microcode.service                  enabled enabled
NetworkManager-dispatcher.service  enabled enabled
NetworkManager-wait-online.service enabled disabled
NetworkManager.service             enabled enabled
nis-domainname.service             enabled enabled
rsyslog.service                    enabled enabled
selinux-autorelabel-mark.service   enabled enabled
sshd.service                       enabled enabled
sssd.service                       enabled enabled
systemd-boot-update.service        enabled enabled
systemd-network-generator.service  enabled enabled
systemd-pstore.service             enabled enabled
udisks2.service                    enabled enabled

23 unit files listed.

list-units は「今動いているサービス」、list-unit-files は「自動起動が設定されているサービス」を表示します。用途に応じて使い分けてください。

journalctl — サービスのログを確認する

サービスの状態を確認した次のステップは、ログの確認です。systemd 環境では journalctl コマンドでシステム全体のログを検索できます。systemd-journald というサービスがログを一元的に収集・管理しています。先ほどの list-units の一覧にも systemd-journald.service が含まれていました。

今回は5つのオプションに絞って紹介します。journalctl の詳細（永続化設定、rsyslog との関係など）は第23回「ログ管理」で扱います。

-u: サービスを指定してログを表示する

実行コマンド:

$ journalctl -u sshd -n 5 --no-pager

実行結果:

 3月 29 22:45:08 alma-main sshd[13607]: Accepted publickey for developer from 192.168.1.100 port 52574 ssh2: ED25519 SHA256:W2DBHTgDj1dxfL1A8U9rxnmhPn9hN6Ru5sAbR9Ydgcc
 3月 29 22:45:08 alma-main sshd[13607]: pam_unix(sshd:session): session opened for user developer(uid=1000) by developer(uid=0)
 3月 29 22:45:08 alma-main sshd[13607]: pam_unix(sshd:session): session closed for user developer
 3月 29 22:45:08 alma-main sshd[13632]: Accepted publickey for developer from 192.168.1.100 port 52575 ssh2: ED25519 SHA256:W2DBHTgDj1dxfL1A8U9rxnmhPn9hN6Ru5sAbR9Ydgcc
 3月 29 22:45:08 alma-main sshd[13632]: pam_unix(sshd:session): session opened for user developer(uid=1000) by developer(uid=0)

-u sshd で sshd のログだけに絞り込み、-n 5 で末尾5行に制限しています。--no-pager はページャー（less のような画面送り）を使わずに出力するオプションです。パイプで別のコマンドに渡すときに使います。

ログの中に Accepted publickey for developer という行があります。これは developer ユーザーが SSH 鍵認証で接続に成功したことを示しています。自分のSSH接続がログに記録されていることを確認してください。

-f: リアルタイムでログを追いかける

-f を付けると、ログが出力されるたびにリアルタイムで表示されます。第8回で紹介した tail -f と同じ動作です。

実行コマンド:

$ journalctl -u sshd -f

別のターミナルから alma-main にSSH接続すると、接続ログがリアルタイムで表示されます。確認後、Ctrl+C で終了してください。

-p: ログレベルで絞り込む

ログには重要度（プライオリティ）が設定されています。-p で指定したレベル以上のログだけを表示できます。

実行コマンド:

$ journalctl -p err -n 5 --no-pager

-p err はエラーレベル以上（emerg、alert、crit、err）のログを表示します。この出力でエラーがほとんどなければ、システムは健全な状態です。障害対応時には、まず -p err でエラーログを絞り込むのが定石です。

–since: 日時で絞り込む

「いつからの障害か」がわかっている場合、日時で絞り込めます。

実行コマンド:

$ journalctl -u sshd --since "1 hour ago" --no-pager

直近1時間分の sshd ログだけが表示されます。--since "2026-03-28 16:00:00" のように絶対時刻でも指定できます。

ここまでの5つのオプションをまとめます。

オプション	用途	例
-u	サービスを指定	-u sshd
-n	表示行数を指定	-n 20
-f	リアルタイム追跡	journalctl -u sshd -f
-p	ログレベルで絞り込み	-p err
--since	日時で絞り込み	--since "1 hour ago"

従来の Linux では /var/log/messages などのテキストファイルにログが書かれていました。systemd 環境でも rsyslog がテキストファイルへの書き出しを行っています。journalctl と従来のログファイルの関係は第23回「ログ管理」で詳しく扱います。今は journalctl でログを検索できることを覚えておいてください。

ユニットファイルを読んでみる

sshd のユニットファイルを systemctl cat で表示します。cat コマンドで直接ファイルを読むこともできますが、systemctl cat はユニットファイルのパスも表示してくれるため便利です。

実行コマンド:

$ systemctl cat sshd.service

実行結果:

# /usr/lib/systemd/system/sshd.service
[Unit]
Description=OpenSSH server daemon
Documentation=man:sshd(8) man:sshd_config(5)
After=network.target sshd-keygen.target
Wants=sshd-keygen.target

[Service]
Type=notify
EnvironmentFile=-/etc/sysconfig/sshd
ExecStart=/usr/sbin/sshd -D $OPTIONS
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure
RestartSec=42s

[Install]
WantedBy=multi-user.target

ユニットファイルは3つのセクションで構成されています。それぞれの役割を見ていきます。

[Unit] セクション — サービスの基本情報

• Description: サービスの説明。systemctl status の1行目に表示される
• After: このサービスより先に起動するべきユニット。sshd は network.target（ネットワーク）の起動後に起動する
• Wants: 依存するユニット。sshd-keygen.target（SSH鍵の生成）が必要

[Service] セクション — サービスの動作定義

• ExecStart: サービスの起動コマンド。/usr/sbin/sshd -D が実行される
• ExecReload: systemctl reload 時に実行されるコマンド。/bin/kill -HUP $MAINPID と書かれている
• Restart: 異常終了時の再起動設定。on-failure は異常終了した場合に自動で再起動する
• RestartSec: 再起動までの待機時間。42秒後に再起動する

ExecReload=/bin/kill -HUP $MAINPID に注目してください。前回学んだ SIGHUP（シグナル番号1）がここで使われています。systemctl reload sshd を実行すると、内部的にはメインプロセスに SIGHUP が送られ、設定ファイルが再読み込みされます。前回のシグナルの知識がここでつながります。

Restart=on-failure は「手動で systemctl stop した場合は再起動しないが、プロセスが異常終了した場合は自動で再起動する」という設定です。前回は kill でプロセスを手動で終了しましたが、systemd が管理するサービスでは、この自動再起動の仕組みによって障害時の復旧が自動化されます。

[Install] セクション — enable 時の設定

• WantedBy: systemctl enable を実行したときに、どのターゲットに紐付くかを指定する。multi-user.target は CUI（コマンドライン）の通常起動モード

ユニットファイルの作成や編集は第24回「cron / systemd timer」で扱います。今は「ユニットファイルを読んでサービスの設定内容を確認できる」ことが目標です。

サービスが起動しないときの切り分け

「サービスが起動しない」は、現場で最も頻繁に遭遇するトラブルです。原因はさまざまですが、切り分けの手順は共通しています。以下の3ステップを覚えてください。

ステップ1: systemctl status で状態を確認する

実行コマンド:

$ systemctl status サービス名

Active 行が failed であれば起動に失敗しています。末尾に表示されるログ行に原因のヒントが含まれていることがあります。

ステップ2: journalctl でエラーログを確認する

実行コマンド:

$ journalctl -u サービス名 -n 30 --no-pager

エラーメッセージを確認します。設定ファイルの構文エラーであれば、エラー行の行番号が表示されることが多いです。

ステップ3: 設定ファイルを確認する

ログのエラーメッセージを手がかりに、設定ファイルを確認します。よくある原因は以下の通りです。

• 設定ファイルのタイポ（スペルミスや余分な空白）
• ポートの競合 — 別のプロセスが同じポートを使っている。前回学んだ ss -tlnp で確認できる
• パーミッション不足 — 設定ファイルやデータディレクトリの権限が不適切。第11回の知識を活用する
• 依存するサービスが起動していない — systemctl status 依存サービス名 で確認する

この「status → journalctl → 設定確認」の3ステップは、サービスの種類を問わず使える鉄板パターンです。Webサーバーでもデータベースでも、切り分けの手順は同じです。

やってみよう — systemctl と journalctl を使いこなす

ここまで学んだ内容を、手を動かして確認します。

ステップ1: sshd の状態確認

alma-mainで実行します。

実行コマンド:

$ systemctl status sshd

Active 行が active (running) であることを確認してください。Main PID の値を控えておきます。

実行コマンド:

$ ps aux | grep sshd | grep -v grep

前回の ps aux で確認した sshd のPIDと、systemctl status の Main PID が一致していることを確認してください。同じプロセスを、前回は ps で見て、今回は systemctl で管理しています。

ステップ2: sshd のログを確認する

実行コマンド:

$ journalctl -u sshd -n 10 --no-pager

自分のSSH接続ログ（Accepted publickey for developer）が含まれていることを確認してください。

ステップ3: 実行中のサービス一覧を確認する

実行コマンド:

$ systemctl list-units --type=service --state=running

sshd.service、crond.service などが一覧に含まれていることを確認します。前回の ps aux で見たプロセスたちがサービスとして管理されていることがわかります。

ステップ4: crond で restart を体験する

実行コマンド:

$ systemctl status crond

Main PID を確認してから restart を実行します。

実行コマンド:

$ sudo systemctl restart crond

実行コマンド:

$ systemctl status crond

Main PID の値が変わっていることを確認します。プロセスが再起動されたため、PIDが新しくなっています。

実行コマンド:

$ journalctl -u crond -n 5 --no-pager

crond の停止と起動のログが記録されていることを確認します。

ステップ5（やらかし体験）: sshd を stop してみる

alma-mainで実行します。

実行コマンド:

$ sudo systemctl stop sshd

実行コマンド:

$ systemctl status sshd

Active 行が inactive (dead) に変わります。

実行コマンド:

$ systemctl is-active sshd

inactive と返ります。

ここで、ホストPCから別のターミナルを開いて alma-main にSSH接続を試みてください。

ホストPCで実行します。

実行コマンド:

PS> ssh developer@192.168.1.121

接続が拒否されます。sshd が停止しているため、SSH接続を受け付けるプロセスが存在しないからです。これが「サービスを止める」ということの意味です。

元のSSHセッション（alma-main）に戻り、sshd を起動します。

alma-mainで実行します。

実行コマンド:

$ sudo systemctl start sshd

実行コマンド:

$ systemctl status sshd

Active 行が active (running) に戻っていることを確認します。ホストPCから再度SSH接続を試みて、接続できることを確認してください。

もし誤ってすべてのSSHセッションを閉じてしまい、sshd を start できなくなった場合は、以下の手順で復旧します。

お使いの仮想化ソフトのコンソール機能でVMに直接接続します。

1. 仮想化ソフトのコンソール機能でalma-mainに接続する（Hyper-Vの場合: Hyper-Vマネージャーでalma-mainを右クリック →「接続」）
2. root または developer でログインする
3. sudo systemctl start sshd を実行する

本番サーバーでコンソールアクセス手段（iLO、IPMI、クラウドのシリアルコンソール等）がない状態で sshd を停止すると、リモートから二度とログインできなくなります。データセンターに物理的に出向いてコンソール接続する必要があります。

クリーンアップ

sshd と crond がそれぞれ active (running) かつ enabled であることを確認します。

実行コマンド:

$ systemctl is-active sshd

実行コマンド:

$ systemctl is-enabled sshd

実行コマンド:

$ systemctl is-active crond

実行コマンド:

$ systemctl is-enabled crond

すべて active / enabled が返れば問題ありません。

自走のヒント

man systemctl で systemctl の全サブコマンドとオプションを確認できます。man journalctl で journalctl のオプション一覧を調べられます。今回紹介したサブコマンドは systemctl の機能のごく一部です。必要になったときに man で調べる習慣をつけてください。

理解度チェック

以下の文が正しければ○、間違っていれば×と答えてください。

1. systemd は PID 1 として動作し、他のサービスを起動・管理するプロセスである
2. systemctl start sshd を実行すると、次回のOS起動時にも sshd が自動で起動する
3. systemctl enable sshd は、今すぐ sshd を起動するコマンドである
4. systemctl reload はプロセスを止めずに設定ファイルを再読み込みする
5. systemctl is-active sshd は active または inactive を返す
6. journalctl -u sshd は sshd のログだけを表示する
7. ユニットファイルの Restart=on-failure は、systemctl stop でサービスを停止した場合にも自動で再起動する設定である
8. サービスが起動しない場合の切り分けは、status → journalctl → 設定ファイル確認の順に行う

まとめ

今回は systemd によるサービス管理を学びました。

• systemd は PID 1 として動作し、Linux のサービスを起動・停止・監視する中核プロセス
• systemctl status サービス名 でサービスの状態を確認する。障害対応の第一歩
• systemctl start/stop/restart でサービスを操作する。reload はプロセスを止めずに設定を再読み込みする
• systemctl enable/disable でOS起動時の自動起動を設定する。enable --now で即時起動と自動起動を同時に設定できる
• journalctl -u サービス名 でサービスのログを確認する。-n、-f、-p、--since で絞り込む
• ユニットファイルの [Unit]、[Service]、[Install] の3セクションを読んでサービスの設定内容を把握できる
• サービスが起動しないときは「status → journalctl → 設定確認」の3ステップで切り分ける

今回学んだ systemctl と journalctl は、この先の全回で繰り返し使います。Webサーバーの構築（第29回）でもデータベースの構築（第30回）でも、systemctl enable --now と systemctl status は必ず登場します。

次回の第14回「シェルスクリプト入門」では、今回学んだ systemctl is-active のような状態チェックコマンドをシェルスクリプトで自動化する方法を学びます。環境変数（PATH, HOME, LANG）や .bashrc/.bash_profile の仕組みも扱います。

シリーズ一覧

フェーズ1: エンジニアのいろは（第1回〜第3回）

• 第1回 エンジニアの仕事と学び方
• 第2回 作業記録と報連相
• 第3回 セキュリティ意識の基本

フェーズ2: Linux基礎（第4回〜第15回）

• 第4回 Linuxとは何か＋環境確認
• 第5回 SSH接続とターミナル操作
• 第6回 ファイルシステムとディレクトリ構造
• 第7回 基本コマンド（ファイル操作）
• 第8回 基本コマンド（テキスト処理・パイプとリダイレクト）
• 第9回 viエディタ
• 第10回 ユーザーとグループ管理
• 第11回 パーミッションと所有権
• 第12回 プロセス管理
• 第13回 systemd（この記事）
• 第14回 シェルスクリプト入門
• 第15回 フェーズ2まとめ演習

フェーズ3: ネットワークとインフラ基盤（第16回〜第27回）

• 第16回 ネットワーク基礎
• 第17回 ネットワーク設定と疎通確認
• 第18回 企業ネットワークの仕組み
• 第19回 パッケージ管理
• 第20回 ファイアウォール（firewalld）
• 第21回 ボンディング/チーミング
• 第22回 VLAN
• 第23回 ログ管理
• 第24回 cron / systemd timer
• 第25回 ストレージ管理（LVM）
• 第26回 シェルスクリプト実践
• 第27回 SSH応用

フェーズ4: サーバー構築と運用（第28回〜第36回）

• 第28回 SELinux
• 第29回 Webサーバー構築（Apache/Nginx）
• 第30回 データベース基礎（MariaDB）
• 第31回 バックアップと復旧
• 第32回 監視入門
• 第33回 セキュリティ実践
• 第34回 Git基本操作
• 第35回 自動化と構成管理（Ansible）
• 第36回 トラブルシューティング（総合演習・最終回）