cron systemd timer 定期実行の設定方法

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

前回の予告で「logrotate が誰に呼び出されて定期実行されているのか。cron と systemd timer を使った定期実行の設定方法を学びます」とお伝えしました。前回の理解度チェック Q7 で「logrotate はデーモンとして常駐し、自動的にローテーションを実行する」が × だったことを覚えているでしょうか。logrotate はデーモンではなく、「何かの仕組み」によって定期的に呼び出されるコマンドでした。今回はその「何かの仕組み」の正体を学びます。

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

• crontab の書式（分 時 日 月 曜日 コマンド）を読み書きできる
• cron の実行環境がログインシェルと異なることを理解し、PATH 問題を回避できる
• /etc/crontab と /etc/cron.d/ の役割を説明できる
• systemctl list-timers で既存タイマーを確認し、.timer ユニットの設定を読み解ける
• logrotate が systemd timer によって定期実行されている仕組みを説明できる

なぜ定期実行が必要か

もし logrotate が1週間実行されなかったら、サーバーに何が起きるでしょうか。第23回で学んだ /var パーティションの話を思い出してから読み進めてください。

サーバー運用には「毎日やらなければならない作業」がいくつもあります。

• ログローテーション — 前回学んだ logrotate による古いログの圧縮・削除
• バックアップ — データベースのダンプやファイルの定期コピー（第31回で実践）
• パッケージキャッシュの更新 — 第19回で学んだ dnf のキャッシュ更新
• 監視データの収集 — ディスク使用量やプロセスの状態確認

これらを毎日手作業で実行するのは現実的ではありません。しかし、定期実行が必要な本質的な理由は「人間が忘れるから」ではありません。ログが肥大化すれば /var パーティションが溢れてサービスが停止します。バックアップがなければ障害時にデータが失われます。これらは「確実に実行されなければサービスに影響する」設計上の要件です。サービスの可用性と信頼性を、人間の判断や記憶に依存しない仕組みで守ること — それが定期実行の本質です。

Linux には cron と systemd timer という2つの仕組みがあり、今回はその両方を学びます。

cron の基本

cron は Linux で最も古くから使われている定期実行の仕組みです。crond というデーモンが常駐し、登録されたスケジュールに従ってコマンドを実行します。

crond サービスの確認

まず、crond が動いていることを確認します。alma-mainで実行してください。

実行コマンド：

$ systemctl status crond --no-pager -l

実行結果：

● crond.service - Command Scheduler
     Loaded: loaded (/usr/lib/systemd/system/crond.service; enabled; preset: enabled)
     Active: active (running) since Tue 2026-03-31 05:28:30 JST; 3 days ago
   Main PID: 817 (crond)
      Tasks: 2 (limit: 24743)
     Memory: 1.6M
        CPU: 31ms
     CGroup: /system.slice/crond.service

※ PID やタイムスタンプは環境によって異なります。

第13回で学んだ systemctl status の読み方を思い出してください。enabled でシステム起動時に自動起動され、active (running) で現在動作中です。crond は AlmaLinux 9 のデフォルトで有効になっています。

crontab の書式

cron に登録するスケジュールの書式は以下のとおりです。

分  時  日  月  曜日  コマンド
0   3   *   *   *     /usr/local/bin/backup.sh

各フィールドの意味は以下のとおりです。

フィールド	範囲	説明
分	0-59	実行する「分」
時	0-23	実行する「時」（24時間表記）
日	1-31	実行する「日」
月	1-12	実行する「月」
曜日	0-7	0と7が日曜、1が月曜…6が土曜

* はそのフィールドのすべての値を意味します。いくつか具体例を見てみます。

書式	意味
0 3 * * *	毎日 3:00 に実行
0 * * * *	毎時 0分に実行
*/5 * * * *	5分ごとに実行
0 2 * * 0	毎週日曜 2:00 に実行
0 0 1 * *	毎月1日 0:00 に実行
* * * * *	毎分実行（テスト用）

