文件 modBackup.sh 中的脚本在由cron启动时没有完全运行,结果是一个损坏的tar.gz文件,如果我手动运行,它的大小是这个文件的一半。在任何情况下,它的大小比手动启动的小很多倍,但仍然创建了一些无法正常打开的内容,归档文件被损坏
文件 * modBackup.sh *:
# !/bin/sh
find /home/share/ -mmin -720 -type f -exec tar -rvf /mnt/archives/`date +%F`-modified.tar.gz "{}" +
当我手动运行它时,脚本创建了一个真正的存档文件[当前日期]-modified.tar.gz
下面是crontab -e:
00 18 * * 1-5 /home/myScripts/modBackup.sh
编辑:日志中没有任何信息,除了crond没有在邮件日志、cron或消息中启动(我使用非常旧的CentOS:(但我认为这不是错误的原因)。仅用于测试:我在脚本中添加了%H%M的文件名,并执行了以下操作:我手动运行了它:sh /home/myScripts/modBackup.sh
,并使用crontab -e
设置为两分钟后运行相同的命令
几分钟后,出现了两个同时增长的文件,但随后由cronjob创建的文件停止增长(two files)。通过手动启动脚本创建的文件可以打开(manually started),但另一个文件,从cronjob无法打开,即使我更改了扩展名,错误是“存档中出现意外EOF”(auto started)
2条答案
按热度按时间4ioopgfo1#
建议将用户的环境上下文与
$PATH
和其他关键环境变量一起包含进来,以便应用程序正常工作。第1001章:我的modBackup.sh:
du7egjpx2#
我发现,在cron环境中,“find”命令会错误地解释包含特定字符的文件名,即使在脚本行“export LANG = en_US.UTF-8; LC_CTYPE=..."。我尝试了许多其他的组合和尝试都没有成功。这就是为什么我离开了“find”命令并使用带有选项的tar命令来存档修改过的文件。这种方法现在非常好用: