由Cron运行时,Shell脚本不会完全运行

发布于 2025-01-29 19:40:29 字数 1118 浏览 2 评论 0原文

文件 modbackup.sh 中的脚本在启动时不会完全运行,结果是损坏的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

edit:edit: 日志中没有任何信息,除了克朗已经开始 在邮件日志中,也不是在邮件中,也不是在邮件中 (我使用非常旧的Centos :(但我不认为这是错误的原因)。 仅用于测试:我在脚本中添加了文件名的%h%m,并进行了以下操作: 我手动运行它:sh/home/myscripts/modbackup.sh 并设置crontab -e在两分钟后运行同一命令

,几分钟后,出现了两个文件,但同时增长了,但是cronjob创建的文件 停止成长 (两个文件)。 在两种情况下,我都使用相同的GUI工具(档案管理器)打开。 通过手动启动脚本创建的文件,打开(手动启动),但另一个是另一个,即使我更改了扩展名,也无法从cronjob出发,错误是“档案中的意外EOF” (自动启动了)

The script in file modBackup.sh does not run completely when started by cron, the result is a corrupted tar.gz file that is half the size of this one if I run manually. In any case, its size is many times smaller than the one started manually, but still creates some content that can not be opened normally, archive is damaged

file modBackup.sh:

 #!/bin/sh
    find /home/share/ -mmin -720 -type f -exec tar -rvf /mnt/archives/`date +%F`-modified.tar.gz "{}" +

Тhe behavior of the automatic one seems to be interrupted and does not end.
When I run it manualy, the script creates a genuine archive as [current date]-modified.tar.gz

Here is the crontab -e:

00 18 * * 1-5 /home/myScripts/modBackup.sh

Edit:
There is no information in the logs except that crond has started
neither in the mail log, nor in the cron, nor in the messages
(I use very old CentOS :( but I don't think this is the reason for the error).
For testing only: I added %H%M of the file name in the script and did the following:
I ran it manually: sh /home/myScripts/modBackup.sh
and set with crontab -e to run a two minutes later the same command

After a few minutes, two files appeared that grew at the same time, but then the one created by cronjob
stopped growing
(two files).
I use the same GUI tool (Archive Manager) to open in both cases.
Тhe file, created by manually starting the script, opens (manually started), but the other one, from cronjob cannot, even after I changed the extension, the error is 'unexpected EOF in archive' (auto started)

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

淡紫姑娘! 2025-02-05 19:40:29

一起工作。

建议将用户的环境上下文与$ path和其他关键环境变量

#!/bin/sh

source ~/.profile
find /home/share/ -mmin -720 -type f -exec tar -rvf /mnt/archives/`date +%F`-modified.tar.gz "{}" +

Suggesting to include the users's environment context with $PATH and other critical environment variables for the application to work.:

modBackup.sh:

#!/bin/sh

source ~/.profile
find /home/share/ -mmin -720 -type f -exec tar -rvf /mnt/archives/`date +%F`-modified.tar.gz "{}" +
涙—继续流 2025-02-05 19:40:29

我发现在cron环境中,即使在脚本行的开头的add aDD上,“ find”命令误解了包含特定字符的文件名,即使编码的显式更改” ”。有了许多其他组合和尝试,我没有成功。
这就是为什么我留下“查找”命令并使用tar命令的选项来存档修改文件的原因。这种方式现在完美地工作:

fromDate = $(date --date = '15 hours ago')

/bin/tar -N "$fromDate" -zcf /mnt/archives/`date +% F-% H% M`-share.modified.tar.gz /home/share/

I found that in the cron environment the "find" command misinterprets filenames containing specific characters, even with the explicit change of the encoding with add at the beginning of the script line "export LANG = en_US.UTF-8; LC_CTYPE=...". With many other combinations and attempts I had no success.
That's why I left the "find" command and use the tar command with an option to archive modified files. This way works perfect now:

fromDate = $(date --date = '15 hours ago')

/bin/tar -N "$fromDate" -zcf /mnt/archives/`date +% F-% H% M`-share.modified.tar.gz /home/share/
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文