*/5 は「5で割り切れる分」、つまり 0, 5, 10, 15, … 分に実行するという意味です。書式の詳細は man 5 crontab で確認できます。

crontab コマンドの操作

ユーザーの cron ジョブは crontab コマンドで管理します。主なオプションは3つです。

コマンド	説明
crontab -l	登録済みのジョブを一覧表示
crontab -e	エディタ（vi）でジョブを編集
crontab -r	登録済みのジョブをすべて削除

現在のジョブを確認してみます。alma-mainで実行してください。

実行コマンド：

$ crontab -l

実行結果：

no crontab for developer

まだ何も登録されていません。

テスト: 毎分実行するジョブを登録する

実際にジョブを登録して動作を確認してみます。毎分 date コマンドの出力を /tmp/cron-test.log に追記するジョブを登録します。ここではパイプを使って直接登録する方法を使います。

alma-mainで実行してください。

実行コマンド：

$ echo "* * * * * /usr/bin/date >> /tmp/cron-test.log" | crontab -

date ではなく /usr/bin/date とフルパスで指定しています。この理由は次のセクションで解説します。

登録されたことを確認します。

実行コマンド：

$ crontab -l

実行結果：

* * * * * /usr/bin/date >> /tmp/cron-test.log

約1分待ってからログファイルを確認します。

実行コマンド：

$ cat /tmp/cron-test.log

実行結果：

2026年  4月  3日 金曜日 20:01:01 JST

※ 表示される日時は実行タイミングによって異なります。

cron の実行ログは /var/log/cron に記録されます。確認してみます。

実行コマンド：

$ sudo tail -5 /var/log/cron

実行結果：

Apr  3 20:01:01 alma-main CROND[21090]: (developer) CMD (/usr/bin/date >> /tmp/cron-test.log)
Apr  3 20:01:01 alma-main CROND[21074]: (developer) CMDEND (/usr/bin/date >> /tmp/cron-test.log)

※ PID やタイムスタンプは環境によって異なります。

「CROND」が developer ユーザーとしてコマンドを実行したことが記録されています。cron のジョブが正常に動作しない場合、まず /var/log/cron を確認するのが基本です。

確認が終わったらクリーンアップします。テスト用のジョブを放置しておくと毎分実行され続けるため、確認後は必ず削除してください。

実行コマンド：

$ crontab -r
$ rm -f /tmp/cron-test.log

削除されたことを確認します。

実行コマンド：

$ crontab -l

実行結果：

no crontab for developer

ジョブが削除されました。man crontab で crontab コマンドの詳しいオプションを確認できます。

cron の実行環境の罠

先ほどのテストで /usr/bin/date とフルパスを指定しました。なぜ単に date ではなくフルパスなのか。ここが cron で最も多いトラブルの原因です。

cron がジョブを実行する環境は、ターミナルにログインしたときの環境とは大きく異なります。実際に比較してみます。

cron の実行環境を取得するために、env > /tmp/cron-env.txt というジョブを一時的に登録して確認した結果が以下です。

cron の実行環境：

SHELL=/bin/sh
PATH=/usr/bin:/bin
HOME=/home/developer
LANG=ja_JP.UTF-8

ログインシェルの環境：

SHELL=/bin/bash
PATH=/home/developer/.local/bin:/home/developer/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin
HOME=/home/developer

2つの重要な違いがあります。

項目	cron	ログインシェル
SHELL	/bin/sh	/bin/bash
PATH	/usr/bin:/bin	/home/developer/.local/bin:/home/developer/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin

SHELL の違い: cron は /bin/sh で実行されます。bash 固有の記法（配列、[[ ]] 等）はそのままでは使えません。

PATH の違い: これが最大の罠です。cron の PATH は /usr/bin:/bin だけです。ログインシェルには含まれている /usr/local/bin や /usr/sbin が含まれていません。つまり、ターミナルでは動くコマンドが cron では「コマンドが見つからない」というエラーになることがあります。

