cron timer chrony LinuC102 第6回

LinuC レベル1 102試験対策シリーズの第6回です。前回はユーザとグループの仕組み、sudo の安全な編集を扱いました。今回は 「いつ実行するか」「正しい時刻か」 を支える2つの仕組み、ジョブスケジューリング（cron と systemd timer）と 時刻同期（chrony / NTP / timedatectl）を扱います。バックアップ・ログローテーション・監視データ収集など現場の定期処理を支える土台です。

今ここマップ

LinuC 102 試験対策シリーズ（全12回）

  第1回 シェル環境のカスタマイズ
  第2回 Bashスクリプト入門
  第3回 ネットワーク基礎
  第4回 ネットワークトラブルシューティングとDNS
  第5回 ユーザ・グループ管理と sudo 設定
▶ 第6回 ジョブスケジューリングと時刻管理    ← いまここ
  第7回 ログ管理実践
  第8回 メール配送エージェント(MTA)の基本
  第9回 ファイアウォールと SELinux 入門
  第10回 暗号化によるデータ保護
  第11回 クラウドセキュリティの基礎
  第12回 オープンソースの文化

この記事で身につくこと

1. crontab の書式（分 時 日 月 曜日）を読み書きできる
2. /etc/crontab と /etc/cron.{hourly,daily,weekly,monthly} /etc/cron.d/ の役割を説明できる
3. systemctl list-timers で systemd timer 一覧を確認し、cron との使い分けを判断できる
4. chronyc tracking chronyc sources で NTP 同期状態を確認できる
5. timedatectl でタイムゾーンと NTP 有効/無効を管理できる

第1章：なぜ「決まった時刻」と「定期実行」が大切なのか

1.1 定期実行の正体は3つの仕組みの組み合わせ

「毎晩03時にバックアップを取る」「毎時データを収集する」「毎週ログをローテーションする」── どれも 当たり前のように動いていますが、内側では 3つの仕組み が連携しています。

• いつ実行するか ── cron または systemd timer
• 正しい時刻か ── chrony（NTP クライアント）
• ローテーション ── logrotate（次回第7回で扱う）

1.2 時刻ズレが引き起こす実害 ── 誰のために時刻を合わせるのか

「サーバの時計なんて多少ズレていても困らないでしょう」と思ってしまいがちです。実際には次のような実害が起こります。

• 運用担当のため：複数台サーバのログを時系列で並べて障害を再現する。1台だけ5分ズレていると、原因系のサーバの「先」に結果系のログが見えてしまい、因果関係を読み違える
• セキュリティ担当のため：SSL/TLS 証明書は「有効期限」を時計で判定する。サーバ時計が将来にズレていると有効な証明書を「期限切れ」と誤判定する。Kerberos 認証は5分以上のズレでチケットが無効化される
• 監査担当のため：「誰がいつ何をしたか」の auth.log 記録は時刻が信頼できないと法的証拠にならない
• 分散システムのため：データベースのレプリケーション、ETCD の合意形成、Kafka のメッセージ順序 ── 全部「時刻が揃っている前提」で動く

だから現代のLinux運用は「時刻が合っていることを当たり前にする」ために、NTP 同期を 標準で稼働させ続ける 構成を取ります。AlmaLinux 9 でも chrony が既定で起動しています。

第2章：cron ── 古典の定番

2.1 cron の役割と稼働確認

Linux で長年使われてきた定期実行の仕組みが cron（クロン）です。RHEL系では cronie パッケージとして提供され、crond デーモンが常時動作します。

実行コマンド（linuc-alma）：

$ systemctl is-active crond
$ systemctl is-enabled crond

実行結果：

active
enabled

稼働中かつ自動起動有効。これが既定状態です。

2.2 5フィールド書式

cron の1行はスペース区切りの 5フィールド + コマンド です。

分  時  日  月  曜日   コマンド
 *   *   *   *   *    /path/to/command

各フィールドで使える特殊記法は次の4つです。

典型例を読んでみます。

