メニュー
Linux cron vs systemd timer 比較｜定期タスク管理の最適解
自作.com編集部·
自作.com編集部
PCパーツ・ガジェット専門
自作PCパーツやガジェットの最新情報を発信中。実測データに基づいた公平なランキングをお届けします。
公開: 2026/4/15
更新: 2026/4/14
PCパーツ・ガジェット専門
自作PCパーツやガジェットの最新情報を発信中。実測データに基づいた公平なランキングをお届けします。
Linux のサーバー環境やデスクトップ PC を運用する際、特定の時刻に自動で処理を実行させる「定期タスク」は不可欠な機能です。バックアップの実行、ログのローテーション、キャッシュの削除、システム情報の更新など、多くの管理作業を自動化することで、管理者の手間を大幅に削減し、システムの安定性を担保できます。しかし、Linux におけるこの定期タスク管理には、長年親しまれてきた「cron」と、次世代 Linux システム管理の標準となった「systemd timer」の 2 つ主要な選択肢が存在します。
両者は互いに競合関係にあるわけではなく、それぞれが異なるアーキテクチャと強みを持っています。特に 2025 年以降、システムログや依存関係管理において systemd を中心とした設計思想が主流となる中、cron の位置づけはどのように変わるのか、あるいは systemd timer の導入が推奨されるのかを判断する必要があります。本記事では、Ubuntu 24.04 LTS（systemd 255）や Fedora 41（systemd 256）などの最新環境を想定し、 cron と systemd timer の詳細な比較解説を行います。各方式の設定方法からメリット・デメリット、そして具体的なユースケース別の使い分けまでを網羅的にガイドします。
Linux オペレーティングシステムにおける定期タスク管理は、システムのライフサイクルを支える重要なインフラストラクチャの一部です。最も古くから存在し、広く普及している方式が「cron」です。これは、UNIX から継承されたプロセススケジューラであり、ユーザーレベルおよびシステムレベルで特定の時刻にコマンドを実行する仕組みを提供します。その設計思想はシンプルで、テキストベースの設定ファイルを解析してタスクをキューに登録するというものです。1970 年代から存在する歴史的経緯を持つため、多くのスクリプトや既存のシステムツールが cron の構文に依存しています。
対照的に、「systemd timer」は systemd システム管理デモンを中心とした、より現代的なアプローチです。systemd は Linux カーネル上の起動プロセスを管理する唯一の初期化システムとして普及しており、その一環として提供されるのが systemd timer です。これは従来の cron と同等の機能を持ちつつも、systemd のログ管理（journal）や依存関係制御、セクション単位での整合性など、モダンな OS 機能を活用して設計されています。2025 年時点では、多くのディストリビューションで systemd が標準となり、そのバージョンアップに伴い timer ユニットファイルの機能も強化され続けています。
両者の本質的な違いは、「独立したデモンとして動作する cron」と「systemd の一部として統合された timer」にあります。cron は独自のプロセス（crond）を常駐させ、設定ファイルを定期的にポーリングしてタスクを実行します。一方、systemd timer は systemd マネージャーに組み込まれており、他のユニット（service, socket など）とシームレスに連携することができます。この違いは、システムの起動順やシャットダウン時の処理、そしてログの一元管理において大きな影響を及ぼします。最新の Linux 環境では、これらのアーキテクチャの違いを理解した上で、運用目的に合わせて最適な手段を選択することが求められます。
以下に、両者の基本的な特性を整理しました。
cron:
systemd timer:
このように、cron はそのシンプルさと歴史的背景により依然として広く使われていますが、systemd timer は次世代のシステム管理において、より高度な機能を提供しています。2026 年に向けた長期的な運用を考慮するならば、systemd の仕様変更やサポート期間も踏まえた判断が必要です。
cron を使用して定期タスクを設定する際、最も基本的かつ重要な要素が「crontab ファイルの記述ルール」です。これは 5 つのフィールド形式によって時刻を指定し、実行するコマンドを記述します。各フィールドはそれぞれ時、分、日付、月、曜日を表しており、これらを組み合わせることで複雑なスケジュールも表現可能です。設定コマンドとして crontab -e を使用すると、現在のユーザーの crontab ファイルをエディタで開くことができます。システム全体で使用したい場合は、/etc/crontab や /etc/cron.d/ ディレクトリ内のファイルを編集する必要があります。
基本的な構文は以下の 6 つの要素で構成されます。最初の 5 つが時刻指定のフィールドであり、最後の要素が実行するコマンドです。各フィールドには文字列や数値だけでなく、ワイルドカードやリスト指定も可能です。例えば、* * * * * は毎分実行を意味し、これはシステム監視スクリプトなどで頻繁に使用されます。また、数字の範囲指定（1-5）やステップ値（*/10）の使用も可能で、これにより柔軟なスケジュール設定が行えます。
cron のフィールドは以下の通り定義されており、それぞれの制約を理解しておくことが誤作動防止につながります。
これらのフィールドを組み合わせる際に、よくあるミスとして「曜日の指定が異なる」ことが挙げられます。例えば、Linux の標準的な cron では曜日が 0-6 の範囲で定義されることが一般的ですが、一部の GNU crontab 実装では 0 と 7 が両方とも日曜日として扱われます。また、/etc/crontab を編集する際は、ユーザー名フィールドが追加される点に注意が必要です。これは、誰の権限でタスクを実行するかを指定するためのものであり、root ユーザーで実行したい場合はここに root と記述します。
具体的な設定例として、毎日午前 2 時にバックアップスクリプト /home/admin/backup.sh を実行する場合の設定は以下のようになります。
0 2 * * * root /home/admin/backup.sh >> /var/log/backup.log 2>&1
この行の意味を分解すると、「分：0 時、時：2 時、日：毎月、月：毎日、曜：毎日」となり、結果として「毎日午前 2 時に実行」となります。また、標準出力と標準エラー出力をログファイルにリダイレクトする部分も重要です。>> /var/log/backup.log は結果をログに残し、2>&1 はエラー情報も含めて同じファイルに記録します。これにより、タスクの成否を後から確認することが可能になります。
Ubuntu 24.04 LTS や Debian 12 のような現行ディストリビューションでは、cron デーモンは通常 cronie パッケージとして提供されます。Fedora 41 では systemd との統合が強化されているため、単純な cron スクリプトでも systemd timer を経由して実行するパターンが増えています。ただし、既存のレガシーシステムや、特定のサードパーティ製ソフトウェアが依存している設定を変更しないためには、cron の構文を正しく理解し続ける必要があります。
cron を実務レベルで安定して運用するためには、基本的な時刻指定を超えた高度なテクニックを理解する必要があります。特に、スクリプトの実行時間が長時間に及ぶ場合や、重複実行によってリソースが枯渇するリスクを回避するための機構が必要です。最も一般的な手法は「ロックファイル」の活用です。flock コマンドを使用することで、あるプロセスが既に実行中であることを検知し、次の実行を待機させたりスキップしたりすることができます。これにより、バックアップ処理中に再度トリガーされることを防ぎます。
具体的には、cron のコマンド部分に flock を追加して記述します。例えば、スクリプトの実行開始時にロックを取得し、完了するまで他の実行をブロックする設定は以下のようになります。
0 2 * * * root flock -n /var/lock/db_backup.lock /home/admin/db_backup.sh-n オプションは非ブロックモードを指定します。ロックが存在する場合、即座に失敗（スクリプト実行なし）として終了します。このテクニックは、システムが長時間停止している場合や、ネットワーク遅延により処理が異常に長引いた場合に有効です。また、cron の設定ファイルには環境変数も定義可能です。PATH 変数を適切に指定することで、スクリプト内で呼び出すコマンドのパスを解決しやすくします。デフォルトでは PATH=/usr/bin:/bin が設定されていますが、専門的なツールを使用する場合はこれを拡張することが推奨されます。
cron には他にも高度な機能として特殊記述子（@reboot, @daily など）があります。これらは標準的な 5 フィールド形式の短縮版であり、頻出するスケジュールを簡潔に記述できます。
システム起動時にのみ実行するスクリプト（例えば、ネットワーク設定の初期化）が必要な場合、@reboot を使用すると非常に便利です。ただし、この機能は /etc/crontab ではなくユーザーごとの crontab でよく使われます。また、メール通知機能も重要な要素です。[email protected] と記述することで、タスクの実行結果（標準出力）を指定されたメールアドレスに送信できます。
しかしながら、cron の運用にはいくつかの制限事項や注意点もあります。まず、システムがシャットダウンされている期間中に設定された時刻のタスクは実行されません。これは「anacron」によって補完される機能ですが、通常のスクリプトでは遅延処理が行われません。このため、サーバーが週次メンテナンスで数日間停止している場合、バックアップなどが欠落するリスクがあります。また、cron は基本的にユーザー権限で動作するため、root 権限が必要なタスクを設定するには /etc/crontab や sudo の設定を適切に行う必要があります。
さらに、ログ出力はデフォルトでは syslog に集約されますが、これは分散管理されるため、特定の cron スクリプトの履歴だけを追跡するのは困難です。また、cron デーモン自体が停止した場合や、crontab ファイルのパーミッションが誤って変更された場合にタスクが実行されなくなるトラブルも発生し得ます。これらのリスクを最小限に抑えるためには、定期的な設定の確認とログ監視の設定が不可欠です。
systemd timer は、cron と同様の目的を持ちつつも、その実装方式において根本的な違いがあります。これは systemd マネージャーの一部として動作し、他のシステムサービス（service）やソケットと密接に連携する設計となっています。systemd timer を設定するには、主に 2 つのファイルを作成する必要があります。「.timer」ファイルが時刻指定を担当し、「.service」ファイルが実際のタスク実行を担当します。この分離構造により、スケジュール管理と処理ロジックを明確に分けることができ、保守性が向上します。
まず、timer ユニットファイルの作成から始めます。通常、/etc/systemd/system/ ディレクトリに配置し、拡張子を .timer とします。ここで重要なのは OnCalendar 設定です。これは cron の 5 フィールド形式よりも柔軟で、人間が読みやすい自然言語に近い記述が可能です。例えば、「毎週月曜日の午前 10 時」を指定する際、cron では 0 10 * * 1 と数字だけで指定しますが、systemd timer では OnCalendar=Mon 10:00 と表記できます。これにより、設定ファイルの可読性が劇的に向上します。
具体的な systemd timer ユニットファイルの例を以下に示します。この設定では、毎朝 8 時に実行されるスクリプトを定義しています。
[Unit]
Description=My Daily Backup Timer
After=network-online.target
[Timer]
OnCalendar=*-*-* 08:00:00
Persistent=true
RandomizedDelaySec=60s
[Install]
WantedBy=timers.target
このファイルのポイントとして、After=network-online.target が挙げられます。これは、タスク実行前にネットワークが確実に確立されていることを保証する依存関係です。systemd timer は他のユニットとの順序制御が可能であり、バックアップのようなネットワーク依存タスクでは非常に有用です。また、OnCalendar にはワイルドカードも使用でき、*-*-* 08:00:00 は毎日 8 時を意味します。
次に、実際にスクリプトを実行する .service ユニットファイルを作成します。これは /etc/systemd/system/ ディレクトリに配置し、拡張子を .service とします。timer ユニットは Unit= セクションでこの service ファイルへのリンクを指定します。
[Unit]
Description=My Daily Backup Service
After=network-online.target
[Service]
Type=oneshot
ExecStart=/home/admin/backup_script.sh
User=admin
StandardOutput=journal
StandardError=journal
Type=oneshot は、タスクが終了したら systemd がそのプロセスを待機しなくてよいことを示します。これは通常のスクリプト実行に適しています。また、StandardOutput と StandardError を journal に設定することで、出力ログを systemd のジャーナルに記録させることができます。
このように、systemd timer は cron とは異なり、単なる時刻指定だけでなく、システムの状態や依存関係を考慮してタスクを実行できる点が特徴です。Ubuntu 24.04 LTS（systemd 255）および Fedora 41（systemd 256）では、これらの機能がさらに強化されており、ネットワーク起動時の同期処理などもより細かく制御できるようになっています。
設定ファイルの作成後は、systemctl daemon-reload を実行して変更を反映させます。その後、systemctl enable <timer_name>.timer で有効化し、systemctl start <timer_name>.timer でテスト実行可能です。このように systemd timer は、モダンな Linux システムにおける標準的な定期タスク管理手法として確立されています。
systemd timer には、cron では対応が困難な高度な機能が多数実装されています。特に、時刻のズレ補正や実行間隔のランダム化といった機能は、サーバーの負荷分散やシステムログの平準化に寄与します。これらは Linux システムを運用する上で、単なる自動化を超えて「安定性」を高める要素となります。
まず、「OnBootSec」機能について解説します。これはシステム起動から指定した時間の後にタスクを実行する設定です。例えば、OnBootSec=10min と記述すると、サーバーの再起動後 10 分経過した時点でタスクがトリガーされます。これは、システム起動時にネットワークサービスやファイルシステムが完全にマウントされるのを待ってからバックアップを開始したい場合などに有用です。cron ではこれを実現するには複雑なスクリプトロジックが必要ですが、systemd timer では設定だけで完結します。
次に、「RandomizedDelaySec」機能は、同じ時刻に多数のサーバーでタスクを実行する際に、負荷集中を防ぐために設計されています。RandomizedDelaySec=1h と指定すると、実際の実行時間は指定された時刻から ±1 時間の範囲内でランダムになります。これにより、例えば世界中に分散配置されたサーバーがすべて同一時刻にバックアップを開始することでネットワーク輻輳を引き起こすリスクを低減できます。2025 年以降のクラウド環境や大規模インフラ運用では、この機能は標準的なベストプラクティスとして推奨されています。
また、「Persistent=true」という設定も重要です。これは、設定された時刻にシステムがシャットダウン状態であった場合でも、システム起動後に遅延実行を行うことを保証します。cron はシステム停止中に落ちたタスクを逃しますが、systemd timer を使用すれば後から必ず実行されます。特に、メンテナンスウィンドウでサーバーを再起動する場合などに、この機能は重要な役割を果たします。
さらに、依存管理の観点では「WantedBy」や"After」を使用することで、他の systemd サービスとの順序制御が可能となります。例えば、データベースサービスが起動するまでバックアップを実行しないように設定できます。これは cron のスクリプト内で sleep 系のコマンドで擬似的に実現することも可能ですが、systemd 固有の依存管理はより堅牢です。
以下に、systemd timer の高度機能に関する主なパラメータを整理しました。
これらの機能を組み合わせることで、cron では不可能な複雑なスケジューリングも実現可能です。例えば、「システム起動後 30 分以内に実行し、かつランダムに最大 15 分遅延させる」ような条件は、OnBootSec=30min と RandomizedDelaySec=15min を併用することで容易に記述できます。
また、2026 年に向けたシステム設計においては、これらの機能を活用して「自己修復型」の定期タスクを構築することが可能です。例えば、バックアップが失敗した場合、systemd のリトライ機能と組み合わせることで、自動的に再試行を行う設定も可能です。これにより、人的介入なしでシステムの健全性を維持するインフラ基盤の構築が可能となります。
cron と systemd timer を使い分ける際、重要な判断基準の一つが「ログ管理の仕組み」です。システム全体の監視や障害対応において、ログがどのように記録され、どこから取得できるかは、管理者の作業効率に直結します。cron は伝統的に syslog デーモン（rsyslog や syslog-ng）経由でログを出力し、システム全体のパラメータ設定ファイル /etc/rsyslog.conf などで管理されます。一方、systemd timer は systemd-journald を介してログを記録し、コマンドラインツール journalctl で一元管理します。
cron のログは通常 /var/log/syslog や /var/log/cron に記録されます。しかし、これは syslog デーモンに依存するため、設定ファイルの編集や権限の設定が誤っているとログが出力されない可能性があります。また、ユーザーごとの cron ログは個別に管理される場合があり、特定のタスクの履歴を特定しにくいという側面があります。トラブルシューティングの際には、まず grep コマンドで該当ログを検索することから始めます。
sudo grep CRON /var/log/syslog
このコマンドにより、cron デーモンの実行記録を確認できます。しかし、systemd timer の場合は journalctl を使用することで、より詳細かつ構造化された情報を取得できます。例えば、特定の timer ユニットのログをフィルタリングするには以下のようにします。
sudo journalctl -u mytimer.timersudo journalctl -u mytask.servicesudo journalctl -f -u mytimer.timersystemd timer のログ管理は、journalctl を介して日時や優先度（info, warning, error）ごとに整理されるため、エラー発生時の原因特定が容易です。特に systemd 255 や 256 では、ログの構造化データ（JSON など）の出力もサポートされており、外部の監視ツールとの連携がスムーズです。
トラブルシューティングの手順として、以下のステップを推奨します。
systemctl status <timer>.timer で現在のステータスを確認systemctl timer-list または journalctl -u <timer> で実行時刻を確認journalctl -u <service> --since "1 hour ago" で直近の失敗ログを検索これにより、cron の場合よりも早く問題点に切り込めます。また、systemd timer は OnCalendar の構文エラーがあった場合、起動時に警告を出力するため、設定ミスにも早期に対応可能です。
ただし、ログの保存期間については systemd-journald の設定ファイル /etc/systemd/journald.conf で管理されます。ディスク容量が枯渇しないよう、適切なローテーション設定が必要です。一方、cron のログは syslog の設定で管理されるため、両者のバランスを考慮した設定が求められます。2025 年以降の運用では、これらログの可視化を自動化し、異常検知に繋げるシステム構築も一般的となっています。
「anacron」は、cron の欠点を補完するために設計されたツールです。特に、PC やノートパソコンのように常時稼働していない環境や、メンテナンスでシャットダウンされる期間があるサーバーにおいて重要です。cron はシステム停止中に落ちたタスクを逃しますが、anacron はそれを記憶し、次回の起動時に実行します。この機能は、デスクトップ Linux のユーザーや、頻繁に再起動するテスト環境では必須の機能と言えます。
anacron を使用すると、ファイル /etc/anacrontab に設定を行います。これは cron の構文と似ていますが、日付フィールドに @daily, @weekly, @monthly などの記述が標準的に対応しています。また、ランダム遅延（RANDOM_DELAY）のデフォルト値も設定されており、多数の anacron タスクが同時に起動するのを防ぎます。
cron から systemd timer への移行は、レガシーなシステムを現代的な環境へアップデートする際に頻繁に発生します。この移行においては、単なる構文変更だけでなく、ログ管理や権限設定の変更も伴います。以下の移行ガイドを参考にしてください。
crontab -l で確認OnCalendar 形式に変換移行プロセスでは、並行して両方のシステムを動作させる期間を設け、ログの整合性を確認することが重要です。特に、/var/spool/cron ディレクトリ内の設定は、systemd timer のユニットファイル作成後に削除または非有効化します。これにより、二重実行や競合状態を防げます。
ただし、anacron の移行においては注意が必要です。anacron は特定のユーザー（通常 root）のみで動作し、システム起動時に処理を実行する設計です。systemd timer を使用すれば、この機能は Persistent=true と同等の効果が得られるため、anacron 自体の使用を減らすことも可能です。しかし、既存の anacron スクリプトが複雑なロジックを持っている場合は、一旦 systemd 側で再実装を検討します。
2026 年時点での Linux インフラでは、anacron を使わずに systemd timer の機能だけでカバーすることが推奨される傾向にあります。これにより、管理コストを削減し、システム全体の整合性を高めることができます。特に Ubuntu 24.04 LTS や Fedora 41 では、systemd のロジックが強化されているため、移行後のパフォーマンスも期待できます。
ここで、cron と systemd timer を包括的に比較する表を提示します。この比較は、システム管理者や開発者が自社の環境に最適なツールを選択するための基準となります。機能の多さだけでなく、学習コストや運用負荷といった観点からも評価を行います。
| 項目 | cron | systemd timer |
|---|---|---|
| 設定ファイル形式 | テキスト（5 フィールド） | INI ベースのユニットファイル |
| 学習コスト | 低（シンプル） | 中（systemd の理解が必要） |
| 時刻指定表現 | 数値ベース（* * * * *） | 自然言語ベース（OnCalendar） |
| システム依存性 | なし（独立型） | systemd に依存する |
| デフォルト設定 | /etc/crontab, crontab -e | /etc/systemd/system/*.timer |
この表から、cron はシンプルで直感的である一方、systemd timer は設定項目が豊富で構造的であると読み取れます。初心者には cron が扱いやすいですが、中級者以上は systemd timer の柔軟性を活用できます。
| 項目 | cron | systemd timer |
|---|---|---|
| ログ管理 | syslog / メール | journalctl（構造化） |
| 依存管理 | なし | strong/weak 依存可能 |
| シャットダウン補完 | anacron が必須 | Persistent=true で対応 |
| 実行遅延制御 | スクリプト内実装必要 | RandomizedDelaySec |
| 起動時タスク | @reboot 記述可能 | OnBootSec / OnCalendar |
この比較表は、運用上の違いを明確に示しています。特にログ管理の統一性や、シャットダウン補完機能の有無は、システム安定性を担保する上で重要な判断材料です。
| 項目 | cron | systemd timer |
|---|---|---|
| ユーザー指定 | 設定ファイル内記述可能 | User=ディレクティブで指定 |
| 環境変数 | ファイル内で定義可能 | Environment=/EnvironmentFile |
| 権限昇格 | sudo 利用が必要 | Type=su や ExecStart で制御 |
systemd timer は、環境変数の管理やユーザー権限の指定においてより細かく制御が可能です。これにより、セキュリティポリシーに準拠したタスク実行が容易になります。
| 項目 | cron | systemd timer |
|---|---|---|
| レガシー対応 | 非常に高い（UNIX 以来） | 標準的（systemd ベース） |
| 将来性 | 維持されるが新機能は少ない | 次世代 Linux の標準 |
| バージョン依存 | 低い（POSIX準拠） | systemd バージョンに依存 |
2025 年以降の Linux ディストリビューションでは、systemd timer がデフォルト推奨となるケースが増えています。特に、新しいディストリビューションでの新規プロジェクトでは systemd timer の採用が有利です。
2026 年に向けて Linux システムを運用する際、cron と systemd timer をどう使い分けるべきかという問いは、環境の特性によって答えが変わります。ここでは、具体的なユースケース別に最適な選択を提案します。単にどちらが優れているかではなく、「どの状況でどちらを使うのが最も効率的か」を考えることが重要です。
まず、**「シンプルで即座に動かしたい場合」**には cron が推奨されます。特に、システム起動時の初期設定や、ネットワーク依存の少ないスクリプトを実行する場合です。また、既存のレガシーシステムを維持・保守する際にも、cron の変更リスクは低く抑えられます。例えば、特定のサードパーティ製バックアップツールが cron でのみ動作するように設計されている場合、無理に systemd timer に移行する必要はありません。
次に、**「システム全体の統合と監視が重要な場合」**には systemd timer が最適解です。特に、ログを syslog ではなく journal で一元管理したい場合や、他のサービスとの依存関係を明確に定義したい場合に有効です。例えば、「データベース起動後にバックアップを実行する」ようなタスクは、systemd の After=database.service を使用することで、より堅牢な実装が可能です。また、ログ分析ツールが systemd journal と連携している環境では、その方が運用コストを下げられます。
このように、タスクの複雑さや環境要件によって選択は変わります。また、Ubuntu 24.04 LTS や Debian 12 のような最新ディストリビューションでは、systemd のバージョンが比較的新しく、timer の機能も安定しているため、積極的に systemd timer を採用する傾向にあります。
さらに、**「混合運用」**という選択肢もあります。すべてのタスクを systemd timer に移行せず、重要なシステムタスクのみを移行し、単純な定期タスクは cron で維持するという手法です。これにより、移行リスクを抑えつつ、メリットの大きい部分から改善できます。2026 年時点では、このようなハイブリッド運用も十分に許容される範囲内ですが、将来的には systemd timer への完全移行が主流となる見込みです。
最後に、**「学習コスト」**についても考慮する必要があります。systemd の理解にはある程度の知識が必要ですが、その分、システム管理のスキル向上にもつながります。若手エンジニアや新規プロジェクトでは、systemd timer を基準に設計を進めることで、将来的な技術負債を減らすことができます。
Q1. cron と systemd timer の両方を同時に使うことは可能ですか？ はい、可能です。ただし、同じタスクを重複して実行しないように注意が必要です。一般的には、片方のみを使用することを推奨しますが、移行期間中などは両立させることがあります。設定ファイルの管理を分けることで混乱を防げます。
Q2. systemd timer を使う場合、cron デーモンは停止すべきですか？ 必ずしも停止する必要はありませんが、システムリソースの節約と管理コスト削減のために、使用しない場合は無効化（disable）するのが推奨されます。Ubuntu 24.04 では cron はデフォルトで有効なため、手動で調整することがあります。
Q3. @reboot の機能は systemd timer でも実現できますか？
はい、OnBootSec=0 または Unit.file で WantedBy= を設定することで実現可能です。systemd timer ではより柔軟に起動後の遅延制御を行えるため、cron よりも優れている場合があります。
Q4. cron のログはどこで確認できますか？
通常 /var/log/syslog または /var/log/cron で確認できます。システムによってファイルパスが異なる場合があるため、rsyslog の設定を確認してください。systemd timer は journalctl -u <name> で確認します。
Q5. systemd timer は Linux カーネルのバージョンに依存しますか？ systemd デーモンのバージョンに依存します。Ubuntu 24.04 LTS（systemd 255）や Fedora 41（systemd 256）など、比較的最近のディストリビューションであれば問題なく動作します。古い Linux では機能制限がある可能性があります。
Q6. cron のロックファイル（flock）は systemd timer でも使えますか？
はい、可能です。ExecStartPre に flock を記述して実行前処理として使用できます。また、systemd には RuntimeMaxSecs で実行制限をかける機能もあるため、代替手段も用意されています。
Q7. anacron は systemd timer のどの機能に相当しますか？
anacron の「シャットダウン中のタスク補完」は、systemd timer の Persistent=true に相当します。ただし、anacron はユーザーレベルで動作するスクリプトを管理する仕組みであるため、完全に 1:1 で置き換えられるとは限りません。
**Q8. cron を systemd timer に移行する際、最も気をつけるべき点は？
ログ出力先と権限設定です。cron のログは syslog ですが、systemd は journal です。また、cron では /etc/crontab 内のユーザー指定が重要ですが、systemd では User= 属性で管理するため、設定ファイルを注意深く変更する必要があります。
Q9. systemd timer のエラーが発生した場合はどうすればよいですか？
まず journalctl -u <timer>.timer でログを確認し、OnCalendar や Unit の記述ミスがないか検証します。また、依存する service ファイルが有効化されているかも確認してください。
Q10. 2026 年までに cron はサポートされなくなるでしょうか？ 現時点では、POSIX 準拠として永続的にサポートされる見込みです。しかし、新しい機能の開発は systemd timer に集中しており、将来的には systemd timer が標準的になることは間違いありません。
本記事を通じて、Linux の定期タスク管理における cron と systemd timer の違いと、それぞれの適切な使い分けについて解説しました。両者は競合するのではなく、それぞれが持つ特性を活かして運用することが重要です。
最終的には、運用するシステムの規模や既存環境の状況に合わせて最適な選択を行う必要があります。しかし、2026 年に向けた長期的な視点では、systemd timer を活用したモダンなインフラ設計が推奨されます。
Linux systemdのサービス管理を実践的に解説。カスタムサービスユニットファイルの作成、タイマー、依存関係設定、ジャーナルログ管理まで完全ガイド。
TimeshiftでLinuxシステムのスナップショットバックアップを作成する方法を解説。RSYNC/BTRFS各方式の設定と復元手順。
Linuxのモダンファイアウォール管理をfirewalldとnftablesで解説。ゾーンベース設定、リッチルール、nftablesの直接操作まで網羅したセキュリティガイド。
Linux用ユニバーサルパッケージ形式Flatpak・Snap・AppImageを比較。セキュリティ・起動速度・容量効率を徹底検証。
自作PCガイド：time を正しく理解する — その他/time spy/time