cron の PATH がログインシェルより狭いのは、偶然ではなく意図的な設計です。定期実行されるジョブは無人で動くため、不要なディレクトリが PATH に含まれていると、意図しないコマンドが実行されるリスクがあります。セキュリティの観点から、必要最小限の PATH に制限されています。

対策は2つあります。

• フルパスで指定する — date ではなく /usr/bin/date と書く。コマンドのフルパスは which date で確認できる
• crontab 内で PATH を定義する — crontab の先頭行に PATH=/usr/local/bin:/usr/bin:/usr/sbin:/bin と書くことで、以降のジョブにその PATH が適用される

ユーザー crontab と /etc/crontab の実行環境の違い

ここまで見てきたのはユーザー crontab（crontab -e で編集するもの）の環境です。一方、/etc/crontab（次のセクションで詳しく解説）には異なるデフォルト値が設定されています。

項目	ユーザー crontab	/etc/crontab
SHELL	/bin/sh	/bin/bash
PATH	/usr/bin:/bin	/sbin:/bin:/usr/sbin:/usr/bin

/etc/crontab のほうが PATH が広く、/usr/sbin なども含まれています。とはいえ /usr/local/bin は含まれないため、フルパス指定の習慣はどちらでも有効です。

/etc/crontab とシステム cron

ここまでは crontab -e で編集するユーザー個人の cron ジョブを扱いました。Linux にはもう1つ、システム全体の定期ジョブを管理する仕組みがあります。

/etc/crontab を読む

alma-mainで実行してください。

実行コマンド：

$ cat /etc/crontab

実行結果：

SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root

# For details see man 4 crontabs

# Example of job definition:
# .---------------- minute (0 - 59)
# |  .------------- hour (0 - 23)
# |  |  .---------- day of month (1 - 31)
# |  |  |  .------- month (1 - 12) OR jan,feb,mar,apr ...
# |  |  |  |  .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# |  |  |  |  |
# *  *  *  *  * user-name  command to be executed

先頭の3行が環境変数の設定です。

• SHELL=/bin/bash — /etc/crontab のジョブは bash で実行される（ユーザー crontab の /bin/sh とは異なる）
• PATH=/sbin:/bin:/usr/sbin:/usr/bin — ユーザー crontab より広い PATH が設定されている
• MAILTO=root — ジョブの標準出力・標準エラー出力を root ユーザーにメールで送信する設定。メールサーバーが未設定の場合は送信されない

コメント行に書式の説明が記載されています。ユーザー crontab との違いは、user-name フィールドがある点です。/etc/crontab や /etc/cron.d/ のファイルでは「どのユーザーとして実行するか」を指定します。

/etc/cron.d/ と cron.hourly/daily/weekly/monthly

システムの定期ジョブはもう1つ、/etc/cron.d/ ディレクトリにファイルとして配置する方法があります。パッケージが独自の定期ジョブを追加するときに、この方式がよく使われます。

alma-mainで実行してください。

実行コマンド：

$ cat /etc/cron.d/0hourly

実行結果：

# Run the hourly jobs
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
01 * * * * root run-parts /etc/cron.hourly

毎時01分に root ユーザーとして run-parts /etc/cron.hourly を実行しています。run-parts は指定ディレクトリ内の実行可能ファイルをすべて順番に実行するコマンドです。

/etc/cron.hourly/ の中身を見てみます。

実行コマンド：

$ ls /etc/cron.hourly/

実行結果：

0anacron

0anacron というスクリプトだけがあります。これが anacron を起動し、/etc/cron.daily/、/etc/cron.weekly/、/etc/cron.monthly/ のジョブを処理します。流れを整理すると以下のようになります。

/etc/cron.d/0hourly（毎時01分）
  → run-parts /etc/cron.hourly/
    → 0anacron を実行
      → anacron が /etc/cron.daily/, /etc/cron.weekly/, /etc/cron.monthly/ を処理

