Linuxでcronとcrontabを使って自動タスクをスケジュールする

Linuxで作業する場合、遅かれ早かれ必要になります 反復的なタスクを自動化するバックアップ、クリーンアップ、アップデート、レポート生成、サービスの再起動…これらすべてにおいて、古典的な味方はデーモンです cron とファイル crontabこれにより、システムを監視しなくても、何を実行するか、いつ実行するかをシステムに指示できるようになります。

概念はシンプルですが、実際には cron には奥深さがあります。 crontabタイプ、構文満載 シンボル権限、ログ、パフォーマンスへの影響、一般的なエラー、代替手段 systemdタイマーなど cronとanacronの違い あるいは具体的な解決策 Windows およびmacOS。このガイドでは、ドキュメント全体や様々なページに散在するすべての内容を、異なる言葉とより分かりやすい口調で包括的かつ体系的に解説しています。

クロノグラフとは何ですか？正確な時間を保つことがなぜそれほど重要なのですか？

システムタイプ Unixのcronは バックグラウンドで実行されているデーモン マシンが起動した瞬間から、その仕事は一見非常にシンプルです。毎分プログラミングテーブルをチェックし、現在の日付と時刻に一致する命令があるかどうかを確認します。一致すると、コマンドまたは スクリプト 示された。

これは、Cronが システム時間時計またはタイムゾーンの設定が間違っていると、タスクは想定外の時間に実行されます。これを回避するには、[関連するサービス/プラットフォーム]との同期が不可欠です。 NTP（ネットワークタイムプロトコル）インターネット上のタイムサーバーを参照して正確な時刻を維持します。

ほとんどの最近のディストリビューションでは、次のコマンドで時間の状態を確認できます。

timedatectl

このコマンドは日付が正しいかどうか、 タイムゾーン システムはNTPと同期しており、有効になっています。タイムゾーンが正しくない場合は、次のように調整できます。

timedatectl set-timezone Europe/Madrid

さらに、NTPサービスは次のようなファイルで設定されます。 /etc/ntp.conf または、ディストリビューションに応じて同等のものを使用します。これらすべてを微調整することは不可欠です。なぜなら、クロックが同期していないと、 cronジョブ 何も変更していないのに、不合理な時間に実行が開始されます。

crontab とは何でしょうか?

cronデーモンは、自分自身で何をすべきかを「知っている」わけではなく、1つ以上の特別なファイルによって制御されます。 crontab（cronテーブル）これらの各ファイルは、時間フィールドに基づくコンパクトな構文を使用して、いつ何を実行するかを示す行を含む単純なテキスト ファイルです。

標準的な Linux システムには、主に 2 種類の構成があります。

• システムのクロナブ: 通常は / etc / crontab そして、以下のファイルによって補完される。 /etc/cron.d/ または次のようなディレクトリ /etc/cron.hourly, /etc/cron.dailyなどなど、大抵は彼が対応してくれます。 ルート 重要なシステムタスクに使用されます。
• ユーザーcrontab各ユーザーは独自のテーブルを持つことができ、次のようなパスに保存されます。 / var /スプール/ cron o /var/spool/cron/crontabs 配分に従って。これは各人がスケジュールを立てる際に推奨される方法です。 自分の仕事 グローバル設定を変更せずに。

ユーザーのcrontabは通常のエディタで直接編集するのではなく、コマンドを通じて編集します。 crontab適切な権限で正しい場所にファイルを保存する役割を担います。

現在のユーザーのテーブルを表示、作成、または変更するには、次のコマンドを使用します。

crontab -e

管理者権限を持っている場合は、オプションを追加することで他のユーザーのテーブルを管理できます。 -u:

crontab -e -u nombreusuario

crontab行の基本構文

スケジュールされたジョブはそれぞれcrontabファイル内の1行に記述されます。ユーザーcrontabファイルの基本形式は次のとおりです。

m h dom mon dow comando

