クイックスタート（5分）
標準的な cron はシステム管理者の定番ですが、2つの特定のシナリオ（単発のタスクと、24時間365日オンラインではないシステム）ではうまくいきません。cronジョブがスケジュールされている時にマシンが停止していると、そのタスクは単に消滅してしまいます。at と anacron はこれらのギャップを完璧に埋めてくれます。
まず、システムに at がインストールされていることを確認してください。UbuntuまたはDebianでは、以下を実行します：
sudo apt update && sudo apt install at
sudo systemctl enable --now atd今夜午前2時にバックアップを実行したいですか？複雑なcrontabファイルと格闘する代わりに、コマンドを直接 at にパイプするだけです：
echo "/home/user/scripts/backup.sh" | at 02:00Anacronは定期的なタスクを異なる方法で処理します。時刻ではなく間隔を追跡します。週次のクリーンアップがスケジュールされている時にノートパソコンが閉じられていても、蓋を開けてから15分後にanacronがそれを実行します。cat /etc/anacrontab を実行して設定を確認できます。
Linuxタスクスケジューリングの詳細
atコマンドの正確性
私は「投げっぱなし（fire and forget）」のタスクに at を頻繁に使用します。15分間のメンテナンス時間中にサーバーを再起動したり、データ移行後に50GBの一時ディレクトリを削除したりするのに最適です。構文は非常に汎用的です。絶対時間（at 14:30）、相対オフセット（at now + 2 hours）、または特定の日付（at 10:00 AM July 25）を指定できます。
送信されたすべてのジョブには一意のIDが割り当てられます。保留中のタスクを表示するには atq を、キャンセルするには atrm を使用してこれらを管理します。1つ重要な教訓として、at は送信した瞬間の現在の環境変数をスナップショットとして保存します。それでも、パス関連の失敗を防ぐために、スクリプトやバイナリには常に絶対パスを使用してください。
anacronによる「オフタイム」問題の解決
Anacronはワークステーションやローカルの開発環境に不可欠です。クラウドのVPSは300日間連続稼働するかもしれませんが、ノートパソコンはおそらく毎晩スリープします。Anacronは /var/spool/anacron のタイムスタンプを追跡することで、深夜のメンテナンスジョブが実際に実行されることを保証します。
/etc/anacrontab の構造は以下のようになっています：
# 期間（日単位） | 遅延（分単位） | ジョブ識別子 | コマンド
1 5 daily-backup /usr/local/bin/backup.sh
7 15 weekly-cleanup /usr/local/bin/cleanup.shこの設定では、日次バックアップが24時間ごとに1回実行されます。システムがオフだった場合、anacronは起動後5分待ってからスクリプトを開始します。このように開始をずらすことで、ログインした瞬間に大量のメンテナンスタスクがCPUを圧迫するのを防ぎます。
4GB RAMのUbuntuサーバーを使用した最近のプロジェクトでは、いくつかの重いデータ処理タスクを午前3時にスケジュールされた at ジョブに移動しました。これにより、営業時間中のピーク時のCPU負荷が90%から20%未満に減少しました。ユーザーにとってシステムは快適なまま、一時的なニーズのために永続的なcrontabを管理する必要もありませんでした。
高度な使い方とテクニック
batchコマンドの活用
batch コマンドは、at パッケージに含まれる強力で見落とされがちなツールです。at と全く同じように機能しますが、「知能」を備えています。システムのロードアベレージが1.5を下回った時にのみ実行されます。これは、現在の作業に影響を与えることなく、ビデオのエンコードや大規模なカーネルのコンパイルなどの重い処理を行うのに最適です。
batch <<EOF
/usr/bin/process-heavy-data.sh
EOFアクセス制限
マルチユーザー環境ではセキュリティが重要です。Linuxは /etc/at.allow と /etc/at.deny を使用してアクセスを制限します。at.allow が存在する場合、そこにリストされているユーザーのみがジョブをスケジュールできます。本番サーバーでは、ジュニア開発者が再帰スクリプトで誤ってシステムリソースを使い果たすのを防ぐために、ホワイトリスト方式をお勧めします。
出力とエラーの処理
デフォルトでは、at は標準出力（stdout）と標準エラー（stderr）をローカルユーザーアカウントにメールで送信しようとします。ローカルシステムメールはめったにチェックされないため、トラブルシューティングを簡単にするために、常に出力を専用のログファイルにリダイレクトしています：
echo "/path/to/script.sh >> /var/log/myscript.log 2>&1" | at now + 1 hour信頼性の高いスケジューリングのための実用的なヒント
- 絶対パスは必須： 単に
python script.pyと実行しないでください。/usr/bin/python3 /home/user/scripts/script.pyを使用しましょう。これにより、スケジューリング失敗の90%を防げます。 - 自動化する前に手動でテストする： まず標準のシェルでスクリプトを実行してください。対話的な入力（パスワードプロンプトなど）が必要な場合、バックグラウンドで黙って失敗します。
- ログがすべてを語る： 定期的なタスクが消えてしまった場合は、
journalctl -u anacronを確認してください。sudo anacron -fですべてのジョブを強制的にテスト実行することもできます。 - ジョブIDを把握する： 複数の
atタスクをスケジュールする場合は、IDを控えておきましょう。スクリプトにバグがあることに気づいた際、慌てるよりもatrm 42と打つ方がずっと早いです。 - システムクロックを同期する：
atの正確さは時計の正確さに依存します。午前3時のメンテナンスが午前9時のピーク時に誤って実行されないよう、NTPが有効であることを確認してください。
at と anacron をマスターすることで、標準の cron には欠けている柔軟性が得られます。ローカルのワークステーションを管理している場合でも、高トラフィックのサーバーを管理している場合でも、これらのツールを使用すれば、たとえ停電があったとしてもタスクを正確なタイミングで実行できます。