2.3 user crontab ── 自分専用の cron

各ユーザが自分専用の cron を持てます。これを「user crontab」と呼びます。実体は /var/spool/cron/<ユーザ名> に保存されますが、ユーザが直接編集することはなく、crontab コマンドを介して操作します。

新しく作る／確認する／消す流れを実機で見てみます（最初は何も登録されていない状態）。

実行コマンド（linuc-alma、developer）：

$ crontab -l 2>&1

実行結果：

no crontab for developer

登録する場合、crontab -e がインタラクティブなエディタを起動しますが、ここでは 標準入力から流し込む方式 を使います（自動化スクリプトでよく使う手）。

実行コマンド（linuc-alma）：

$ (echo "# LinuC test"; echo "*/5 * * * * /bin/true") | crontab -
$ crontab -l

実行結果：

# LinuC test
*/5 * * * * /bin/true

削除します。

実行コマンド（linuc-alma）：

$ crontab -r
$ crontab -l 2>&1

実行結果：

no crontab for developer

2.4 cron.allow / cron.deny によるアクセス制御

誰が crontab を使えるかは2つのファイルで制御されます。

• /etc/cron.allow が 存在する場合：そのファイルに名前があるユーザだけ許可（deny は無視）
• /etc/cron.allow が 存在しない場合：/etc/cron.deny に名前があるユーザは拒否、それ以外は許可
• 両方とも存在しない場合：root のみ許可

AlmaLinux 9 の既定状態を見ます。

実行コマンド（linuc-alma）：

$ ls -la /etc/cron.deny /etc/cron.allow 2>&1

実行結果：

ls: '/etc/cron.allow' にアクセスできません: そのようなファイルやディレクトリはありません
-rw-r--r--. 1 root root 0  3月 12  2025 /etc/cron.deny

cron.allow 無し、cron.deny 空 = 全ユーザ許可（既定の挙動）。本番では「cron.allow に決められたサービスユーザだけ書く」運用も多いです。

第3章：システム cron と /etc/crontab

3.1 /etc/crontab ── 現代のAlmaLinuxでは「テンプレート」

/etc/crontab は システム全体の cron 設定 で、ユーザの crontab とは別物です。user crontab と異なり、6番目のフィールドに「実行ユーザ名」 が入る点が特徴です（user crontab は自分自身として実行される）。

実行コマンド（linuc-alma）：

$ 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

注目すべき点が2つあります。

• 冒頭3行で 環境変数 を設定している（SHELL PATH MAILTO）。cron 実行時は対話シェルが立ち上がらないため、明示的に PATH を指定しないと「手では動くのに cron だと動かない」が起こる
• 実ジョブは1行も無い。AlmaLinux 9 では実ジョブは /etc/cron.d/0hourly に分離されている

3.2 /etc/cron.{hourly,daily,weekly,monthly} ── ファイルを置くだけ

定期実行したいスクリプトを置くだけで、毎時／毎日／毎週／毎月走らせるための4つの標準ディレクトリがあります。

実行コマンド（linuc-alma）：

$ ls /etc/cron.hourly/
$ ls /etc/cron.daily/
$ ls /etc/cron.weekly/
$ ls /etc/cron.monthly/
$ ls /etc/cron.d/

実行結果：

0anacron
（cron.daily は空）
（cron.weekly は空）
（cron.monthly は空）
0hourly

Minimal Install では cron.daily 以下が空です。パッケージをインストールすると /etc/cron.daily/<パッケージ名> のような形でスクリプトが自動配置されます（例：かつての logrotate）。なお AlmaLinux 9 の logrotate は logrotate.timer（systemd timer、後述）に移行しています。

/etc/cron.d/ は パッケージごとの cron 行分割管理 用です。0hourly は cronie パッケージが提供するもので、これが cron.hourly/ 配下のスクリプトを毎時起動します。さらに cron.hourly/0anacron が anacron を呼び出して、cron.daily/weekly/monthly を順次走らせる二段構造になっています。

3.3 anacron ── 電源が切れていた間を補完する

