当通过crontab运行脚本时,问题来了。在shell上手动运行时,没有问题[重复]

这是人们似乎倾向于使用cron的一种非常常见的反模式。

Cron会向您发送一封带有脚本输出的电子邮件, 如果 它产生任何输出。人们经常将输出重定向到 /dev/null 以阻止cron发送电子邮件。这很糟糕,因为现在脚本的输出完全丢失了。即使脚本有一些内置的日志记录,它也可能在打开日志文件之前生成错误,这些错误会丢失。它也可能以一种不会写入日志记录机制的方式崩溃。

至少,您应该删除 2>&1 >/dev/null 开始接收电子邮件。(此外,使用临时cron作业测试邮件设置,如 1 * * * * echo "Test" )

下一个更好的解决方案是将其更改为 >> /var/log/myscript/current.log 然后还设置一些东西来旋转日志文件(比如 logrotate )并确保使用允许脚本用户写入的权限创建该目录。通过仅重定向脚本的STDOUT,它写入STDERR的任何错误或警告都会导致您收到电子邮件,如果没有错误/警告,则输出将转到日志文件,也不会发送电子邮件。

不过,这两项更改都没有解决根本问题,即当cron运行脚本时,它使用的环境与命令行上的环境不同。您真正想要的是一种在一致的环境中运行脚本的方式, 和 记录它。“最终解决方案”是在某种服务管理器中定义您的任务,然后偶尔使用cron来启动它。例如,您可以使用systemd定义一个不重新启动的服务,然后使用 systemctl start my_custom.service 在你的cron工作中。现在,您可以独立于cron进行测试,并且您的测试将具有完全相同的环境,并由服务管理器记录。作为额外的奖励,您可以避免意外地同时运行两次脚本,并且可以获得一种干净的方法来停止正在运行的cron作业,而不会有过时pid文件的危险。

我自己并不特别提倡systemd,但谢天谢地,有很多替代方案:

• Runit: http://smarden.org/runit/runsvdir.8.html
• S6: https://skarnet.org/software/s6/
• Perp: http://b0llix.net/perp/site.cgi?page=perpd.8

(但是,如果您的发行版是基于systemd的,那么安装和配置服务管理器要比仅使用systemd更艰巨。)每一项都允许您定义一个不会重新启动的服务。然后,使用shell命令向主管发出“运行一次”指令,该主管将任务作为子任务运行。现在,您可以轻松地自己启动作业,并查看日志中的所有错误,然后将该命令添加到crontab中,并知道当cron启动它时,它将以相同的方式运行。

回到您最初的问题,一旦您获得一些日志记录,您可能会发现这是权限问题或系统perl中的升级模块。