はじめに#
サーバー運用では、バックアップの実行、ログのローテーション、定期的なデータ同期など、決まった時間に自動でタスクを実行する仕組みが不可欠です。Linuxではこのタスクスケジューリングを実現する方法として、伝統的な「cron」と、現代的な「systemdタイマー」の2つの選択肢があります。
cronは40年以上の歴史を持つ実績あるツールで、多くのシステム管理者に親しまれています。一方、systemdタイマーはsystemdエコシステムの一部として、より柔軟な制御とログ管理機能を提供します。
本記事では、cronの基本構文からsystemdタイマーの実践的な設定方法まで、タスクスケジューリングの全体像を解説します。両方の仕組みを理解することで、状況に応じた最適な選択ができるようになります。
前提条件と動作確認環境#
本記事の内容は以下の環境で動作確認しています。
| 項目 |
内容 |
| OS |
Ubuntu 24.04 LTS / AlmaLinux 9 |
| cron |
cronie 1.6.1 |
| systemd |
255 |
| シェル |
bash 5.2 |
WSL2環境でも基本的なcron操作は可能ですが、systemdタイマーを使用するにはsystemdが有効化されている必要があります。
cronとは#
cronは、Unix系システムで定期的にコマンドやスクリプトを実行するためのデーモンプロセスです。cronデーモン(crond)がバックグラウンドで常駐し、設定ファイル(crontab)に記述されたスケジュールに従ってタスクを実行します。
graph TB
A[cronデーモン<br/>crond] --> B{毎分チェック}
B --> C[crontabファイル]
C --> D{実行時刻?}
D -->|一致| E[コマンド実行]
D -->|不一致| B
E --> F[結果をメール送信<br/>または出力]
F --> Bcronの種類#
Linuxには複数のcron実装が存在します。
| 実装 |
特徴 |
主な採用ディストリビューション |
| cronie |
Red Hat系で標準採用、SELinux対応 |
RHEL、AlmaLinux、Rocky Linux |
| Vixie cron |
従来のcron、現在はcronieの基盤 |
歴史的な実装 |
| anacron |
システム停止中のタスクを起動時に実行 |
デスクトップLinux |
| fcron |
柔軟なスケジューリング機能 |
組み込み用途 |
現代のサーバー環境ではcronieが最も一般的に使用されています。
crontabの基本操作#
crontabは「cron table」の略で、cronジョブのスケジュールを定義するファイルです。ユーザーごとに個別のcrontabファイルを持つことができます。
crontabコマンド#
crontabの操作には以下のコマンドを使用します。
1
2
3
4
5
6
7
8
9
10
11
|
# 現在のcrontabを表示
crontab -l
# crontabを編集
crontab -e
# crontabを削除
crontab -r
# 他のユーザーのcrontabを編集(root権限が必要)
sudo crontab -u username -e
|
初めてcrontab -eを実行すると、使用するエディタを選択するプロンプトが表示されます。
1
2
3
4
5
6
7
8
9
10
|
$ crontab -e
no crontab for user - using an empty one
Select an editor. To change later, run 'select-editor'.
1. /bin/nano <---- easiest
2. /usr/bin/vim.basic
3. /usr/bin/vim.tiny
4. /bin/ed
Choose 1-4 [1]:
|
crontabファイルの場所#
crontabファイルは以下の場所に保存されます。
| ファイル |
説明 |
/var/spool/cron/crontabs/ユーザー名 |
ユーザー個別のcrontab(Ubuntu/Debian) |
/var/spool/cron/ユーザー名 |
ユーザー個別のcrontab(RHEL系) |
/etc/crontab |
システム全体のcrontab |
/etc/cron.d/ |
システムcrontabのディレクトリ |
ユーザーcrontabを直接編集することは推奨されません。必ずcrontab -eコマンドを使用してください。
cron式の構文と書き方#
cron式は5つの時間フィールドとコマンドで構成されます。これがcronスケジューリングの核心部分です。
cron式の基本構造#
┌───────────── 分 (0-59)
│ ┌───────────── 時 (0-23)
│ │ ┌───────────── 日 (1-31)
│ │ │ ┌───────────── 月 (1-12)
│ │ │ │ ┌───────────── 曜日 (0-7, 0と7は日曜日)
│ │ │ │ │
│ │ │ │ │
* * * * * コマンド
各フィールドの指定方法#
| 記号 |
意味 |
例 |
* |
すべての値 |
* * * * *(毎分) |
, |
複数の値を列挙 |
0,30 * * * *(0分と30分) |
- |
範囲指定 |
0 9-17 * * *(9時から17時) |
/ |
間隔指定 |
*/15 * * * *(15分ごと) |
月と曜日の名前指定#
数値の代わりに英語の省略形も使用できます。
1
2
3
4
5
|
# 月の指定
jan, feb, mar, apr, may, jun, jul, aug, sep, oct, nov, dec
# 曜日の指定
sun, mon, tue, wed, thu, fri, sat
|
cron式の実践例#
日常的によく使われるcron式のパターンを見ていきましょう。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
|
# 毎日午前3時に実行
0 3 * * * /path/to/backup.sh
# 毎時0分に実行
0 * * * * /path/to/hourly-task.sh
# 5分ごとに実行
*/5 * * * * /path/to/check-status.sh
# 平日の午前9時に実行
0 9 * * 1-5 /path/to/weekday-task.sh
# 毎月1日と15日の午前2時に実行
0 2 1,15 * * /path/to/bimonthly-task.sh
# 毎週日曜日の午前4時30分に実行
30 4 * * 0 /path/to/weekly-maintenance.sh
# 1月から6月の毎日午前6時に実行
0 6 * 1-6 * /path/to/first-half-year.sh
# 平日の営業時間(9時-18時)に30分ごとに実行
*/30 9-18 * * 1-5 /path/to/business-hours-check.sh
|
特殊な時間指定(ショートカット)#
cronieでは、よく使われるスケジュールにショートカットが用意されています。
| ショートカット |
等価なcron式 |
説明 |
@reboot |
- |
システム起動時 |
@yearly |
0 0 1 1 * |
年1回(1月1日0時) |
@annually |
0 0 1 1 * |
@yearlyと同じ |
@monthly |
0 0 1 * * |
月1回(1日0時) |
@weekly |
0 0 * * 0 |
週1回(日曜0時) |
@daily |
0 0 * * * |
日1回(0時) |
@hourly |
0 * * * * |
時1回(毎時0分) |
1
2
3
4
5
|
# システム起動時にスクリプトを実行
@reboot /path/to/startup-script.sh
# 毎日バックアップを実行
@daily /path/to/daily-backup.sh
|
crontabの実践的な設定例#
バックアップジョブの設定#
データベースのバックアップを毎日深夜に実行する例です。
1
2
3
4
5
6
7
8
9
10
|
# crontab -e で以下を追加
SHELL=/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=admin@example.com
# PostgreSQLデータベースのバックアップ(毎日午前2時)
0 2 * * * pg_dump -U postgres mydb | gzip > /backup/mydb_$(date +\%Y\%m\%d).sql.gz
# 7日以上前のバックアップを削除(毎日午前3時)
0 3 * * * find /backup -name "mydb_*.sql.gz" -mtime +7 -delete
|
crontabでは%が特殊文字として扱われるため、dateコマンドのフォーマット指定では\%とエスケープする必要があります。
環境変数の設定#
cron環境では通常のログインシェルとは異なる最小限の環境変数しか設定されていません。スクリプトが正しく動作するよう、必要な環境変数をcrontabで設定しましょう。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
# 環境変数の設定
SHELL=/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
HOME=/home/myuser
LANG=ja_JP.UTF-8
# メール送信先
MAILTO=admin@example.com
# MAILTOを空にするとメールを送信しない
# MAILTO=""
# cronジョブの定義
0 * * * * /home/myuser/scripts/hourly-check.sh
|
ログファイルへの出力#
cronジョブの実行結果をログファイルに記録する設定です。
1
2
3
4
5
6
7
8
|
# 標準出力と標準エラー出力の両方をログファイルに記録
0 * * * * /path/to/script.sh >> /var/log/myscript.log 2>&1
# 日付付きでログを記録
0 * * * * /path/to/script.sh >> /var/log/myscript_$(date +\%Y\%m\%d).log 2>&1
# 出力を完全に破棄(非推奨だが特定の用途で使用)
0 * * * * /path/to/script.sh > /dev/null 2>&1
|
システムcrontabの設定例#
/etc/crontabや/etc/cron.d/配下のファイルでは、コマンドの前に実行ユーザーを指定します。
1
2
3
4
5
6
7
8
|
# /etc/cron.d/my-system-job
SHELL=/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
# 分 時 日 月 曜日 ユーザー コマンド
0 4 * * * root /usr/local/bin/system-maintenance.sh
*/10 * * * * www-data /var/www/app/artisan schedule:run
|
cronのログ確認とトラブルシューティング#
cronログの確認#
cronの実行ログは、ディストリビューションによって保存場所が異なります。
1
2
3
4
5
6
7
8
9
|
# Ubuntu/Debian系
sudo grep CRON /var/log/syslog
# RHEL/AlmaLinux系
sudo cat /var/log/cron
# journalctlを使用(systemd環境)
journalctl -u cron
journalctl -u crond # RHEL系
|
cronが動作しない場合のチェックポイント#
cronジョブが期待通りに動作しない場合、以下の点を確認してください。
graph TD
A[cronジョブが動作しない] --> B{cronデーモンは起動中?}
B -->|いいえ| C[sudo systemctl start cron]
B -->|はい| D{crontab構文は正しい?}
D -->|いいえ| E[crontab -e で修正]
D -->|はい| F{実行権限はある?}
F -->|いいえ| G[chmod +x script.sh]
F -->|はい| H{PATHは正しい?}
H -->|いいえ| I[フルパスで指定]
H -->|はい| J{スクリプト自体は動作?}
J -->|いいえ| K[手動実行でデバッグ]
J -->|はい| L[環境変数を確認]確認コマンド
1
2
3
4
5
6
7
8
9
10
11
|
# cronデーモンの状態確認
sudo systemctl status cron # Ubuntu/Debian
sudo systemctl status crond # RHEL系
# crontab構文の検証
crontab -l | grep -v "^#" | while read line; do
echo "Checking: $line"
done
# cronが使用する環境変数の確認
* * * * * env > /tmp/cron-env.txt
|
よくあるトラブルと解決策#
| 症状 |
原因 |
解決策 |
| スクリプトが実行されない |
PATHが通っていない |
コマンドをフルパスで記述 |
| 文字化けが発生 |
LANGが設定されていない |
LANG=ja_JP.UTF-8を追加 |
| 出力がメールで届く |
リダイレクトが未設定 |
>> /path/to/log 2>&1を追加 |
| 権限エラー |
実行権限がない |
chmod +x script.sh |
%でエラー |
エスケープ忘れ |
\%に変更 |
systemdタイマーとは#
systemdタイマーは、systemdに統合されたタスクスケジューリング機能です。cronの代替として使用でき、systemdの豊富な機能(依存関係管理、リソース制御、ログ統合など)を活用できます。
systemdタイマーの構成要素#
systemdタイマーは2つのUnitファイルで構成されます。
graph LR
A[タイマーUnit<br/>foo.timer] -->|トリガー| B[サービスUnit<br/>foo.service]
B --> C[実行するコマンド]
D[systemd] --> A
D --> B
| ファイル |
役割 |
.timer |
いつ実行するかを定義 |
.service |
何を実行するかを定義 |
タイマーの種類#
systemdタイマーには2種類の時間指定方法があります。
| 種類 |
説明 |
オプション |
| リアルタイムタイマー |
カレンダー時刻で指定(cronと同様) |
OnCalendar= |
| モノトニックタイマー |
相対時間で指定 |
OnBootSec=, OnUnitActiveSec=など |
systemdタイマーの基本設定#
サービスUnitの作成#
まず、実行したいタスクを定義するサービスUnitを作成します。
1
|
sudo vim /etc/systemd/system/backup.service
|
1
2
3
4
5
6
7
8
9
10
11
12
13
|
[Unit]
Description=Daily Backup Service
After=network.target
[Service]
Type=oneshot
User=root
ExecStart=/usr/local/bin/backup.sh
StandardOutput=journal
StandardError=journal
[Install]
WantedBy=multi-user.target
|
Type=oneshotは、タスク完了後にサービスが終了することを示します。
タイマーUnitの作成#
次に、サービスをいつ実行するかを定義するタイマーUnitを作成します。
1
|
sudo vim /etc/systemd/system/backup.timer
|
1
2
3
4
5
6
7
8
9
10
|
[Unit]
Description=Daily Backup Timer
[Timer]
OnCalendar=*-*-* 02:00:00
Persistent=true
RandomizedDelaySec=300
[Install]
WantedBy=timers.target
|
タイマーの有効化と開始#
作成したタイマーを有効化し、開始します。
1
2
3
4
5
6
7
8
9
10
11
|
# systemd設定を再読み込み
sudo systemctl daemon-reload
# タイマーを有効化(自動起動)
sudo systemctl enable backup.timer
# タイマーを開始
sudo systemctl start backup.timer
# 状態を確認
sudo systemctl status backup.timer
|
OnCalendarの構文#
OnCalendarオプションは、cronに相当するカレンダーベースのスケジューリングを提供します。
基本フォーマット#
曜日 年-月-日 時:分:秒
例:
Mon 2025-01-08 14:30:00
ワイルドカードと範囲指定#
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
# 毎日午前2時
OnCalendar=*-*-* 02:00:00
# 毎週月曜日の午前9時
OnCalendar=Mon *-*-* 09:00:00
# 毎月1日の午前0時
OnCalendar=*-*-01 00:00:00
# 平日(月〜金)の午前9時
OnCalendar=Mon..Fri *-*-* 09:00:00
# 毎時30分
OnCalendar=*-*-* *:30:00
# 15分ごと
OnCalendar=*-*-* *:00,15,30,45:00
|
定義済みの時間表現#
systemdには便利なショートカットが用意されています。
| 表現 |
等価な指定 |
minutely |
*-*-* *:*:00 |
hourly |
*-*-* *:00:00 |
daily |
*-*-* 00:00:00 |
weekly |
Mon *-*-* 00:00:00 |
monthly |
*-*-01 00:00:00 |
yearly |
*-01-01 00:00:00 |
OnCalendarの検証#
systemd-analyze calendarコマンドで、OnCalendarの解釈と次回実行時刻を確認できます。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
# 指定した時間表現の解釈を確認
$ systemd-analyze calendar "Mon..Fri *-*-* 09:00:00"
Original form: Mon..Fri *-*-* 09:00:00
Normalized form: Mon..Fri *-*-* 09:00:00
Next elapse: Thu 2026-01-08 09:00:00 JST
(in UTC): Thu 2026-01-08 00:00:00 UTC
From now: 18h left
# 複数回の実行時刻を確認
$ systemd-analyze calendar --iterations=5 daily
Original form: daily
Normalized form: *-*-* 00:00:00
Next elapse: Thu 2026-01-09 00:00:00 JST
(in UTC): Wed 2026-01-08 15:00:00 UTC
From now: 9h 30min left
Iter. #2: Fri 2026-01-10 00:00:00 JST
Iter. #3: Sat 2026-01-11 00:00:00 JST
Iter. #4: Sun 2026-01-12 00:00:00 JST
Iter. #5: Mon 2026-01-13 00:00:00 JST
|
モノトニックタイマーの設定#
モノトニックタイマーは、特定のイベントからの経過時間でスケジューリングします。
よく使用されるオプション#
| オプション |
説明 |
OnBootSec= |
システム起動からの経過時間 |
OnStartupSec= |
systemd起動からの経過時間 |
OnActiveSec= |
タイマーがアクティブになってからの経過時間 |
OnUnitActiveSec= |
サービスが最後にアクティブになってからの経過時間 |
OnUnitInactiveSec= |
サービスが最後に非アクティブになってからの経過時間 |
例:起動15分後と、その後1時間ごとに実行#
1
2
3
4
5
6
7
8
9
10
|
[Unit]
Description=Periodic Health Check Timer
[Timer]
OnBootSec=15min
OnUnitActiveSec=1h
Unit=health-check.service
[Install]
WantedBy=timers.target
|
systemdタイマーの管理#
タイマーの一覧表示#
1
2
3
4
5
6
7
8
9
10
|
# 有効なタイマーの一覧
systemctl list-timers
# すべてのタイマー(無効なものを含む)
systemctl list-timers --all
# 出力例
NEXT LEFT LAST PASSED UNIT ACTIVATES
Thu 2026-01-09 00:00:00 JST 9h left Wed 2026-01-08 00:00:00 JST 14h ago logrotate.timer logrotate.service
Thu 2026-01-09 02:00:00 JST 11h left Wed 2026-01-08 02:00:00 JST 12h ago backup.timer backup.service
|
タイマーの状態確認#
1
2
3
4
5
|
# タイマーの詳細状態
sudo systemctl status backup.timer
# サービスの実行結果
sudo systemctl status backup.service
|
手動でサービスを実行#
タイマーを待たずにサービスをテスト実行できます。
1
|
sudo systemctl start backup.service
|
タイマーのログ確認#
journalctlを使ってタイマーとサービスのログを確認します。
1
2
3
4
5
6
7
8
9
10
11
|
# タイマーのログ
journalctl -u backup.timer
# サービスのログ
journalctl -u backup.service
# 最近のログのみ表示
journalctl -u backup.service --since "1 hour ago"
# リアルタイムでログを監視
journalctl -u backup.service -f
|
systemdタイマーの実践例#
毎日のデータベースバックアップ#
サービスUnit(/etc/systemd/system/db-backup.service)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
[Unit]
Description=PostgreSQL Database Backup
Wants=postgresql.service
After=postgresql.service
[Service]
Type=oneshot
User=postgres
Environment=PGPASSWORD=secretpassword
ExecStart=/bin/bash -c '/usr/bin/pg_dump mydb | gzip > /backup/mydb_$(date +%%Y%%m%%d_%%H%%M%%S).sql.gz'
StandardOutput=journal
StandardError=journal
[Install]
WantedBy=multi-user.target
|
タイマーUnit(/etc/systemd/system/db-backup.timer)
1
2
3
4
5
6
7
8
9
10
|
[Unit]
Description=Daily Database Backup Timer
[Timer]
OnCalendar=*-*-* 03:00:00
Persistent=true
RandomizedDelaySec=600
[Install]
WantedBy=timers.target
|
Persistent=trueを設定すると、システム停止中にスキップされた実行が起動時に行われます。
古いログファイルの削除#
サービスUnit(/etc/systemd/system/cleanup-logs.service)
1
2
3
4
5
6
7
|
[Unit]
Description=Cleanup Old Log Files
[Service]
Type=oneshot
ExecStart=/usr/bin/find /var/log/myapp -name "*.log" -mtime +30 -delete
ExecStart=/usr/bin/find /backup -name "*.sql.gz" -mtime +7 -delete
|
タイマーUnit(/etc/systemd/system/cleanup-logs.timer)
1
2
3
4
5
6
7
8
9
|
[Unit]
Description=Weekly Log Cleanup Timer
[Timer]
OnCalendar=Sun *-*-* 04:00:00
Persistent=true
[Install]
WantedBy=timers.target
|
ヘルスチェックの定期実行#
サービスUnit(/etc/systemd/system/health-check.service)
1
2
3
4
5
6
7
|
[Unit]
Description=Application Health Check
[Service]
Type=oneshot
ExecStart=/usr/local/bin/health-check.sh
ExecStartPost=/bin/bash -c 'if [ $EXIT_STATUS -ne 0 ]; then /usr/local/bin/notify-error.sh; fi'
|
タイマーUnit(/etc/systemd/system/health-check.timer)
1
2
3
4
5
6
7
8
9
|
[Unit]
Description=Health Check Timer (Every 5 Minutes)
[Timer]
OnCalendar=*-*-* *:00/5:00
AccuracySec=1s
[Install]
WantedBy=timers.target
|
AccuracySec=1sで実行タイミングの精度を高めています。デフォルトは1分の誤差が許容されます。
エラー通知の設定#
cronでのエラー通知#
cronではMAILTO環境変数でメール通知先を設定します。
1
2
3
4
5
|
MAILTO=admin@example.com
0 2 * * * /path/to/backup.sh
# 失敗時のみ通知したい場合は出力を制御
0 2 * * * /path/to/backup.sh > /dev/null || echo "Backup failed" | mail -s "Backup Error" admin@example.com
|
Slackへの通知スクリプト例
1
2
3
4
5
6
7
8
9
|
#!/bin/bash
# /usr/local/bin/notify-slack.sh
WEBHOOK_URL="https://hooks.slack.com/services/YOUR/WEBHOOK/URL"
MESSAGE="$1"
curl -X POST -H 'Content-type: application/json' \
--data "{\"text\":\"${MESSAGE}\"}" \
"$WEBHOOK_URL"
|
1
2
|
# crontabでの使用
0 2 * * * /path/to/backup.sh || /usr/local/bin/notify-slack.sh "Backup failed on $(hostname)"
|
systemdでのエラー通知#
systemdではOnFailureディレクティブを使用してエラー通知サービスを呼び出せます。
通知サービス(/etc/systemd/system/notify-failure@.service)
1
2
3
4
5
6
|
[Unit]
Description=Send Failure Notification for %i
[Service]
Type=oneshot
ExecStart=/usr/local/bin/notify-failure.sh %i
|
通知スクリプト(/usr/local/bin/notify-failure.sh)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
#!/bin/bash
UNIT_NAME="$1"
HOSTNAME=$(hostname)
TIMESTAMP=$(date '+%Y-%m-%d %H:%M:%S')
# メール送信
echo "Service ${UNIT_NAME} failed on ${HOSTNAME} at ${TIMESTAMP}" | \
mail -s "[ALERT] ${UNIT_NAME} failed" admin@example.com
# Slack通知(オプション)
curl -X POST -H 'Content-type: application/json' \
--data "{\"text\":\"[ALERT] ${UNIT_NAME} failed on ${HOSTNAME} at ${TIMESTAMP}\"}" \
"https://hooks.slack.com/services/YOUR/WEBHOOK/URL"
|
バックアップサービスにOnFailureを追加
1
2
3
4
5
6
7
|
[Unit]
Description=PostgreSQL Database Backup
OnFailure=notify-failure@%n.service
[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh
|
cronとsystemdタイマーの比較#
どちらを使うべきか迷った場合の判断基準をまとめます。
| 観点 |
cron |
systemdタイマー |
| 設定の簡単さ |
1行で記述可能 |
2ファイル必要 |
| ログ管理 |
分散(syslog/メール) |
journaldに統合 |
| 依存関係 |
対応なし |
柔軟に設定可能 |
| リソース制御 |
対応なし |
cgroup連携 |
| 失敗時の処理 |
メール通知のみ |
OnFailure指定 |
| デバッグ |
やや困難 |
systemctl/journalctlで容易 |
| 学習コスト |
低い |
やや高い |
| 可搬性 |
高い |
systemd環境限定 |
使い分けの指針#
cronが適している場面
- シンプルな定期実行タスク
- 非systemd環境(コンテナなど)
- 既存のcron設定を維持したい場合
- 短い1行のコマンド実行
systemdタイマーが適している場面
- サービス間の依存関係がある場合
- 詳細なログ管理が必要な場合
- リソース制限を設定したい場合
- 失敗時の自動リカバリやエスカレーションが必要な場合
- systemd環境で運用を統一したい場合
一時的なタイマーの作成(systemd-run)#
systemd-runコマンドを使用すると、Unitファイルを作成せずに一時的なタイマーを設定できます。
1
2
3
4
5
6
7
8
9
10
11
|
# 30秒後に1回だけ実行
sudo systemd-run --on-active=30 /bin/touch /tmp/test-file
# 1時間後に実行
sudo systemd-run --on-active="1h" /usr/local/bin/task.sh
# 特定の時刻に実行
sudo systemd-run --on-calendar="2026-01-09 10:00:00" /usr/local/bin/task.sh
# 既存のサービスを1時間後に実行
sudo systemd-run --on-active="1h" --unit=backup.service
|
テストや一時的なタスクの実行に便利です。
まとめ#
本記事では、Linuxにおけるタスクスケジューリングの2つの主要な方法であるcronとsystemdタイマーについて解説しました。
cronは長い歴史を持ち、シンプルな構文で素早く定期実行を設定できます。一方、systemdタイマーはsystemdエコシステムと統合され、依存関係管理やログの一元化など、より高度な機能を提供します。
定期実行タスクを設定する際は、以下のポイントを意識してください。
- タスクの複雑さに応じてcronとsystemdタイマーを使い分ける
- 環境変数やPATHの設定を忘れずに行う
- ログ出力を適切に設定し、実行結果を追跡可能にする
- エラー通知を設定して問題を早期に検知する
- 本番適用前にテスト環境で動作を確認する
cronの5フィールド形式やsystemdのOnCalendar構文を理解し、定期実行タスクの自動化を実現しましょう。
参考リンク#