Answers:
* * * * * 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\%S-cron.log 2>＆1
默认情况下，cron日志记录到/ var / log / syslog，因此您可以使用以下命令查看与cron相关的条目：
grep CRON /var/log/syslog
journalctl | grep cron在系统系统上使用
/var/log/cron在AWS Linux AMI上
sudo journalctl -u cron
cron记录的位置非常依赖系统。有一个单独的答案，其中包含有关如何在Linux系统（或更正确地说，是使用的系统syslog）上配置各种日志记录目标的详细信息。其他系统可能有不同的方式来配置这些东西。
这是我的代码：
* * * * * your_script_fullpath >> your_log_path 2>&1
>>追加并2>&1说将标准错误发送到与标准输出相同的位置。
至少有三种不同类型的日志记录：
程序执行之前的日志记录，仅当cronjob TRIED执行命令时才记录日志。如@Matthew Lock所述，该文件位于/ var / log / syslog中。
程序尝试执行后记录错误，如@Spliffster所述，可以将其记录到电子邮件或文件中。我更喜欢登录到文件，因为使用电子邮件，那么您就有了一个新的问题源，并且可以检查电子邮件的发送和接收是否工作正常。有时是，有时不是。例如，在您对配置SMTP不感兴趣的简单普通台式机中，有时您会更喜欢登录到文件：
* * * * COMMAND_ABSOLUTE_PATH > /ABSOLUTE_PATH_TO_LOG 2>&1
cronjobs有一些常见的问题根源：*要执行的二进制文件的绝对路径。从外壳运行它时，它可能会起作用，但是cron进程似乎使用了另一个环境，因此，如果不使用绝对路径，它并不总是会找到二进制文件。*二进制文件使用的LIBRARIES。它与上一点大致相同，但是请确保（如果仅放置命令的名称）是指使用完全相同的库的二进制文件，或者更好，请检查您使用绝对路径引用的二进制文件与您直接使用控制台时所指的相同。可以使用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)
但是，您将不会看到有关在/etc/cron.daily或中实际运行了哪些脚本的更多信息/etc/cron.hourly，除非这些脚本将输出定向到cron.log（或其他一些日志文件）。
如果要验证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>&1并说“标准错误应该在标准输出所处的任何地方”。（但是我并不特别赞成这种做法。如果您对标准输出不抱有任何期望，但是可能已经忽略了某些东西，也许是来自脚本调用的外部工具，这在很大程度上是有意义的。）
cron作业在您的主目录中运行，因此任何相对文件名都应与此相对。如果要在主目录之外进行写操作，显然需要单独确保对目标文件具有写权限。
常见的反模式是将所有内容重定向到/dev/null（然后让Stack Overflow帮助您找出在某些情况下无法解决问题的原因；但是我们也看不到丢失的输出！）
在脚本中，请确保将常规输出（实际结果，理想情况下以机器可读的形式）和诊断（通常为人类阅读器格式化）分开。在Shell脚本中，
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。还请注意，错误消息应如何包括产生诊断消息的脚本的名称。