ログ管理入門 journalctl rsyslog実践

Linuxエンジニア養成講座 第23回｜全36回・フェーズ3「ネットワークとインフラ基盤」の8回目（8/12回目）です。
前回まで: 第16回でTCP/IPの基礎、第17回でnmcliによるIP設定と疎通確認、第18回でプロキシ・DNS・NTPのクライアント設定、第19回でパッケージ管理、第20回でfirewalldによる通信制御、第21回・第22回で発展トピック（ボンディング・VLAN）を学びました。
今回学ぶこと: journalctl、rsyslog、logrotate を使ったログの管理方法を学びます。

前回の予告で「journalctl、rsyslog、logrotate を使ったログの管理方法を学びます」とお伝えしました。発展トピック（第21-22回）が終わり、今回から通常回に戻ります。

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

• Linux のログ管理が journald（収集）→ rsyslog（振り分け）→ テキストファイル保存という二重構造であることを説明できる
• journalctl のオプションを使って、ユニット別・優先度別・期間別にログを絞り込める
• rsyslog.conf のルール（facility.priority → 出力先）を読み解ける
• logger コマンドでテストログを送信し、journalctl と /var/log/messages の両方に記録されることを確認できる
• alma-main から alma-sub へリモートsyslog転送を設定し、ログが転送されることを確認できる
• logrotate の設定ファイルを読み解き、ローテーションの仕組みを説明できる

なぜログ管理が重要か

サーバーで問題が起きたとき、最初に確認するのがログです。第15回の「初動コマンド集」でも、障害時に最初に叩くコマンドの1つとして journalctl を紹介しました。ログにはシステムの動作記録がすべて残っており、「いつ」「何が」「どのように」起きたかを時系列で追跡できます。

ログ管理が重要な理由は大きく2つあります。

• 障害調査の起点 — サービスが停止した、通信できない、といった問題の原因を突き止めるためにログを読む。原因特定ができなければ対策も打てない
• 定期的な監視 — 障害が起きてからログを見るだけでなく、日常的にログを監視してエラーの兆候を早期に発見する。この考え方は第32回「監視入門」で詳しく扱う

今回はこのログをどう確認し、どう管理するかを学びます。

Linux のログ管理の全体像

Linux のログ管理は、主に3つのコンポーネントで構成されています。

• systemd-journald（journald） — システムのログを収集する。第13回で学んだ systemd の一部で、カーネルメッセージやサービスの出力をバイナリ形式のジャーナルとして保存する
• rsyslog — journald が収集したログを読み取り、facility（発生源）と priority（重要度）に基づいてテキストファイルに振り分ける。/var/log/ 以下のファイルを作成・更新する役割
• logrotate — テキストファイルとして蓄積されたログを定期的にローテーション（古いログを圧縮・削除）して、ディスク容量の枯渇を防ぐ

流れを整理すると以下のようになります。

アプリケーション / カーネル
       ↓ ログ出力
  systemd-journald（バイナリのジャーナルに保存）
       ↓ imjournal モジュール経由で読み取り
     rsyslog（facility.priority のルールでテキストファイルに振り分け）
       ↓ /var/log/messages, /var/log/secure, ...
     logrotate（定期的にローテーション → 古いログを圧縮・削除）

同じログが journald のジャーナルと /var/log/ のテキストファイルの両方に存在するのは、二重に記録しているわけではありません。rsyslog が journald から読み取ってテキストファイルに書き出しているのです。この二重構造を理解した上で、それぞれの使い方を見ていきます。

journalctl でジャーナルを閲覧する

journalctl は systemd-journald が収集したジャーナルを閲覧するコマンドです。テキストファイルではなくバイナリ形式のジャーナルを読み取るため、grep ではなく journalctl のオプションで絞り込みます。

最新のログを表示する（-n）

alma-mainで実行してください。-n オプションで表示行数を指定します。

実行コマンド:

$ journalctl --no-pager -n 5

実行結果:

 4月 03 19:03:00 alma-main systemd[21012]: Reached target Main User Target.
 4月 03 19:03:00 alma-main systemd[21012]: Startup finished in 72ms.
 4月 03 19:03:00 alma-main systemd[1]: Started User Manager for UID 1000.
 4月 03 19:03:00 alma-main systemd[1]: Started Session 35 of User developer.
 4月 03 19:03:00 alma-main sshd[21008]: pam_unix(sshd:session): session opened for user developer(uid=1000) by developer(uid=0)

–no-pager を付けないと less のようなページャで表示されます。スクリプトやパイプで処理する場合は –no-pager が便利です。角括弧内の数値（21012 など）はプロセスID（PID）で、環境によって異なります。タイムスタンプの日本語表記は LANG 設定が ja_JP.UTF-8 の場合の表示です。

特定のサービスに絞り込む（-u）

第13回で systemctl status を使ってサービスの状態を確認しました。journalctl -u を使うと、特定のサービス（ユニット）のログだけを抽出できます。

alma-mainで実行:

実行コマンド:

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

実行結果:

 4月 02 20:52:19 alma-main sshd[20940]: pam_unix(sshd:session): session closed for user developer
 4月 03 19:03:00 alma-main sshd[21008]: Accepted publickey for developer from 192.168.1.100 port 63617 ssh2: ED25519 SHA256:W2DBHTgDj1dxfL1A8U9rxnmhPn9hN6Ru5sAbR9Ydgcc
 4月 03 19:03:00 alma-main sshd[21008]: pam_unix(sshd:session): session opened for user developer(uid=1000) by developer(uid=0)

SSH接続の履歴が確認できます。「Accepted publickey」は公開鍵認証で接続が成功したことを示しています。PIDやポート番号は接続ごとに変わるため、環境によって異なります。

優先度で絞り込む（-p）

ログには優先度（priority）が設定されています。主な優先度は上から emerg（緊急）、alert、crit、err、warning、notice、info、debug の8段階です。-p で指定した優先度以上のログだけを表示できます。

alma-mainで実行:

実行コマンド:

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

実行結果:

 3月 31 05:28:30 alma-main kernel: Warning: Unmaintained driver is detected: ip_set

err レベル以上のログが少ないため1行しか表示されませんでした。障害調査のときは -p err で重要なエラーだけに絞り込み、原因の手がかりを探すのが基本的な使い方です。

期間で絞り込む（–since）

alma-mainで実行:

実行コマンド:

$ journalctl --since today --no-pager -n 3

実行結果:

 4月 03 19:02:33 alma-main systemd[1]: Starting dnf makecache...
 4月 03 19:02:33 alma-main systemd[1]: Starting Rotate log files...
 4月 03 19:02:33 alma-main systemd[1]: logrotate.service: Deactivated successfully.

–since today は今日の 0:00 以降のログを表示します。–since “2026-04-03 18:00” のように日時を指定することもできます。「障害発生は今日の18時頃」といった情報があるときに、期間を絞り込んで調査するのに使います。

現在のブートのログのみ表示する（-b）

alma-mainで実行:

実行コマンド:

$ journalctl -b --no-pager -n 3

実行結果:

 4月 03 19:03:00 alma-main systemd[1]: Started User Manager for UID 1000.
 4月 03 19:03:00 alma-main systemd[1]: Started Session 35 of User developer.
 4月 03 19:03:00 alma-main sshd[21008]: pam_unix(sshd:session): session opened for user developer(uid=1000) by developer(uid=0)

-b は最後にサーバーを起動してからのログだけを表示します。再起動前のログを見たいときは -b -1（1つ前のブート）を指定します。

ジャーナルのディスク使用量を確認する

alma-mainで実行:

実行コマンド:

$ journalctl --disk-usage

実行結果:

Archived and active journals take up 8.8M in the file system.

ジャーナル自体もディスクを消費します。サイズが大きくなりすぎた場合は journalctl –vacuum-size=100M のように上限を指定して古いジャーナルを削除できます。

補足: journalctl -o json-pretty のように出力形式を変更することもできます。JSON形式で出力すると、ログの構造化データ（ユニット名、PID、優先度など）をプログラムから扱いやすい形で取得できます。今は「こういう出力もできる」と知っておくだけで十分です。

journalctl のオプションは多数あります。man journalctl で全オプションを確認できるので、必要になったときに調べてみてください。

/var/log のファイルを確認する

journalctl はバイナリのジャーナルを読み取るコマンドでした。一方、/var/log/ 以下にはテキスト形式のログファイルが保存されています。こちらは grep や tail などのテキスト処理コマンド（第8回で学習済み）で直接読めます。

主要なログファイル

まず、主要なログファイルのサイズと更新日時を確認します。

alma-mainで実行:

実行コマンド:

$ ls -lh /var/log/messages /var/log/secure /var/log/cron

実行結果:

-rw-------. 1 root root 3.9K  4月  2 21:01 /var/log/cron
-rw-------. 1 root root 751K  4月  3 19:03 /var/log/messages
-rw-------. 1 root root  68K  4月  3 19:03 /var/log/secure

3つのファイルの役割は以下の通りです。

• /var/log/messages — 一般的なシステムログ。カーネルメッセージ、サービスの起動・停止、ネットワーク関連など、幅広い情報が記録される。障害調査で最初に確認するファイル
• /var/log/secure — 認証関連のログ。SSH接続の成功・失敗、sudo の実行記録などが記録される。不正アクセスの調査に使う
• /var/log/cron — cron ジョブの実行記録。定期実行タスクが正常に動作したかを確認する（第24回で詳しく扱う）

パーミッションが -rw——- なので、一般ユーザーでは読めません。sudo を付けて確認します。

alma-mainで実行:

実行コマンド:

$ sudo tail -5 /var/log/messages

実行結果:

Apr  3 19:02:51 alma-main NetworkManager[777]: <info>  [1775210571.5806] device (eth2): carrier: link connected
Apr  3 19:02:51 alma-main dnf[20987]: Extra Packages for Enterprise Linux 9 - x86_64   13 kB/s |  11 kB     00:00
Apr  3 19:02:55 alma-main systemd[1]: NetworkManager-dispatcher.service: Deactivated successfully.
Apr  3 19:02:55 alma-main dnf[20987]: Extra Packages for Enterprise Linux 9 - x86_64  5.2 MB/s |  20 MB     00:03
Apr  3 19:02:59 alma-main dnf[20987]: Extra Packages for Enterprise Linux 9 openh264  2.0 kB/s | 993  B     00:00

各行の形式は「日時 ホスト名 プログラム名[PID]: メッセージ」です。journalctl の出力と比べてみると、同じ内容がテキスト形式で記録されていることがわかります。

alma-mainで実行:

実行コマンド:

$ sudo tail -3 /var/log/secure

実行結果:

Apr  2 20:52:19 alma-main sshd[20943]: Disconnected from user developer 192.168.1.100 port 61292
Apr  2 20:52:19 alma-main sshd[20940]: pam_unix(sshd:session): session closed for user developer
Apr  3 19:03:00 alma-main sshd[21008]: Accepted publickey for developer from 192.168.1.100 port 63617 ssh2: ED25519 SHA256:W2DBHTgDj1dxfL1A8U9rxnmhPn9hN6Ru5sAbR9Ydgcc

SSH接続の記録が secure に記録されています。不正なログイン試行があった場合も、このファイルに「Failed password」のようなメッセージが残ります。

rsyslog.conf のルールを読み解く

「どのログがどのファイルに書かれるか」を決めているのが rsyslog の設定ファイルです。ルール部分を確認します。

rsyslog.conf のルール部分（コメント行を除いた抜粋）:

*.info;mail.none;authpriv.none;cron.none                /var/log/messages
authpriv.*                                              /var/log/secure
mail.*                                                  -/var/log/maillog
cron.*                                                  /var/log/cron
*.emerg                                                 :omusrmsg:*
local7.*                                                /var/log/boot.log

各行の読み方は「facility.priority → 出力先」です。

• *.info;mail.none;authpriv.none;cron.none → /var/log/messages — すべての facility の info レベル以上を messages に記録する。ただし mail、authpriv、cron は除外（それぞれ専用ファイルがあるため）
• authpriv.* → /var/log/secure — 認証関連（authpriv）のすべてのレベルを secure に記録する
• mail.* → -/var/log/maillog — メール関連を maillog に記録する。先頭の – は非同期書き込み（パフォーマンス優先）を意味する
• cron.* → /var/log/cron — cron 関連を cron ファイルに記録する
• *.emerg → :omusrmsg:* — emerg（最も緊急）レベルのログをログインしている全ユーザーの端末に通知する
• local7.* → /var/log/boot.log — 起動時のログを boot.log に記録する

facility（発生源）と priority（優先度）の組み合わせで振り分け先が決まるという仕組みです。新しいアプリケーションのログを別ファイルに分けたい場合は、このルールを追加します。

補足: rsyslog.conf の先頭部分には module() や input() のような新しい記法（RainerScript形式）で書かれたセクションがあります。今はルール部分の旧形式（facility.priority → ファイル）が読めれば十分です。

詳しい記法は man rsyslog.conf で確認できます。

/var/log の容量を確認する習慣

ログファイルは放置すると大きくなり続けます。定期的に容量を確認する習慣を付けておくと、ディスク枯渇を未然に防げます。

alma-mainで実行:

実行コマンド:

$ sudo du -sh /var/log/* | sort -rh | head -5

実行結果:

5.6M	/var/log/anaconda
1.1M	/var/log/audit
756K	/var/log/messages
128K	/var/log/secure
48K	/var/log/dnf.log

現在はまだ小さいですが、本番環境ではアクセスログやアプリケーションログが数GBに達することもあります。第6回で学んだ du コマンドと 第8回で学んだ sort コマンドのパイプの組み合わせです。

logger コマンドでテストログを送信する

logger は syslog にテストメッセージを送信するコマンドです。rsyslog の設定を変更した後に「ログが正しく記録されるか」を確認するのに使います。

alma-mainで実行:

実行コマンド:

$ logger -t test-log 'Hello from alma-main'

-t オプションでタグ（プログラム名に相当する識別子）を指定しています。このメッセージが journalctl と /var/log/messages の両方に記録されることを確認します。

alma-mainで実行:

実行コマンド:

$ journalctl -t test-log --no-pager -n 1

実行結果:

 4月 03 19:03:00 alma-main test-log[21057]: Hello from alma-main

journalctl 側に記録されています。次に /var/log/messages を確認します。

alma-mainで実行:

実行コマンド:

$ sudo grep 'test-log' /var/log/messages | tail -1

実行結果:

Apr  3 19:03:00 alma-main test-log[21057]: Hello from alma-main

/var/log/messages にも同じ内容が記録されています。これが「journald が収集し、rsyslog がテキストファイルに書き出す」という二重構造の実体です。PIDは環境によって異なります。

リモートsyslog転送（alma-main → alma-sub）

ここまではサーバー1台の中でのログ管理でした。本番環境では、複数のサーバーのログを1か所に集約する運用が一般的です。サーバーが障害でダウンした場合、そのサーバー上のログも参照できなくなる可能性があります。ログを別のサーバーに転送しておけば、障害時にも調査が可能です。

ここでは rsyslog の TCP 転送機能を使い、alma-main のログを alma-sub に転送する設定を行います。

手順1: alma-sub で firewalld の 514/tcp を許可する

まず alma-sub 側で rsyslog の待ち受けポート 514/tcp を許可します。第20回で学んだ firewall-cmd の実践復習です。

alma-subで実行:

実行コマンド:

$ sudo firewall-cmd --add-port=514/tcp

実行結果:

success

ランタイム設定に追加されました。動作確認が取れた後に永続化します。

alma-subで実行:

実行コマンド:

$ sudo firewall-cmd --runtime-to-permanent

実行結果:

success

永続化されました。確認します。

alma-subで実行:

実行コマンド:

$ sudo firewall-cmd --list-ports

実行結果:

514/tcp

手順2: alma-sub で rsyslog の TCP 受信を有効化する

rsyslog に TCP 514 番ポートで受信する設定を追加します。メインの rsyslog.conf は変更せず、/etc/rsyslog.d/ ディレクトリに設定ファイルを追加する方法を使います。

alma-subで実行:

実行コマンド:

$ echo 'module(load="imtcp")' | sudo tee /etc/rsyslog.d/listen.conf

実行結果:

module(load="imtcp")

alma-subで実行:

実行コマンド:

$ echo 'input(type="imtcp" port="514")' | sudo tee -a /etc/rsyslog.d/listen.conf

実行結果:

input(type="imtcp" port="514")

1行目の module(load=”imtcp”) で TCP 入力モジュールをロードし、2行目の input() でポート 514 で待ち受ける設定を追加しました。tee -a の -a は追記モードです（第8回のリダイレクト >> と同じ意味）。rsyslog を再起動して設定を反映します。

alma-subで実行:

実行コマンド:

$ sudo systemctl restart rsyslog

ポート 514 が LISTEN 状態になっているか確認します。

alma-subで実行:

実行コマンド:

$ ss -tlnp | grep 514

実行結果:

LISTEN 0      25           0.0.0.0:514       0.0.0.0:*
LISTEN 0      25              [::]:514          [::]:*

IPv4 と IPv6 の両方でポート 514 が LISTEN になっています。第12回で学んだ ss コマンドの活用です。

手順3: alma-main で転送設定を追加する

次に送信側の alma-main に、ログを alma-sub（10.0.1.3）へ TCP で転送する設定を追加します。

alma-mainで実行:

実行コマンド:

$ echo 'action(type="omfwd" Target="10.0.1.3" Port="514" Protocol="tcp")' | sudo tee /etc/rsyslog.d/remote.conf

実行結果:

action(type="omfwd" Target="10.0.1.3" Port="514" Protocol="tcp")

omfwd は「output module forward」の略で、ログを別のサーバーに転送するモジュールです。rsyslog を再起動します。

alma-mainで実行:

実行コマンド:

$ sudo systemctl restart rsyslog

TCP接続が確立されているか確認します。

alma-mainで実行:

実行コマンド:

$ ss -tnp | grep 514

実行結果:

ESTAB 0      0           10.0.1.1:51808      10.0.1.3:514

ESTAB（Established = 接続確立済み）が表示されました。alma-main（10.0.1.1）から alma-sub（10.0.1.3）のポート 514 に TCP 接続が確立されています。送信元ポート（51808）は環境によって異なります。

手順4: テストログで転送を確認する

alma-main から logger でテストメッセージを送信し、alma-sub に届くか確認します。

alma-mainで実行:

実行コマンド:

$ logger -t remote-test 'Hello from alma-main to alma-sub'

alma-subで実行:

実行コマンド:

$ sudo grep 'remote-test' /var/log/messages | tail -1

実行結果:

Apr  3 19:03:16 alma-main remote-test[21119]: Hello from alma-main to alma-sub

alma-sub の /var/log/messages に alma-main のログが記録されました。ホスト名が「alma-main」のまま転送されている点に注目してください。複数のサーバーからログを集約しても、どのサーバーのログかを識別できます。PIDは環境によって異なります。

logrotate

ここまでで、ログの収集（journald）、振り分け（rsyslog）、転送を学びました。最後に、ログファイルのローテーション（古いログの圧縮・削除）を管理する logrotate を見ていきます。

なぜローテーションが必要か

/var/log/messages のようなテキストファイルは、放置するとサーバーが稼働し続ける限り大きくなり続けます。本番環境で数か月〜数年運用したサーバーでは、ログファイルが数GBに達することもあります。/var パーティションがいっぱいになると、rsyslog がログを書き込めなくなるだけでなく、他のサービスも動作不良を起こす可能性があります。

logrotate は、指定した周期でログファイルを「ローテーション」します。現在の messages を messages-20260403 のようにリネームし、新しい空の messages ファイルを作成します。古いファイルは圧縮され、一定の世代数を超えると自動的に削除されます。

/etc/logrotate.conf の読み方

logrotate のメイン設定ファイルを確認します。

/etc/logrotate.conf の主要な設定値:

weekly          # 週次ローテーション
rotate 4        # 4世代保持（4週間分）
create          # ローテーション後に新しい空ファイルを作成
dateext         # ローテーション後のファイル名に日付サフィックスを付ける

• weekly — 週に1回ローテーションを実行する（daily、monthly も指定可能）
• rotate 4 — 古いログを4世代分保持する。5世代目以降は自動的に削除される
• create — ローテーション後に新しい空のログファイルを作成する。これがないと rsyslog がログの書き込み先を失う
• dateext — ローテーション後のファイル名に日付を付ける（例: messages-20260403）

/etc/logrotate.d/rsyslog の読み方

個別のアプリケーション用設定は /etc/logrotate.d/ ディレクトリに配置されます。rsyslog 用の設定を確認します。

/etc/logrotate.d/rsyslog の内容:

/var/log/cron
/var/log/maillog
/var/log/messages
/var/log/secure
/var/log/spooler
{
    missingok
    sharedscripts
    postrotate
        /usr/bin/systemctl -s HUP kill rsyslog.service >/dev/null 2>&1 || true
    endscript
}

• 先頭のパス群 — ローテーション対象のファイル一覧
• missingok — 対象ファイルが存在しなくてもエラーにしない
• sharedscripts — postrotate スクリプトを全ファイルのローテーション後に1回だけ実行する
• postrotate … endscript — ローテーション後に実行するコマンド。rsyslog に HUP シグナルを送り、新しいログファイルへの書き込みを開始させる

postrotate が重要です。ログファイルをリネームしただけでは、rsyslog は古いファイル（リネーム後のファイル）に書き込み続けてしまいます。HUP シグナルで rsyslog にファイルの再オープンを促すことで、新しいファイルに書き込みが切り替わります。

logrotate 自体は単独では動作しません。定期的に実行される仕組み（cron や systemd timer）によって呼び出されます。この定期実行の仕組みは次回の第24回「cron / systemd timer」で詳しく学びます。

logrotate のオプションや設定項目の一覧は man logrotate で確認できます。

やってみよう

以下の2つの課題に取り組んでください。alma-sub が起動していることを確認してから始めてください。

課題1: journalctl で sshd のエラーログを絞り込む

alma-mainで実行してください。journalctl のオプションを組み合わせて、sshd ユニットの err レベル以上のログを今日の分だけ表示してください。

ヒント: -u、-p、–since の3つのオプションを組み合わせます。

$ journalctl -u sshd -p err --since today --no-pager

課題2: リモートsyslog転送を自分で設定する

クリーンアップ済み（転送設定が削除された状態）から、以下の手順をすべて自分で実行してください。

• alma-sub で firewalld の 514/tcp を許可する
• alma-sub で rsyslog の TCP 受信設定を追加して再起動する
• alma-main で転送設定を追加して再起動する
• alma-main から logger でメッセージを送信し、alma-sub の /var/log/messages に届くことを確認する

ヒント: 本文の「リモートsyslog転送」セクションの手順1〜4をもう一度たどってください。詰まった場合は、ss コマンドで 514 ポートの状態を確認することが切り分けの第一歩です。

クリーンアップ

演習で追加した設定を元に戻します。

alma-mainで実行:

実行コマンド:

$ sudo rm /etc/rsyslog.d/remote.conf

実行コマンド:

$ sudo systemctl restart rsyslog

転送が停止したことを確認します。

実行コマンド:

$ ss -tnp | grep 514

出力がなければ、転送接続が切断されています。

alma-subで実行:

実行コマンド:

$ sudo rm /etc/rsyslog.d/listen.conf

実行コマンド:

$ sudo systemctl restart rsyslog

実行コマンド:

$ sudo firewall-cmd --permanent --remove-port=514/tcp

実行結果:

success

実行コマンド:

$ sudo firewall-cmd --reload

実行結果:

success

最終確認として、ポートが閉じられたこととrsyslogが受信を停止したことを確認します。

alma-subで実行:

実行コマンド:

$ sudo firewall-cmd --list-ports

出力がなければ、514/tcp が削除されています。

実行コマンド:

$ ss -tlnp | grep 514

出力がなければ、rsyslog の TCP 受信も停止しています。

まとめ

• Linux のログは journald（収集）→ rsyslog（振り分け）→ テキストファイルの二重構造 — journalctl でバイナリジャーナルを閲覧し、/var/log/ のテキストファイルは grep や tail で読める。同じログが両方に存在する
• rsyslog はリモート転送で複数サーバーのログを集約できる — 障害でサーバーがダウンしてもログを別サーバーで確認できる。firewalld のポート開放を忘れずに
• logrotate はログの無限増大を防ぐ仕組み — 定期的にログをローテーション（リネーム・圧縮・削除）して、ディスク容量の枯渇を防ぐ。定期実行の仕組みは次回学ぶ

今回はログの「確認方法」と「管理の仕組み」を学びました。次のステップとして重要なのは、障害が起きてからログを見るだけでなく、日常的にログを監視してエラーの兆候を早期に発見する体制を作ることです。この「監視」の考え方は第32回「監視入門」で詳しく学びます。

次回の第24回「cron / systemd timer」では、今回登場した logrotate が「誰に呼び出されて定期実行されているのか」という疑問に答えます。cron と systemd timer を使った定期実行の設定方法を学びます。

理解度チェック

以下の文が正しければ「○」、誤りなら「×」と答えてください。

以下、解答です。

シリーズ一覧

フェーズ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回 トラブルシューティング（総合演習・最終回）