anacron は「前回の実行から指定日数が経過していれば実行する」という仕組みです。通常の cron は指定時刻にサーバーが停止していると実行されませんが、anacron は「電源が入っていなかった間にやるべきだったジョブ」を起動後に実行します。この仕組みにより、メンテナンスで再起動した後でも定期ジョブが確実に実行されます。

実運用での使い分けをまとめます。

• 個人のジョブ → crontab -e で登録
• システムのジョブ → /etc/cron.d/ にファイルを配置
• 日次・週次・月次のシステムジョブ → /etc/cron.daily/ 等にスクリプトを配置（anacron 経由で実行される）

systemd timer

cron は Linux の定期実行の仕組みとして長い歴史がありますが、第13回で学んだ systemd にも定期実行の仕組みがあります。それが systemd timer です。AlmaLinux 9 では logrotate のようにシステム管理系のジョブが cron から systemd timer に移行しています。

既存のタイマーを確認する

現在有効な systemd timer を確認してみます。alma-mainで実行してください。

実行コマンド：

$ systemctl list-timers --no-pager

実行結果：

NEXT                        LEFT          LAST                        PASSED       UNIT                         ACTIVATES
Fri 2026-04-03 21:33:20 JST 1h 30min left Fri 2026-04-03 20:00:07 JST 2min 51s ago dnf-makecache.timer          dnf-makecache.service
Sat 2026-04-04 00:00:00 JST 3h 57min left Fri 2026-04-03 20:00:07 JST 2min 51s ago logrotate.timer              logrotate.service
Sat 2026-04-04 19:31:53 JST 23h left      Thu 2026-04-02 20:59:46 JST 23h ago      systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service

3 timers listed.
Pass --all to see loaded but inactive timers, too.

※ NEXT/LAST のタイムスタンプは環境によって異なります。

各列の意味は以下のとおりです。

列	意味
NEXT	次回の実行予定時刻
LEFT	次回実行までの残り時間
LAST	前回の実行時刻
PASSED	前回実行からの経過時間
UNIT	タイマーユニット名（.timer）
ACTIVATES	タイマーが起動するサービスユニット名（.service）

3つのタイマーが登録されています。

• dnf-makecache.timer — 第19回で学んだ dnf のキャッシュ更新を自動で行う
• logrotate.timer — 前回学んだ logrotate を毎日実行する
• systemd-tmpfiles-clean.timer — /tmp 等の一時ファイルを定期的に削除する

logrotate.timer の仕組みを読み解く

前回「logrotate はデーモンではなく定期的に呼び出されるコマンド」と学びました。では誰が呼び出しているのか。その答えが logrotate.timer です。

systemd timer は「.timer ユニット」と「.service ユニット」のペアで動作します。.timer がスケジュールを管理し、指定時刻になると同名の .service を起動します。

まず .timer ユニットを見てみます。alma-mainで実行してください。

実行コマンド：

$ systemctl cat logrotate.timer

実行結果：

# /usr/lib/systemd/system/logrotate.timer
[Unit]
Description=Daily rotation of log files
Documentation=man:logrotate(8) man:logrotate.conf(5)

[Timer]
OnCalendar=daily
AccuracySec=1h
Persistent=true

[Install]
WantedBy=timers.target

[Timer] セクションの各設定の意味は以下のとおりです。

設定	値	意味
OnCalendar	daily	毎日0時に実行する（cron の 0 0 * * * に相当）
AccuracySec	1h	実行時刻に最大1時間のランダムな遅延を加える。複数のタイマーが同時刻に集中するのを避ける仕組み
Persistent	true	前回の実行時刻を記録し、サーバーが停止中に実行時刻を過ぎた場合、起動後すぐに実行する。anacron と同じ考え方

次に .service ユニットを見てみます。

実行コマンド：

$ systemctl cat logrotate.service