cron は「指定時刻にサーバが起動していない」とジョブを取りこぼします。サーバなら24時間稼働で問題ありませんが、デスクトップ・ノートPC・夜間停止サーバでは cron.daily が走らないまま消化されない事態になります。

anacron は「最後に走ってから N 時間以上経っていれば走らせる」という別の発想で、シャットダウン時刻を補完します。AlmaLinux 9 では cronie-anacron パッケージで自動稼働しており、サーバ用途でも入っています。

第4章：systemd timer ── 現代の選択肢

4.1 cron と systemd timer の違い

systemd の登場以降、cron の機能の多くは systemd timer に置き換わりつつあります。両者は同じ「定期実行」でも設計思想が異なります。

AlmaLinux 9 では logrotate、dnf-makecache、systemd-tmpfiles-clean など、かつて cron で動いていたジョブの多くが systemd timer に移行しています。

4.2 list-timers で稼働中の timer を見る

実行コマンド（linuc-alma）：

$ systemctl list-timers --all --no-pager

実行結果（採取時点のスナップショット）：

NEXT          LEFT       LAST           PASSED     UNIT           ACTIVATES
Thu 2026-05-… 26min left Wed 2026-05-1… 15h ago    logrotate.tim… logrotate.ser…
Thu 2026-05-… 48min left Wed 2026-05-1… 15h ago    dnf-makecache… dnf-makecache…
Thu 2026-05-… 21h left   Sat 2026-05-0… 4 days ago systemd-tmpfi… systemd-tmpfi…

3 timers listed.

列の意味は次のとおりです。

• NEXT：次回実行予定
• LEFT：次回までの残り時間
• LAST：前回実行時刻
• PASSED：前回からの経過時間
• UNIT：timer ユニット名
• ACTIVATES：起動される service 名

4.3 .timer と .service の中身を読む

dnf-makecache.timer を例に、2つのファイルの中身を見てみます。

実行コマンド（linuc-alma）：

$ systemctl cat dnf-makecache.timer

実行結果：

# /usr/lib/systemd/system/dnf-makecache.timer
[Unit]
Description=dnf makecache --timer
ConditionKernelCommandLine=!rd.live.image
# See comment in dnf-makecache.service
ConditionPathExists=!/run/ostree-booted
Wants=network-online.target

[Timer]
OnBootSec=10min
OnUnitInactiveSec=1h
RandomizedDelaySec=60m
Unit=dnf-makecache.service

[Install]
WantedBy=timers.target

主要な指示子は次の意味です。

対応する .service ファイルが「実際に何を実行するか」を持ちます。

実行コマンド（linuc-alma）：

$ systemctl cat dnf-makecache.service

実行結果（抜粋）：

# /usr/lib/systemd/system/dnf-makecache.service
[Unit]
Description=dnf makecache
ConditionPathExists=!/run/ostree-booted
After=network-online.target

[Service]
Type=oneshot
Nice=19
IOSchedulingClass=2
IOSchedulingPriority=7
Environment="ABRT_IGNORE_PYTHON=1"
ExecStart=/usr/bin/dnf makecache --timer

cron と比べると、ネットワーク準備完了を After=network-online.target で待ち、IO スケジューリングを下げ、終了したら戻る（Type=oneshot）という細かい制御が可能です。

4.4 OnCalendar の書式

cron に近い記法は OnCalendar= で書きます。

第5章：時刻同期の仕組み ── NTP と chrony

5.1 NTP の階層（stratum）

NTP（Network Time Protocol）は「正確な時刻を持つサーバから階層的に時刻を配る」プロトコルです。階層を stratum（ストラタム）と呼びます。

• Stratum 0：基準クロック（原子時計、GPS、電波時計）。直接ネットワークには出ない
• Stratum 1：Stratum 0 に直接つながるサーバ（公開 NTP サーバの中で最上位）
• Stratum 2〜15：それぞれ1つ上の階層から同期
• Stratum 16：未同期（信頼できない）