これらの5つの最初のフィールドは瞬間または周期性を定義し、その後に 完全なコマンドまたはスクリプト 実行します。フィールドの意味は次のとおりです。

• 分（m）：0から59までの値。
• 時間（時間）: 0 から 23 (24 時間形式)。
• 日付（日）：1から31まで。
• 月（mon）: 1 から 12 まで、またはシステムに従った月の名前/略語。
• 曜日（下）: 0 から 6 まで (0 と 7 は日曜日を表すこともあります) または英語の略語 (mon、tue など)。

システムcrontab（例えば / etc / crontabコマンドの直前に追加フィールドがあり、 実行するユーザー そのタスク:

m h dom mon dow usuario comando

一般的なシステム入力は次のようになります。

00 19 * * 0 usuario /ruta/absoluta/consulta.sh

その行はスクリプトを実行します。 毎週日曜日に 午後7時、特定のユーザーのアカウントを使用します。ただし、個人用のcrontabでは、暗黙のユーザーが常にファイル所有者となるため、このフィールドは表示されません。

cron の特殊文字: *、-、/、その他

cronの優れた点は、各列に必ずしも1つの数字を書く必要がないことです。 特殊記号 範囲、リスト、または間隔を定義することで、複雑なスクリプトを必要とせずに非常に洗練されたルールを作成できます。

• * （アスタリスク）は、そのフィールドで「可能なすべての値」を意味します。例えば、月フィールドに*が付いている場合、すべての月を表します。
• , （カンマ）：特定の値のリストを示すために使用されます。例えば、時間フィールドでは、 6,18 6:00 と 18:00 に実行されることになります。
• – （ハイフン）：範囲を定義します。曜日を入力すると 1-5月曜日から金曜日まで定義します。
• / (バー): 「n 個ごと」を表します。例えば、 * / 10 このフィールドでは、「minute」という単語は「10 分ごと」と同義です。
• 範囲/除くいくつかの実装では次のような構文が許されている。 0-23/2 0 から 23 までの範囲内で「2 時間ごと」と言うことができます。

さらに、 # 行の先頭はコメントとみなされ、 実行されないこれは、各ジョブの実行内容を文書化する場合と、エントリを削除せずに一時的に無効にする場合の両方で非常に実用的です。

定義済み文字列: @daily、@reboot など

最も一般的なケースでは、cronはさまざまな キーワード これらは5つの時間フィールドを置き換え、テーブルを大幅に簡素化します。完全な構文よりも柔軟性は劣りますが、単純なタスクには非常に便利です。

最もよく使用されるものは次のとおりです。

• @リブート: システムの起動ごとにタスクを 1 回実行します。
• @年齢 o @毎年: 年に1回（0 0 1 1 *に相当）。
• @monthly: 毎月 1 日の午前 0 時 (0 0 1 * *)。
• @ウィークリー: 週に 1 回、その日の最初の時間の最初の 1 分が週の始まりとみなされます (ほとんどのシステムでは 0 0 * * 0)。
• @daily o @midnight: 毎日 00:00 (0 0 * * *)。
• @毎時: 毎時0分(0 * * * *)。

編集する場合 crontab -eこれらの文字列を直接使用できるため、1日に1回スクリプトを実行するなどの日常的なタスクは、非常にきれいな行に短縮されます。 @daily そして、希望するコマンドを入力します。

cronを使ったプログラミングの実例

理論自体は素晴らしいのですが、概念を本当に理解させるのは例です。これまで見てきた構文を使えば、次のようなプログラミングが可能です。

• 毎日午後7時にスクリプト:

  00 19 * * * /ruta/del/script/consulta.sh

• 日曜日のみ午後7時:

  00 19 * * 0 /ruta/del/script/consulta.sh

• 毎年19月4日午後00時:

  00 19 4 2 * /ruta/del/script/consulta.sh

• 10分ごと:

  */10 * * * * /ruta/del/script.sh

