他の人が指摘したように、cronは、実行するプログラムの出力をメールで送信します（出力がある場合）。したがって、出力が得られない場合、基本的に3つの可能性があります。
crondは、プログラムを実行したりメールを送信したりするためのシェルを開始することさえできませんでしたcrondは出力のメール送信に問題があったか、メールが失われました。- プログラムは出力を生成しませんでした（エラーメッセージを含む）
ケース1.は非常にまれですが、何かがcronログに書き込まれているはずです。 Cronには独自の予約済みsyslog機能があるため、/etc/syslog.conf（またはディストリビューション内の同等のファイル）を調べて、機能cronのメッセージの送信先を確認する必要があります。人気の目的地には、/var/log/cron、/var/log/messages、/var/log/syslogがあります。
ケース2.の場合、メーラーデーモンログを検査する必要があります。Cronデーモンからのメッセージは、通常root@yourhostからのように表示されます。 crontabファイルのMAILTO=...行を使用して、cronが特定のアドレスにメールを送信するように設定できます。これにより、メーラーデーモンのログをgrepしやすくなります。例えば：
[email protected]
00 15 * * * echo "Just testing if crond sends email"
ケース3.では、効果を簡単に確認できる別のコマンドを追加して、プログラムが実際に実行されたかどうかをテストできます。たとえば、
00 15 * * * /a/command; touch /tmp/a_command_has_run
したがって、crondが実際に何かを実行したかどうかを確認するには、/tmp/a_command_has_runのmtimeを調べます。
ジョブの出力はいつでも明示的にログファイルに送信できます。
0 8 * * * /usr/local/bin/myjob > /var/log/myjob.log 2>&1
Crond iselfはジョブからの出力を受信しないため、これは前述のメールの動作よりも優先されることに注意してください。その動作を維持したい場合は、tee（1）を調べる必要があります。
メールが表示されない場合は、root @ yourcompanyにスパムでエラーを送信している可能性があり、そのアカウントを使用して監視している人にとっては非常に迷惑です。代わりに、出力をSyslogに送信してみてください。
*/5 * * * * yourcronjob 2>&1 | /usr/bin/logger -t yourtag
次に、cronjobが実行されるのを待ち、/ var/log/messages（または一部のシステムでは/var/log/user.log）でエラーを探します。
これは、「yourcronjob：コマンドが見つかりません」など、1〜2行しかないエラーメッセージに最適です。また、既存のsyslogインフラストラクチャ（Logrotation、中央のsyslog、Splunkなど）を利用します。また、ルートへの電子メールスパムを削減します。
Cronjobが数百行の出力を生成する場合、これは適切なソリューションではない可能性があります。
ジョブの実行に失敗した場合、またはジョブがゼロ以外の終了コードを返した場合は、crondからメールを受け取る必要があります。入力してみてください：
_$ mailx
_コマンドプロンプトで。
mailx(1)は、ほとんどすべてのUnixライクなシステムの基本的なメール読み取りプログラムです。それは現代の標準では非常に原始的ですが、常に利用可能であるとかなり期待できます。その他、より優れたメールエージェントが利用できる場合がありますが、たまたま使用しているランダムなマシンにどのエージェントがインストールされているのかわからないほど多くあります。
システムをインターネット電子メールサーバーとして構成していない限り、このメールサブシステムはマシン内でのみ使用されます。マシン上の他のユーザーと電子メールを送受信できますが、世界に電子メールを送信できない可能性があり、外部の世界からの電子メールは確実にあなたのマシンに到達できません。
デフォルトのcron構成では、プログラムの出力をメールで送信します。これが失敗した場合は、失敗したプログラムをシェルスクリプトでラップして、プログラムが失敗しないことを確認し、さらに出力をログに記録することができます。
これは一部のcron実装で構成可能な設定です。
Cronは基本情報を/var/log/messagesに記録しますが、プログラムの出力は呼び出し元のユーザーにメールで送信します。
私は数年前にこのスレッドに出くわしましたが、同じ問題が発生し、つい最近、Ricardoによる上記のケースの解決策に出会いました。電子メールの欠如を検出することは（あなたが述べたように）困難であり、root @ yourcompanyの電子メールにスパムを送信したくありません。興味があればチェックしてください deadmanssnitch.com。 。このツールは、前述のケースを解決するようです。使い方はかなり簡単に思えます。ツールがcronジョブに提供するコードを少し追加するだけです。指定した内部でジョブの実行に失敗した場合は、警告が表示されます。ジョブが再び実行を開始すると、警告も表示されます。
私はvixie-cronを使用しているため、これがすべてに当てはまるかどうかわかりません。しかし、ジョブのすべての出力を含むdead.letterファイルがあります。
私の/root/フォルダーにはcrons.cronがあり、crontab /root/crons.cronを実行してcrontabとして設定します。 dead.letterも/root/に作成されます。
編集私はGoogleでdead.letterを送信しましたが、これは配信不能メールです。どうやらcronとは関係ありません。メールが正しく設定されていない場合（私のように）、ファイルが作成されます。
別の便利なトリックは、実際に実行されているスクリプトを確認することです。
これはrun-parts -v --test /etc/cron.hourly/で行われます
> /etc/cron.hourly//logrotate
スクリプトが表示されない場合は実行されません。
このbtwは、/etc/cron.hourlyディレクトリにインストールされているスクリプトに対してのみ機能します。 crontabに設定されているアイテムは表示されません。
初心者の場合、これはデバッグが面倒な場合があります。分と時間の値を入れ替えないでください。分が最初に来て、次に時間が来る。それぞれに12未満の値を指定すると、それらは受け入れられますが、期待どおりまたはまったく機能しない可能性があります。