実行結果：

# /usr/lib/systemd/system/logrotate.service
[Unit]
Description=Rotate log files
Documentation=man:logrotate(8) man:logrotate.conf(5)
RequiresMountsFor=/var/log
ConditionACPower=true

[Service]
Type=oneshot
ExecStart=/usr/sbin/logrotate /etc/logrotate.conf

※ この下にセキュリティ強化のオプションが続きますが省略します。

重要なポイントを読み解きます。

• Type=oneshot — 常駐せず、実行したら終了するタイプ。定期実行されるジョブに適している
• ExecStart=/usr/sbin/logrotate /etc/logrotate.conf — 前回学んだ logrotate コマンドそのもの
• ConditionACPower=true — AC電源が接続されている場合のみ実行。ノートPCのバッテリー駆動時は実行しない

つまり、logrotate.timer が毎日0時ごろに logrotate.service を起動し、logrotate.service が /usr/sbin/logrotate を実行する、という流れです。

タイマーの状態も確認してみます。

実行コマンド：

$ systemctl status logrotate.timer --no-pager -l

実行結果：

● logrotate.timer - Daily rotation of log files
     Loaded: loaded (/usr/lib/systemd/system/logrotate.timer; enabled; preset: enabled)
     Active: active (waiting) since Tue 2026-03-31 05:28:29 JST; 3 days ago
      Until: Tue 2026-03-31 05:28:29 JST; 3 days ago
    Trigger: Sat 2026-04-04 00:00:00 JST; 3h 57min left
   Triggers: ● logrotate.service
       Docs: man:logrotate(8)
             man:logrotate.conf(5)

※ タイムスタンプは環境によって異なります。

active (waiting) はタイマーが有効で次の実行時刻を待っている状態です。Trigger に次回の実行予定が、Triggers に起動するサービスが表示されています。

systemd timer の詳しい設定オプションは man systemd.timer で確認できます。

cron と systemd timer の使い分け

Linux には cron と systemd timer という2つの定期実行の仕組みがあることを学びました。それぞれの特徴を比較します。

項目	cron	systemd timer
設定場所	crontab -e、/etc/cron.d/	.timer + .service ユニットファイル
ログ確認	/var/log/cron	journalctl -u サービス名
依存関係	なし	systemd の依存関係管理が使える（After=、Requires= 等）
実行環境	PATH が制限される（罠あり）	systemd サービスと同じ環境
停止中の補完	anacron で対応（daily/weekly/monthly のみ）	Persistent=true で対応（すべてのタイマーで設定可能）
操作方法	crontab -e / -l / -r	systemctl start/stop/enable

実運用での使い分けの目安は以下のとおりです。

• cron が向いている場合 — ユーザー個人の定期ジョブ、手軽に1行でスケジュール登録したい場合。crontab -e で1行書くだけなので手軽
• systemd timer が向いている場合 — システム管理系のジョブ、依存関係の管理が必要な場合、ログを journalctl で一元管理したい場合

AlmaLinux 9 では logrotate が systemd timer に移行済みであるように、システム管理系のジョブは systemd timer が主流になりつつあります。ただし cron がなくなるわけではなく、両方を理解しておく必要があります。

やってみよう

ここまで学んだ内容を手を動かして確認します。alma-mainで実行してください。

課題1: crontab でジョブを登録・確認・削除する

以下の手順を順番に実行してください。

手順1: 毎分 date コマンドの出力を追記するジョブを登録します。

実行コマンド：

$ echo "* * * * * /usr/bin/date >> /tmp/cron-date.log" | crontab -

手順2: 登録されたことを確認します。

実行コマンド：

$ crontab -l

* * * * * /usr/bin/date >> /tmp/cron-date.log と表示されれば成功です。

手順3: 約1分待ってから、ログファイルの内容と /var/log/cron を確認します。

実行コマンド：

$ cat /tmp/cron-date.log

