【広告・アフィリエイトについて】本記事には、関連サービスへのリンクが含まれる場合があります。リンク経由で成果が発生することがありますが、記事内容は中立的に整理しています。

systemd timerとは？cronとの違いと定期実行で確認したい基本

Linuxで定期実行といえばcronが定番ですが、近年はsystemd timerを使う場面も増えています。systemd timerは、systemdの仕組みの中でジョブを一定間隔や特定時刻に実行するための機能です。Raspberry Piや自宅サーバーのように、再起動やサービス管理をまとめて扱いたい環境では、cronより管理しやすい場合があります。

一方で、cronが不要になるわけではありません。用途によって向き不向きがあるため、仕組みの違いと確認ポイントを押さえておくと、定期実行の運用で迷いにくくなります。

systemd timerとは何か

systemd timerは、systemdが持つ「タイマー用のユニット」です。実行したい処理そのものは.serviceファイルに書き、いつ動かすかを.timerファイルで指定します。つまり、処理とスケジュールを分けて管理できるのが特徴です。

この構成にすると、同じサービスを手動実行しやすくなるほか、状態確認やログ追跡もsystemdの枠組みで行えます。Linuxのサービス管理に慣れている人ほど、cronより見通しがよいと感じやすい方式です。

cronとの違いをざっくり整理する

cronは、昔から使われている定期実行ツールです。crontabに実行時刻とコマンドを1行で書くため、短い設定で済むのが利点です。単純な毎日実行や毎時実行なら、cronのほうが分かりやすいこともあります。

systemd timerは、時間指定が柔軟で、サービスとして扱える点が強みです。たとえば次のような違いがあります。

• cronは「その時刻にコマンドを打つ」考え方
• systemd timerは「サービスをいつ起動するか」を管理する考え方
• cronは設定が簡潔だが、ログや依存関係の管理は別途考える必要がある
• systemd timerは、起動失敗の確認や状態管理をsystemdと揃えやすい

なお、どちらが上位互換という話ではありません。小規模な定期処理ならcronで十分なことも多く、systemdに寄せる理由があるときにtimerが有力になります。

systemd timerが向いている人

systemd timerは、次のようなケースで扱いやすい傾向があります。

• Raspberry Piや自宅サーバーで、systemdを普段から使っている
• 定期実行だけでなく、手動起動や停止も同じ単位で管理したい
• バックアップ、ログ整理、API問い合わせなどの処理をサービス化したい
• 再起動後の挙動も含めて、運用をまとめて把握したい

反対に、1行で済む単純なコマンドを毎日動かすだけなら、cronのほうが設定コストは低めです。まずは「何を管理したいのか」で選ぶのが現実的です。

基本構成は.serviceと.timerの2つ

systemd timerを使うときは、通常.serviceと.timerの2ファイルを用意します。たとえば、Pythonスクリプトの定期実行であれば、service側でスクリプトを呼び出し、timer側で実行間隔を指定します。

役割を分けると、次のように考えやすくなります。

• .service：実際に何を実行するか
• .timer：いつ実行するか

この分離は、後から実行方法だけを変えたい場合にも便利です。たとえば、手元での手動テストはservice単体で行い、本番運用ではtimerで起動する、といった整理がしやすくなります。

設定で確認したい主な項目

systemd timerでは、まず以下の項目を確認しておくと設定ミスを減らしやすくなります。

• OnCalendar：特定時刻や定期のカレンダー指定
• OnBootSec：起動後からの経過時間
• OnUnitActiveSec：前回実行からの経過時間
• Persistent：停止中に実行予定だった分を、次回起動時に補うかどうか
• Unit：呼び出すserviceユニット名

特にPersistentは見落としやすい項目です。マシンが止まっている間にスケジュール時刻を過ぎた場合、次回起動時の挙動に影響します。バックアップや集計処理のように「抜けると困る」ジョブでは、要件に合うか確認しておくと安心です。

よくある失敗

定期実行の設定では、仕組みよりも「思った通りに動かない」ことがつまずきやすいポイントです。systemd timerでも次のような失敗がよくあります。

• serviceファイルは作ったが、timerを有効化していない
• パスの指定が曖昧で、実行時にコマンドが見つからない
• Python仮想環境や環境変数を前提にしていて、systemdから呼ぶと動かない
• 実行権限や所有者の設定が不足している
• ログを見ずに設定だけを何度も書き換えてしまう

特に、シェルで直接動くコマンドがsystemd経由では失敗するケースは珍しくありません。ログインシェルの設定ファイルが読み込まれないためです。コマンドはできるだけフルパスで書き、必要な環境変数はservice側で明示すると分かりやすくなります。

cronと比べたときの注意点

systemd timerは便利ですが、cronと同じ感覚で置き換えると戸惑いやすい点があります。たとえば、cronでは1行で済む処理でも、systemdではserviceとtimerの2ファイルが必要になります。そのぶん構成は増えます。

また、systemdが前提の環境で力を発揮しやすいため、最小構成のコンテナや特殊な環境ではcronのほうが扱いやすいこともあります。既存の運用ルールや、メンテナンスする人の習熟度も含めて選ぶのが実務的です。

小さく試す手順

初めてsystemd timerを使う場合は、いきなり本番のバックアップに使うより、短いコマンドで確認するほうが安全です。まずは次の順で試すと整理しやすくなります。

1. ログに文字を出すだけのserviceを作る
2. 1分おきなど、短い間隔のtimerを作る
3. systemctl list-timersで次回実行予定を確認する
4. journalctlで実行ログを確認する
5. 問題がなければ、実処理に差し替える

この流れにすると、設定のどこでつまずいたかを切り分けやすくなります。定期実行の検証では、「タイマーが動いていない」のか「サービスが失敗している」のかを分けて見ることが重要です。

確認に使うコマンドの考え方

systemd timerでは、動作確認にいくつかのコマンドを使います。代表的なのは以下です。

• systemctl status：ユニットの状態確認
• systemctl list-timers：タイマー一覧と次回実行時刻の確認
• journalctl -u ユニット名：ログ確認

これらは「定期実行が設定されているか」だけでなく、「直近の実行で何が起きたか」を追うのに役立ちます。cronよりも状態確認の入口が揃っているため、原因調査をしやすい場面があります。

導入前に必ず確認したいこと

この記事で扱うサービス、ツール、ソフトウェア、設定方法、料金、仕様、提供条件は変更される場合があります。実際に導入する前には、必ず公式サイト、公式ドキュメント、管理画面、利用規約などの最新情報を確認してください。特にサーバー運用、WordPress、AIツール、電子工作、収益化に関わる内容は、古い情報のまま判断するとトラブルにつながることがあります。

まとめ

systemd timerは、systemd中心でLinuxを運用している環境で扱いやすい定期実行の方法です。cronより設定はやや増えますが、サービスとして分けて管理できるため、再起動やログ確認を含めた運用では整理しやすくなります。

一方で、単純な定期コマンドならcronのほうが手早いこともあります。重要なのは、機能の多さではなく、対象の処理をどこまで管理したいかです。まずは小さなジョブで試し、serviceとtimerの役割、ログの見方、失敗時の挙動を確認してから本番用途に広げると、安全に導入しやすくなります。

関連記事

• Raspberry Piで始める定番アイデア集
• Pythonでできる自動化の基本アイデア
• VPSの選び方と比較時の確認ポイント