• 月曜日から金曜日 7:55と19:55:

  55 7,19 * * 1-5 /ruta/del/script.sh

多くのチュートリアルでは、過度に使用しないことを推奨しています コマンド cronライン自体の複雑さを排除し、代わりに 専用スクリプト （例えば/usr/local/binやscriptsディレクトリなど）crontabからそのスクリプトだけを実行します。これにより、テーブルが整理され、ロジックがファイルにまとめられるためデバッグが容易になります。

cronで使用するためのスクリプトと権限の作成

cronがスクリプトを実行できるようにするには、単にスケジュールを設定するだけでは不十分です。 正しい実行権限 適切なパスを指定します。簡単なスクリプトの例は以下のとおりです。

nano consulta.sh

#!/bin/bash
# script de ejemplo
sudo ls -l / > archivoResultado.txt

保存したら、cron が失敗しないように実行可能にする必要があります。

chmod ugo+x consulta.sh

この点は重要です。ファイルが実行可能でない場合、ジョブはサイレントに失敗したり、後で表示されるエラーが発生したりします。 ログまたは電子メールそこから、スクリプトへの絶対パスを含む対応する行を crontab に追加できます。

crontabの環境変数とPATH

cron がタスクを実行する場合、ユーザーと同じ環境で実行されるわけではありません。 ターミナル インタラクティブ。非常に最小限の環境から始まり、次のような変数があります。 HOME、SHELL、LOGNAME、PATH 基本値に設定されています。これは、コンソールでは問題なく動作するスクリプトが、 cronで実行すると失敗する.

よくある理由は、 パス cronが認識するディレクトリには、次のようなコマンドが実行されるディレクトリは含まれません。 ギット、 パイソン、pip、ノード など。解決策としては、常に バイナリへの絶対パス スクリプト内で、または crontab ファイルの先頭で明示的な PATH を定義します。例:

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
MAILTO="tu.correo@ejemplo.com"

これにより、cron 実行ファイルを見つける 対話型シェルから呼び出した場合と同じように動作します。また、MAILTO変数を追加することで、ジョブの出力とエラーを送信するアドレスを制御できます。BashとPowerShellからメールを送信する).

cronジョブの出力とログを表示する場所

デフォルトでは、cronは 標準出力とエラー出力 各ジョブは、タスクをスケジュールしたユーザーのローカルメールアドレスに送信されます。MTA（PostfixやSendmailなど）が設定されている場合は、以下のツールでこれらのメッセージを読むことができます。 mail または外部アカウントにリダイレクトします。

メールが設定されていない最小限の環境では、cronの動作は通常、システムログファイルに記録されます。ディストリビューションによって異なりますが、以下の場所に情報が記録されます。

• / var / log / syslog (Ubuntu、Debian および派生版)。
• /var/log/cron (CentOS、RHEL、Oracle Linux など)。

問題を調査するには、次のようなコマンドを使用できます。

tail -n 50 /var/log/syslog | grep CRON

tail -f /var/log/cron

さらに、ジョブの出力を特定のファイルにリダイレクトすることもできます。たとえば、 専用ログ その仕事に:

0 2 * * * /home/usuario/backup.sh >> /var/log/backup.log 2>&1

送信したくない場合は 郵送で何もないすべての出力を /dev/null に送信できます。

0 2 * * * /ruta/script.sh >/dev/null 2>&1

基本的なcrontab管理

コマンド crontab ユーザーのスケジュールされたジョブを管理するための最も一般的な操作を一元管理します。最も頻繁に使用されるオプションは次のとおりです。

• crontab -e: デフォルトのエディター (nano、vim など) を使用して現在のユーザーの crontab を編集 (または作成) します。
• crontab -l: ユーザーのテーブル内の現在のすべてのエントリを一覧表示します。
• crontab -r: ユーザーの crontab を完全に削除します (確認なしで、注意して続行してください)。
• crontabファイル: 現在の crontab を指定されたファイルの内容に置き換えます。
• crontab-uユーザー: 別のユーザーのテーブルを管理します (権限が必要です)。
• crontab -c ディレクトリ: 一部のシステムでは、crontab ファイルが保存されるディレクトリを定義できます。

