回答:
* * * * * myjob.sh >> /var/log/myjob.log 2>&1
cronジョブからのすべての出力を/var/log/myjob.logに記録します
mailメールの送信に使用できます。ほとんどのシステムは、未処理のcronジョブ出力を電子メールでrootまたは対応するユーザーに送信します。
stderrやstdoutログで、2>&1：間接の後に来るように持っているmyjob.sh >> /var/log/myjob.log 2>&1
YYYY-MM-DD_hh-mm-secに出力ファイル名に挿入して、すべてのファイル名が異なり、書き直さずに保持するのですか？
date +\%Y\%m\%d\%H\%M\%S2を-cron.log>＆1
デフォルトでは、cronは/ var / log / syslogにログを記録するため、次を使用してcron関連のエントリを表示できます。
grep CRON /var/log/syslog
journalctl | grep cronsystemdシステムでの使用
/var/log/cronAWS Linux AMI。
sudo journalctl -u cron
cronに記録される場所は、システムに大きく依存します。Linuxシステム（より正確には、を使用するシステムsyslog）でさまざまなロギング宛先がどのように構成されるかについての詳細を含む別の回答があります。他のシステムでは、これらの構成方法が異なる場合があります。
これが私のコードです：
* * * * * your_script_fullpath >> your_log_path 2>&1
>>追加し、2>&1標準出力と同じ場所に標準エラーを送信するよう指示します。
ロギングには少なくとも3つのタイプがあります。
プログラムが実行される前のロギング。コマンドを実行するためにcronjobが試行された場合にのみログに記録します。@Matthew Lockですでに述べたように、これは/ var / log / syslogにあります。
@Spliffsterで言及されているように、プログラムが実行を試みた後のエラーのログ。これは、電子メールまたはファイルに送信できます。私はファイルにログを記録することを好みます。電子メールの場合、新しい問題の原因があり、電子メールの送受信が完全に機能しているかどうかをチェックするからです。ある場合もあるし、ない場合もあります。たとえば、smtpの設定に関心がない単純な一般的なデスクトップマシンでは、ファイルへのロギングを好む場合があります。
* * * * COMMAND_ABSOLUTE_PATH > /ABSOLUTE_PATH_TO_LOG 2>&1
cronjobsの問題には、いくつかの一般的な原因があります。*実行されるバイナリの絶対パス。シェルから実行すると動作する可能性がありますが、cronプロセスは別の環境を使用しているように見えるため、絶対パスを使用しない場合、バイナリが常に検出されるとは限りません。*バイナリが使用するLIBRARIES。それは以前のポイントとほぼ同じですが、コマンドのNAMEを単に置く場合は、まったく同じライブラリを使用するバイナリを正確に参照しているか、または絶対パスで参照しているバイナリを確認してくださいコンソールを直接使用する場合と同じです。バイナリは、locateコマンドを使用して見つけることができます。次に例を示します。
$locate python
参照するバイナリがシェルで呼び出すバイナリと同じであることを確認するか、cronjobに配置する予定の絶対パスを使用してシェルでもう一度テストしてください。
Ubuntuでは、cron.logファイルにCRONエントリのみを含めることができます。
ファイルで言及さcronれ ている行のコメントを外し/etc/rsyslog.d/50-default.confます。
# Default rules for rsyslog.
#
# For more information see rsyslog.conf(5) and /etc/rsyslog.conf
#
# First some standard log files. Log by facility.
#
auth,authpriv.* /var/log/auth.log
*.*;auth,authpriv.none -/var/log/syslog
#cron.* /var/log/cron.log
ファイルを保存して閉じ、rsyslogサービスを再起動します。
sudo systemctl restart rsyslog
これで、独自のファイルでcronログエントリを確認できます。
sudo tail -f /var/log/cron.log
出力例：
Jul 18 07:05:01 machine-host-name CRON[13638]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
ただし、これらのスクリプトが出力をcron.log（または他のログファイル）に送信しない限り、実際にどのスクリプトが内部/etc/cron.dailyまたは/etc/cron.hourlyで実行されたかについての詳細情報は表示されません。
crontabが実行されているかどうかを確認するために、cron.logまたはsyslogで検索する必要がない場合は、出力を任意のログファイルにリダイレクトするcrontabを作成します。
# For more information see the manual pages of crontab(5) and cron(8)
#
# m h dom mon dow command
30 2 * * 1 /usr/local/sbin/certbot-auto renew >> /var/log/le-renew.log 2>&1
次の手順：https : //www.cyberciti.biz/faq/howto-create-cron-log-file-to-log-crontab-logs-in-ubuntu-linux/
cron は、メールで実行するすべてのジョブの標準出力と標準エラーをcronジョブの所有者に既に送信しています。
ファイルで使用MAILTO=recipientしcrontabて、電子メールを別のアカウントに送信できます。
これを機能させるには、メールを適切に機能させる必要があります。ローカルのメールボックスへの配信は通常問題ではありません（実際、ls -l "$MAIL"既に受信している可能性があります）が、ボックスから取り出してインターネットに送信するには、MTA（Postfix、Sendmailなど）が必要です。世界に接続するように適切に構成されている。
出力がない場合、電子メールは生成されません。
一般的な方法は、出力をファイルにリダイレクトすることです。この場合、もちろん、cronデーモンはジョブが出力を返さないようにします。バリアントは、標準出力をファイルにリダイレクトする（または何も出力しないようにスクリプトを書く-おそらくデータベースに結果を保存する、または単に何も出力しないメンテナンスタスクを実行する）ことであり、そこにある場合にのみメールを受信するエラーメッセージです。
両方の出力ストリームをリダイレクトするための構文は次のとおりです。
42 17 * * * script >>stdout.log 2>>stderr.log
>>前のジョブの出力が次のジョブの出力で置き換えられないように、上書きではなく（double ）を追加する方法に注意してください。
ここの多くの回答で示唆されているように、両方の出力ストリームを単一のファイルに送信することができます。2番目のリダイレクトを2>&1「標準エラーが発生するところはどこでも標準エラーが発生するはずです」と置き換える。（ただし、この方法を特に推奨することはしません。主に標準出力に何も期待しないが、おそらくスクリプトから呼び出された外部ツールからのものである可能性がある）を見落としている可能性があります。
cronジョブはホームディレクトリで実行されるため、相対ファイル名はそれを基準にする必要があります。ホームディレクトリの外に書き込む場合は、その宛先ファイルへの書き込みアクセス権があることを個別に確認する必要があることは明らかです。
一般的なアンチパターンは、すべてをにリダイレクトすることです/dev/null（そして、スタックオーバーフローに何かが機能していないときに何が問題だったかを理解するのを助けるように頼みますが、失われた出力も確認できません！）
スクリプト内から、定期的な出力（実際の結果、理想的には機械可読形式）と診断（通常は人間の読者向けにフォーマットされている）を分離してください。シェルスクリプトでは、
echo "$results" # regular results go to stdout
echo "$0: something went wrong" >&2
一部のプラットフォーム（およびGNU Awkなど）/dev/stderrでは、エラーメッセージにファイル名を使用できますが、これは適切に移植できません。Perlではwarn、die標準エラーに出力します。Pythonでは、に書き込むsys.stderrか使用しloggingます。Rubyでは、を試してください$stderr.puts。エラーメッセージに、診断メッセージを生成したスクリプトの名前を含める方法にも注意してください。
sudoを使用してコマンドを実行している場合、それは許可されません。Sudoにはttyが必要です。
sudo構成にも依存します。パスワードを提供する方法なしで実行する必要があるものNOPASSWD:は、sudoers構成で構成する必要があります。
それでもcronジョブを確認する場合は、cPanelでCronジョブを設定するときに有効なメールアカウントを提供する必要があります。
有効な電子メールを指定すると、実行されたcronジョブの出力を受け取ります。したがって、それをチェックして、すべてが正しく実行されていることを確認できます。cronジョブコマンドからの出力がない場合、電子メールを受信しないことに注意してください。
実行された各cronジョブについてメールを受け取ることを覚えておいてください。これは、cronが頻繁に実行される場合に受信トレイをあふれさせる可能性があります