我有一个crontab，每天晚上都会创建我的数据库的转储：
20 3 * * * /path/to/dailydump.sh
dailydump.sh 包含：
#!/bin/sh
DATENAME=`date +%Y%m%d`
BASENAME="/path/to/dumps/db_${DATENAME}.sql"
/usr/bin/mysqldump -hhost -uusername -ppassword databasename > ${BASENAME}
权限是：
-rwx---r-x 1 ... dailydump.sh
drwxr-xrwx 2 ... dumps
为什么我的cronjob无法正常工作？
我在没有root用户访问权限的共享服务器上。没有登录/var/log/cron或/var/log/syslog。没有邮件/var/mail/<user_name>或/var/spool/mail/<user_name>（其实没有什么的都在/var/mail/和/var/spool/），[email protected]不邮寄任何错误消息，并且1 2 * * * /path/to/your/command &>/path/to/mycommand.log不保存任何日志文件。ps -ef | grep cron | grep -v grep?什么也不返回。（请参阅https://serverfault.com/a/449652）
整个设置工作正常，直到我将所有文件移至新域并必须设置新的crontab。（是的，我更新了所有路径和数据库登录信息。我也对其进行了多次检查。）我在同一台计算机上使用同一托管提供程序，因此环境没有改变。
任何帮助将不胜感激。
好的，这很奇怪。我的提供商的帮助中心说，如果要由cronjob执行的脚本位于受密码保护的目录中，则需要-auth=user:password -source在脚本路径之前添加。因此，我添加了（使用正确的身份验证）：
20 3 * * * -auth=user:password -source /path/to/dailydump.sh
结果是将错误消息通过电子邮件发送给我（如此MAILTO=工作），告诉我/bin/sh: -=: invalid option并列出了可用的选项。在帮助中心的例子其实并没有给出一个物理路径（/path/to/file），而是一个URL（ http://...），所以我删除auth，并source再次拯救了crontab中，和现在的F％§＃荷兰国际集团的cronjob运行！“ crontab看起来完全像以前一样，用char表示char，但是现在它可以运行了，对代码没有明显的更改。
我不知道问题出在什么地方，但是插入错误的代码并再次删除它可以解决问题。o_O似乎cronjob实际上一直在运行（因为如果没有运行，显然会引发错误），只是它什么也没做！非常神秘。如果有人可以（以可重复的方式）向我解释这一点，我将提供200英镑的奖励并奖励（在必要的两天等待之后）。
另外，@ chaos给了我另一个解决方案，完全避免了shell脚本，而让cron直接转储数据库（请参阅下面对他的回答的评论）：
20 3 * * * / usr / bin / mysqldump -hhost -uusername -ppassword数据库名称> / path / to / dumps / db _ $（date + \％Y \％m \％d）.sql
只是不要忘记转义百分号，否则脚本会发现“意外的EOF”。
谢谢大家的帮助。我又学到了很多（尽管这里没有错）。
为了确保cron守护程序正在运行并遵守crontab，您可以做一个小测试。crontab使用以下条目编辑您的内容：
* * * * * /bin/date >>/tmp/test
一分钟后，检查文件/ tmp / test。如果没有文件，则守护程序很可能没有运行。如果是这种情况，我会与提供者的支持联系。
编辑：
要确定cron实例中的环境，您可以：
* * * * * /usr/bin/id >>/tmp/test
* * * * * /usr/bin/env >>/tmp/test
现在查看文件的内容。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句