日時が出力されていれば、cron ジョブが正常に動作しています。

実行コマンド：

$ sudo tail -5 /var/log/cron

CROND の実行ログに developer ユーザーのジョブが記録されていることを確認してください。

手順4: 確認が終わったらクリーンアップします。テスト用ジョブは必ず削除してください。

実行コマンド：

$ crontab -r
$ rm -f /tmp/cron-date.log
$ crontab -l

no crontab for developer と表示されれば、クリーンアップ完了です。

課題2: PATH 問題を体験する

cron の PATH 制限を実際に体験します。

手順1: テスト用スクリプトを作成します。

実行コマンド：

$ mkdir -p ~/scripts
$ cat <<'EOF' > ~/scripts/cron-path-test.sh
#!/bin/bash
echo "$(date): PATH test OK" >> /tmp/cron-path-test.log
EOF
$ chmod +x ~/scripts/cron-path-test.sh

手順2: フルパスなしでスクリプトを cron に登録します。

実行コマンド：

$ echo "* * * * * cron-path-test.sh" | crontab -

手順3: 約1分待ってから /var/log/cron を確認します。

実行コマンド：

$ sudo tail -5 /var/log/cron

CROND のログにジョブの実行記録はありますが、/tmp/cron-path-test.log は作成されていないはずです。~/scripts/ は cron の PATH（/usr/bin:/bin）に含まれないため、コマンドが見つからずに失敗しています。

手順4: フルパスに修正して再登録します。

実行コマンド：

$ echo "* * * * * /home/developer/scripts/cron-path-test.sh" | crontab -

約1分待ってから確認します。

実行コマンド：

$ cat /tmp/cron-path-test.log

今度は日時とともに「PATH test OK」と出力されているはずです。フルパスで指定することの重要性を体感できたでしょうか。

手順5: クリーンアップします。

実行コマンド：

$ crontab -r
$ rm -f /tmp/cron-path-test.log ~/scripts/cron-path-test.sh
$ rmdir ~/scripts 2>/dev/null

課題3: systemd timer の設定を読み解く

手順1: 既存のタイマー一覧を確認します。

実行コマンド：

$ systemctl list-timers --no-pager

logrotate.timer の NEXT 列を確認し、次回の実行予定時刻を読み取ってください。

手順2: logrotate.timer の設定内容を確認します。

実行コマンド：

$ systemctl cat logrotate.timer

以下の3点を読み取ってみてください。

• OnCalendar の値は何か（実行スケジュール）
• AccuracySec の値は何か（実行時刻のずれの許容範囲）
• Persistent の値は何か（サーバー停止中の補完）

答え: OnCalendar=daily（毎日0時）、AccuracySec=1h（最大1時間のランダム遅延）、Persistent=true（停止中に実行時刻を過ぎた場合、起動後に実行する）です。

まとめと次回予告

今回のポイントを3つにまとめます。

• cron は「分 時 日 月 曜日 コマンド」の書式でスケジュールを登録する。 ただし cron の実行環境はログインシェルと異なり、PATH が制限されるため、コマンドはフルパスで指定する
• 個人のジョブは crontab -e、システムのジョブは /etc/cron.d/ に配置する。 /etc/cron.d/0hourly → anacron → cron.daily/weekly/monthly という連鎖でシステムの定期ジョブが実行される
• systemd timer は .timer と .service のペアで動作する。 AlmaLinux 9 では logrotate が systemd timer に移行済み。Persistent=true により、cron にはない「停止中の補完」が可能

次回の第25回「ストレージ管理（LVM）」では、fdisk でディスクにパーティションを作成し、LVM（論理ボリュームマネージャ）で柔軟にストレージを管理する方法を学びます。cron でスクリプトを定期実行する場面は第26回、バックアップの自動化は第31回で扱います。

理解度チェック

以下の文が正しければ ○、誤りであれば × を答えてください。

以下、解答です。

シリーズ一覧

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