脚本运行于终端，而不是cron。我需要对这个脚本做什么编辑？

Question

我有一个脚本，用于压缩数据库和站点文件，然后将输出转储到服务器上的备份文件夹中。脚本在命令行中运行良好，但它不会在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/中

1. 上面的代码有什么不允许它在cron中运行的地方吗？
2. 它应该进入哪个crontab ?来自终端的crontab -e还是/etc/crontab？它们是两个不同的文件。

Answer 1

所以我修好了。不知道是什么问题，但这对我有用。

我最初的脚本位于/usr/local/scripts/中

我在这里创建了一个新目录- /scripts/，并将脚本移到那里。新的crontab -e命令如下所示：

1 1 * * * bash /scripts/file_name.sh

效果很好。再说一遍，我不知道这个问题以前是怎么回事，但现在起作用了。

Answer 2

首先，cron作业中最常见的问题之一是crond运行的路径通常非常小(通常只是/usr/bin:/bin)，所以如果脚本使用来自其他二进制目录的任何命令，它就会失败。mysqldump在您的系统上在哪里(如果您不确定的话运行which mysqldump )？如果这是问题所在，应该在脚本的开头添加PATH=/usr/local/bin:/usr/bin:/bin (或任何适合您的情况)来修复它。或者，您可以在crontab文件中设置路径(将这一行放在运行脚本的条目之前)。

如果这不是问题所在，我的下一步将是捕获脚本的输出，如下所示：

1 1 * * * /usr/local/scripts/file_name.sh >/tmp/file_name.log 2>&1

..。看看输出是否信息丰富。顺便说一下，正如@tripleee所提到的，cron条目的格式适合于crontab -e编辑的文件，但不适合/etc/crontab。/etc版本有一个额外的字段，指定要运行作业的用户。

1 1 * * * eric /usr/local/scripts/file_name.sh >/tmp/file_name.log 2>&1

Answer 3

最佳实践是始终使用crontab -e (生成的文件通常在/var/spool/cron/中)，这在我曾经使用过的每个unix和linux平台上都是有效的。

cron执行中的其他常见问题是缺少环境变量。在.bash_profile中设置的任何环境变量(如果使用korn，则是.profile )都不一定存在于cron环境中。这可以通过将它们包含在脚本中来克服。

就像戈登说的，路径是另一个嫌疑犯。您可以始终在脚本中完成可执行的路径(例如/bin/mysqldump)。无论如何，我们中一些更愤世嫉俗的人这样做是为了确保在当前路径中，我们正在执行指定给其他同名文件的内容。

我只能猜测您的具体问题，因为您通过创建/scripts修复了它，可能/usr/local/script目录上的权限不允许cron用户执行吗？