あなたが作りたいなら バックアップ 作業するには、テーブルをテキスト ファイルにエクスポートするだけです。

crontab -l > ~/crontab_backup.txt

後で次のように復元します。

crontab ~/crontab_backup.txt

パフォーマンスへの影響とベストプラクティス

cron自体はリソースをほとんど消費しませんが、だからといって何も考えずにルールをシステムに詰め込めるわけではありません。実行されるすべてのジョブには、 CPU、メモリ、ディスク、そして多くの場合ネットワークの使用状況多くの重労働が重なると 時間運用中のユーザーやサービスに影響を及ぼすスパイクが発生する可能性があります。

多くのタスクをスケジュールする場合、明らかなリスクがいくつかあります。

• リソース消費複数の負荷の高いスクリプト (バックアップや更新など) が同時に開始されると、CPU または I/O に過負荷がかかり、システムの動作が遅くなる可能性があります。
• ネットワーク過負荷データの同期、ファイルのアップロード、API のクエリなどのタスクは、重要な時間に帯域幅を占有する可能性があります。
• アクセス競合2 つのジョブが同時に同じファイルまたはデータベースに書き込むと、破損した結果や矛盾した結果が生成される場合があります。

これらの問題を軽減するには、次のことが推奨されます。

• オフピーク時間を選ぶ重い作業の場合は、早朝などに行ってください。
• 次のようなツールを使用します nice y cplimit 特定のプロセスの優先度を下げたり、CPU の使用量を制限したりします。
• 同じスクリプトの同時実行を避けるには 群れ またはその他のブロッキング技術。
• 定期的にシステムログと応答を監視し、ボトルネックを検出します。 eBPFでパフォーマンスを監視する.

便利なトリックは、次のようなものを cron に追加することです。

0 3 * * * nice -n 19 /ruta/script_pesado.sh

そうすれば、夜中に仕事をすることができ、 最低CPU優先度残りのプロセスへの影響を軽減します。

よくある間違いとその回避方法

cron を使う際には落とし穴があります。問題を回避するために、知っておくべきよくあるエラーがいくつかあります。

• 不完全なPATHすでに述べたように、手動で動作するコマンドはデーモンの PATH に存在しないため、cron では動作しなくなります。
• 権限が正しくありません: 実行ビットのないスクリプト、または実行するユーザーにとって権限が制限されすぎているスクリプト。
• 相対パススクリプト内の正しいディレクトリに変更せずに ./script.sh または相対パスを使用すると、「ファイルが見つかりません」というエラーが発生します。
• 制御されていない出力: ログをリダイレクトせず、MAILTO を定義しないため、メール キューがバーストしたり、何が起こったかの痕跡が残らなかったりします。
• 頻繁すぎる: 不必要に毎分実行されるジョブで、一定の負荷と膨大なログが生成されます。

デバッグでは、次の方法を強くお勧めします。 まずスクリプトを手動でテストする cronを実行するのと同じユーザーアカウントを使用し、すべてがスムーズに実行されている場合にのみスケジュールを設定してください。もちろん、crontabには各行の目的を思い出せるよう、明確なコメントを追加してください。

cronのセキュリティとアクセス制御

自動化されたタスクは、誰かがcrontabに書き込みや変更を行った場合、悪用される主な標的となります。そのため、多くのディストリビューションでは、設定ファイルを通じてcronを使用できるユーザーを管理できるようになっています。 /etc/cron.allow y /etc/cron.deny.

一般的な操作は次のとおりです。