5.2 chrony と ntpd

Linux で NTP クライアントを担うソフトウェアは2つの系譜があります。

AlmaLinux 9 では chrony が既定です。

5.3 /etc/chrony.conf を読む

chrony の設定ファイルからコメント・空行を除いた主要行を見ます。

実行コマンド（linuc-alma）：

$ grep -v '^#' /etc/chrony.conf | grep -v '^$'

実行結果：

sourcedir /run/chrony-dhcp
driftfile /var/lib/chrony/drift
makestep 1.0 3
rtcsync
keyfile /etc/chrony.keys
ntsdumpdir /var/lib/chrony
leapsectz right/UTC
logdir /var/log/chrony
server 10.0.10.131 iburst

主要な指示子の意味は次のとおりです。

linuc-alma は社内（検証環境内）の NTP サーバ 10.0.10.131（linuc-proxy）から時刻を取っています。本番の社外サーバでは pool 2.rhel.pool.ntp.org iburst のような公開プールを指定するのが定番です。

5.4 chronyc tracking ── 同期状態を見る

実行コマンド（linuc-alma）：

$ chronyc tracking

実行結果（採取時点）：

Reference ID    : 0A000A83 (linuc-proxy.linuc.local)
Stratum         : 4
Ref time (UTC)  : Wed May 13 14:33:15 2026
System time     : 0.000275428 seconds slow of NTP time
Last offset     : +0.483545661 seconds
RMS offset      : 0.574119985 seconds
Frequency       : 22.314 ppm fast
Residual freq   : +1.237 ppm
Skew            : 0.676 ppm
Root delay      : 0.118430741 seconds
Root dispersion : 0.013039490 seconds
Update interval : 65.2 seconds
Leap status     : Normal

運用で見るべき項目は次の3つです。

• Reference ID：現在の同期先（ここでは linuc-proxy）
• Stratum：自分の階層（linuc-proxy が Stratum 3 なので、linuc-alma は Stratum 4）
• Leap status：Normal なら正常。Not synchronised なら未同期

5.5 chronyc sources ── 参照先サーバ一覧

実行コマンド（linuc-alma）：

$ chronyc sources

実行結果：

MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^* linuc-proxy.linuc.local       3   6   377    11   +279us[ +484ms] +/-   72ms

先頭2文字（MS列）が状態を表します。

Reach は 8進数のビット列で、直近8回の応答状況を表します。377（8進）= 11111111（2進）= 直近8回すべて成功という意味で、正常に同期している証拠です。

第6章：timedatectl と date / hwclock

6.1 timedatectl ── 1コマンドで5情報

systemd の timedatectl は、時刻・タイムゾーン・NTP有効/無効・RTC を 1コマンドで統合管理 します。

実行コマンド（linuc-alma）：

$ timedatectl

実行結果：

               Local time: 水 2026-05-13 23:33:27 JST
           Universal time: 水 2026-05-13 14:33:27 UTC
                 RTC time: 水 2026-05-13 14:33:26
                Time zone: Asia/Tokyo (JST, +0900)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

• Local time / Universal time：ローカル時刻（JST）と協定世界時（UTC）の両方を見せる
• RTC time：マザーボード上の RTC（ハードウェア時計）の値。UTC で記録されている
• System clock synchronized: yes：NTP 同期できている
• NTP service: active：chrony や systemd-timesyncd が稼働
• RTC in local TZ: no：RTC は UTC で持つ（Linux 標準）。Windows 互換のため yes にする場合もある

6.2 主要操作

6.3 date と hwclock

date はシステム時計（カーネルが持つ時計）の表示・設定です。表示はユーザ権限で可能、変更は root が必要です。

実行コマンド（linuc-alma）：

$ date
$ date "+%Y-%m-%d %H:%M:%S %z"

実行結果：

2026年  5月 13日 水曜日 23:33:27 JST
2026-05-13 23:33:27 +0900

