放入`/ etc / cron.hourly /`时，cron作业不起作用，但在`crontab -e`中定义时可以正常工作
如果我通过crontab -e定义我的cron调度程序，则调度程序可以正常工作。 但是，将文件放在/etc/cron.hourly/中并不适用于我的情况。
运行run-parts --test /etc/cron.hourly输出脚本。 此外，脚本名称为my_sql_backup ，并且没有文件扩展名。
该脚本是root:root具有777权限。
cron.hourly调度程序似乎正在工作，因为这是grep CRON /var/log/syslog ：
Mar 1 11:17:01 my-instance CRON[12919]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
此外，如果我手动运行该命令，调度程序就像它应该运行：
sudo bash -c "cd / && run-parts --report /etc/cron.hourly"
但是，这似乎并没有起作用。 该脚本将MySQL数据库备份到Google云端存储，但是当我通过Web控制台检查时，存储不会更新。
这里有什么我想念的吗？ 为什么放在/etc/cron.hourly/调度程序脚本不起作用？
UPDATE
将echo test > /tmp/foobar.tmp行添加到我的cron脚本后，我发现tmp文件就在那里。 实际上我发现了我自己的脚本发布的tmp文件。
脚本的内容如下。 那么运行gsutil命令可能会出现问题？
# define environment variables here sudo sh -c "mysqldump -u$MYSQL_USER -p$MYSQL_PASS $MYSQL_DBNAME --single-transaction | gzip -9 > $MYSQL_TEMPPATH" >/dev/null 2>&1 gsutil cp $MYSQL_TEMPPATH gs://$GS_BUCKET_NAME/$MYSQL_S3_DESTPATH >/dev/null 2>&1
再次，如果我手动运行它，脚本工作正常，所以环境变量设置为正确的值…
更新2
我终于发现在获取gsutil命令发出的日志文件后，它具有以下内容：
AccessDeniedException：403 OAuth2范围不足以执行此操作。
如果在/etc/cron.hourly/运行，我仍然需要调查拒绝访问的原因…但问题出在gcloud ，而不是cron …感谢您对评论的支持。
在调查日志输出后，我终于发现日志文件包含以下来自gcloud执行的内容：
AccessDeniedException：403 OAuth2范围不足以执行此操作。
所以问题出在gcloud ，而不是cron。
那么如何避免gcloud上的访问被拒绝错误？
要授予VM访问云存储的权限，请执行以下步骤：
-
停止VM实例
-
编辑VM以将云存储从读取更改为读取/写入 。
-
重启你的VM
现在我终于按计划工作了……
来源： https ： //stackoverflow.com/a/41604071/2360798
你没有提供足够的关于脚本的信息来了解它应该做什么，也没有提供为什么它可能在cron工作中失败 – 有几个常见的原因。
但是，你的问题的标题和第一段（关于用户和根crontabs）看起来很清楚，所以让我们回答：
用户crontabs和root crontabs 格式略有不同 ，不可互换。
例：
1 1 * * * root /bin/foo // root crontab in /etc/cron* 1 1 * * * /bin/foo // user crontab in /var/spool (see it using the 'crontab' command
看到不同？ root crontab有一个额外的字段来指定用户。 用户不必是root ….虽然在实践中它通常是root。
假设您要运行数据库备份作业。 将根crontab添加到/etc/cron.d/以触发备份脚本。 只是触发。 一个常见的错误是使crontab比它需要的更复杂。 所有逻辑和错误检查以及权限和日志记录都应该在脚本中，而不是crontab中。