• 存在する場合 /etc/cron.allowそこにリストされているユーザーのみが cron を使用できます。
• 許可が存在しないが、 /etc/cron.deny、リストに載っている人以外は誰でも利用できるようになります。

さらに、 権限を確認する 関連するスクリプトやディレクトリに関しては、管理が不十分なsudoコマンドや、誰でも変更できるパスをcronに追加することは避けてください。脆弱なcrontabは、権限昇格や侵害されたシステムでの永続性維持への近道となる可能性があります。

Linux、Windows、macOS における cron と crontab の代替手段

cronは多くのサーバーで事実上の標準となっていますが、唯一の選択肢ではなく、常に最適な選択肢でもありません。コンピューターの電源がオフになっている場合でも実行する必要があるジョブなど、cronでは通常処理できないケースを処理するためのツールが存在します。

Linux/Unix の世界では、次のものが目立っています。

• アナクロン24時間7日電源がオンになっていないコンピューターに最適です。コンピューターの電源がオフになっているためにスケジュールされたタスクを実行できなかった場合は、コンピューターの再起動時にタスクが実行されます。
• フクロン: cron に似ていますが、スケジュールに関してより柔軟性があり、「この時間あたり」などの指定が可能で、頻繁にシャットダウンされるマシンでも動作します。
• hcronあまり知られていませんが、ジョブを整理するためのラベル、チーム ネットワーク管理、管理におけるセキュリティの向上などの機能が追加されています。
• マコン: スケジュールを再定義したり、初期時点からジョブを再構築したりする機能など、特殊性を備えた別の実装。

Linux 以外のシステムにも強力な代替手段があります。

• WindowsWinCron、VisualCron、Advanced Task Schedulerなどのツールは、 グラフィカルインターフェイス cron 構文を扱わずにタスクをスケジュールするのに非常に完全です。
• macOScronはまだ存在しますが、Appleは 打ち上げこれは .plist ファイルを使用して構成され、失敗したタスクの自動再起動、高度な条件など、システムとのより深い統合を提供します。

現代のLinuxでは、 システムタイマーこれらはsystemd内で「統合cron」として機能します。cronではできないこと、例えばサービスのチェーニング、イベントへの反応（ブーツ(ネットワーク接続など)、再試行の管理、ジャーナルへのログ記録などを行います。設定はより複雑ですが、要求の厳しい環境では最適な選択肢となることがよくあります。

プロフェッショナルおよびビジネス環境におけるCron

サーバーとビジネスの文脈では、cronとcrontabは 日常的なタスクを自動化する 人的ミスを削減します。組織における典型的な用途としては、以下のようなものがあります。

• 毎日または毎週のバックアップ データベース および重要なファイル。
• 定期的なシステムおよびアプリケーションの更新、またはセキュリティ チェック。
• レポートを自動的に生成し、さまざまな部門に送信します。
• メンテナンス スクリプト: 古いログの消去、ファイルのローテーション、一時ファイルの空化。
• リソース (CPU、RAM、ディスク) とサービスのスケジュールされた監視。

主なメリットは、管理者や技術者が反復的な作業から解放され、より価値の高い仕事に集中できるようになることです。しかし、プロフェッショナルな環境では、 仕事の文書チームや人が変わったときに予期せぬ事態を避けるために、スクリプトのバージョン管理とプログラム内容の定期的なレビューを行います。

さらに、cronを使用してシステムに情報を供給するのも良い方法です。 監視とアラート (たとえば、何かが失敗したり、時間どおりに実行されなかったりしたときに、チェック スクリプトで Healthchecks.io などのサービスに通知するなど)、ログを手動で確認するだけでは不十分になります。

これらすべてにより、cron と crontab はシステムの一種の「自動スケジュール」になります。頻度を適切に計画し、権限を監視し、環境を制御し、ログに注意すれば、狂ったりサーバーのパフォーマンスに悪影響を与えたりすることなく、ほぼすべてのタイプの日常的な自動化に cron と crontab を利用できます。