フォーマット指定文字は %Y 年（4桁）、%m 月、%d 日、%H 時（24h）、%M 分、%S 秒、%z タイムゾーン等です（詳細は man date）。バックアップファイル名に日付を入れるときの定番として使われます。

hwclock は RTC（ハードウェア時計） を直接読み書きします。root 権限が必要です。

実行コマンド（linuc-alma）：

$ sudo hwclock

実行結果：

2026-05-13 23:33:27.003946+09:00

RTC は UTC で記録されていますが、表示はローカルタイムゾーン（+09:00）に変換されています。NTP が動いている環境で hwclock を手動で叩く必要はほぼありませんが、サーバを長期停止した後の再起動時に「RTC が大きくズレている」状況の調査などで使います。

第7章：現場での使いどころ

現場での使いどころ

本章で扱った内容は、現場の以下の場面で日常的に使われます。

• 日次バックアップ：毎晩 03:00 にデータベースダンプ＋ファイル同期。新規実装は OnCalendar=*-*-* 03:00:00 の systemd timer、既存資産は /etc/cron.d/backup の cron 行
• ログローテーション：AlmaLinux 9 では logrotate.timer が毎日自動実行（次回第7回で扱う）。ローテーション漏れがあると /var/log がディスクを食いつぶす
• 監視データ収集：5分ごとの CPU/メモリ／15分ごとのプロセス一覧／1時間ごとのディスク使用率。cron なら */5 * * * *、timer なら OnUnitInactiveSec=5min
• SSL 証明書更新：Let’s Encrypt の certbot は certbot.timer として動く。期限の30日前から自動更新。時刻が大きくズレているサーバでは「証明書を期限切れと誤判定」して更新失敗する
• クラスタの時刻同期：Kubernetes、Kafka、Elasticsearch、PostgreSQL レプリケーションすべて時刻一致が前提。クラスタ内の全ノードで同じ NTP サーバを chrony.conf に指定し、chronyc tracking で揃っていることを定期確認する
• 仮想マシンの時刻ジャンプ対策：スナップショット復元やライブマイグレーションで時刻が飛ぶことがある。makestep 1.0 3 を設定しておけば、起動後の最初の3回までは秒単位のズレを瞬時補正してくれる
• 監査ログの相関分析：複数サーバ・複数サービスのログを SIEM（Security Information and Event Management）で突き合わせる際、時刻が揃っていないと因果関係が読めなくなる

第8章：ヒヤリハット

0 3 * * * /opt/scripts/backup-db.sh

第9章：やってみよう

linuc-alma にログインして次の4つの演習を順に実行してください。所要時間は20〜30分です。crontab の操作以外は全て読み取りのため、システム設定を壊す心配はありません。

演習1：自分の crontab を作る・確認する・消す

実行コマンド（linuc-alma、developer）：

$ crontab -l 2>&1
$ (echo "# LinuC test"; echo "*/5 * * * * /bin/true") | crontab -
$ crontab -l
$ crontab -r
$ crontab -l 2>&1

確認ポイント：

• 初回と削除後に no crontab for developer が表示される
• 登録後は2行が見える（コメント行とジョブ行）
• もし時間があれば、本物のテストとして * * * * * date >> /tmp/cron-test.log を登録し、2〜3分待ってログが追記されることを確認してから消す

演習2：システム cron を読む

実行コマンド（linuc-alma）：

$ cat /etc/crontab
$ ls /etc/cron.hourly/ /etc/cron.daily/ /etc/cron.weekly/ /etc/cron.monthly/
$ ls /etc/cron.d/
$ cat /etc/cron.d/0hourly
$ ls -la /etc/cron.deny /etc/cron.allow 2>&1

確認ポイント：

• /etc/crontab がテンプレートだけになっていること（実ジョブは無い）
• /etc/cron.d/0hourly が cron.hourly を起動する役割になっていること
• /etc/cron.allow が無い、/etc/cron.deny が空 = 既定で全ユーザ許可

演習3：systemd timer を観察する

実行コマンド（linuc-alma）：

