我有一个用于压缩数据库和站点文件的脚本,然后将输出转储到服务器上的备份文件夹中。该脚本在命令行中运行良好,但它不能通过cron工作。
经过大量研究后,我认为cron无法以当前形式运行它,因为它在不同的环境中运行。
以下是保存为file_name.sh
#!/bin/bash
NOW=$(date +"%Y-%m-%d-%H%M")
FILE="website.com.$NOW.tar"
BACKUP_DIR="/backupfolder"
WWW_DIR="/var/www/website/"
DB_USER="dbuser"
DB_PASS="dbpw"
DB_NAME="dbname"
DB_FILE="website.com.$NOW.sql"
WWW_TRANSFORM='s,^var/www/website,www,'
DB_TRANSFORM='s,^backupfolder,database,'
tar -cvf $BACKUP_DIR/$FILE --transform $WWW_TRANSFORM $WWW_DIR
mysqldump -u$DB_USER -p$DB_PASS $DB_NAME > $BACKUP_DIR/$DB_FILE
tar --append --file=$BACKUP_DIR/$FILE --transform $DB_TRANSFORM $BACKUP_DIR/$DB_FILE
rm $BACKUP_DIR/$DB_FILE
gzip -9 $BACKUP_DIR/$FILE
我目前将脚本存储在/usr/local/scripts/
以上代码是否有问题导致无法通过cron运行?
它应该进入哪个crontab?终端crontab -e
或/etc/crontab
?它们是两个不同的文件。
答案 0 :(得分:0)
有几件事情浮现在脑海中:首先,cron作业最常见的问题之一是crond运行的东西通常只有一个非常小的PATH(通常只是/ usr / bin:/ bin),所以如果脚本使用任何命令从其他一些二进制文件目录中,它将失败。您系统上mysqldump
的位置(如果您不确定,请运行which mysqldump
)?如果这是问题,在脚本开头添加PATH=/usr/local/bin:/usr/bin:/bin
(或者你的情况下适当的任何东西)应该修复它。或者,您可以在crontab文件中设置PATH(将此行放在运行脚本的条目之前)。
如果这不是问题,我的下一步就是捕获脚本的输出,例如:
1 1 * * * /usr/local/scripts/file_name.sh >/tmp/file_name.log 2>&1
...并查看输出是否有用。 BTW,正如@tripleee所提到的,你的cron条目的格式适用于文件crontab -e
编辑,但不适用于/ etc / crontab。 / etc版本有一个附加字段,指定运行作业的用户,例如
1 1 * * * eric /usr/local/scripts/file_name.sh >/tmp/file_name.log 2>&1
答案 1 :(得分:0)
最佳做法是始终使用crontab -e(生成的文件通常位于/ var / spool / cron /中),这适用于我曾经使用过的每个unix和linux平台。
cron执行的其他常见问题是缺少环境变量。在.bash_profile中设置的任何环境变量(如果使用korn shell,则为.profile)都不一定存在于cron环境中。这可以通过在脚本中包含它们来克服。
正如戈登所说,道路是另一个嫌疑人。您可以始终在脚本中完整地执行可执行文件(例如/ bin / mysqldump)。一些更愤世嫉俗的人无论如何要做到这一点,以确保我们正在执行我们打算与当前路径中同名的其他文件相关联的内容。
我只能通过创建/脚本来修复你的具体问题,或者/ usr / local / scripts目录下的权限可能不允许cron用户执行?
答案 2 :(得分:-1)
我必须删除cron的扩展名(.sh)才能在某些情况下运行。
答案 3 :(得分:-2)
所以我修好了。不确定问题是什么,但这对我有用。
我最初的脚本位于/usr/local/scripts/
我在这里创建了一个新目录 - /scripts/
并将脚本移到那里。新的crontab -e
命令看起来像这样:
1 1 * * * bash /scripts/file_name.sh
完美无缺。同样,我不确定之前的问题是什么,但它现在有效。