$ systemctl list-timers --all --no-pager
$ systemctl cat dnf-makecache.timer
$ systemctl cat dnf-makecache.service
$ systemctl status dnf-makecache.timer --no-pager

確認ポイント：

• 3つの timer（logrotate、dnf-makecache、systemd-tmpfiles-clean）が並ぶこと
• timer ファイルに OnBootSec と OnUnitInactiveSec が両方ある
• service ファイルに ExecStart=/usr/bin/dnf makecache --timer がある
• status で「Active: active (waiting)」と次の Trigger 時刻が見える

演習4：時刻と NTP を確認する

実行コマンド（linuc-alma）：

$ timedatectl
$ chronyc tracking
$ chronyc sources
$ date
$ date "+%Y-%m-%d %H:%M:%S %z"
$ sudo hwclock

確認ポイント：

• timedatectl の「System clock synchronized: yes」と「NTP service: active」
• chronyc tracking の Reference ID が linuc-proxy.linuc.local、Stratum が 4
• chronyc sources の左端が ^*（現在の同期先）
• date と hwclock が秒単位で揃っている（差は rtcsync が11分間隔で同期しているため最大数百ms）

困ったらマニュアルを引きます。man crontab（書式は man 5 crontab）man systemd.timer man systemd.time man chronyc man chrony.conf man timedatectl man hwclock。chronyc help や systemctl --help でサブコマンド一覧も取り出せます。

理解度チェック

次の5問を ○×で答えてください。解答は記事末尾にあります。

1. cron で「毎日 03:00 にスクリプトを実行する」書式は 0 3 * * * である。
2. /etc/crontab と user crontab の違いの1つは、/etc/crontab には実行ユーザ名のフィールドが入る点である。
3. systemd timer は .timer ファイル単独で完結し、対応する .service ファイルは不要である。
4. chronyc tracking で表示される Stratum が 16 は「未同期」を意味する。
5. cron で「手では動くのに cron だと動かない」が起こったとき、最初に疑うのは PATH 環境変数である。

解答

1. ○（分=0、時=3、日=*、月=*、曜日=*）
2. ○（user crontab は5フィールド、/etc/crontab は6フィールドで、6番目がユーザ名）
3. ×（.timer + .service の2ファイル構成。.timer が時刻を、.service が実行内容を担当）
4. ○（Stratum 16 は信頼できない／未同期。chrony 起動直後や NTP サーバが届かない時に出る）
5. ○（cron は対話シェルと異なり最小 PATH しか持たない。絶対パスか、明示的に PATH=... を crontab 内に書く）

次回予告

次回（第7回）は 「ログ管理実践 — journalctl と rsyslog の使い分け」 です。systemd-journald が出力するバイナリログを journalctl でフィルタリングする方法、/etc/rsyslog.conf の facility / severity の読み方、複数サーバのログを linuc-ubuntu に集約するリモート syslog 構成までを扱います。今回学んだ「定期実行」と「正確な時刻」が、ログ調査の前提として効いてきます。

LinuC 102 試験対策シリーズ（全12回）

1. シェル環境のカスタマイズ：環境変数・エイリアス・履歴・ロケール
2. Bashスクリプト入門：if/for/関数で書く現場の自動化スクリプト
3. ネットワーク基礎：TCP/IP・ip コマンド・NetworkManager
4. ネットワークトラブルシューティングとDNSクライアント設定
5. ユーザ・グループ管理と sudo 設定の実務（useradd, visudo）
6. ジョブスケジューリングと時刻管理：cron, systemd timer, chrony, NTP
7. ログ管理実践：journalctl と rsyslog の使い分け
8. メール配送エージェント(MTA)の基本：postfix の動作確認
9. ファイアウォール（firewalld / ufw）と SELinux 入門
10. 暗号化によるデータ保護：SSH鍵認証・GnuPG・OpenSSL
11. クラウドセキュリティの基礎：IAM・公開鍵管理・SSH踏み台構成
12. オープンソースの文化：主要ライセンス（GPL/MIT/Apache）とコミュニティ