【问题标题】:Tar error: Unexpected EOF in archive when running via Cron/PHP焦油错误:通过 Cron/PHP 运行时存档中出现意外的 EOF
【发布时间】:2015-11-10 05:14:54
【问题描述】:

我有一个 PHP 控制台脚本,它通过 cron 调用,它本身会创建一个目录的 tar 文件。

通过 cron 调用 PHP 脚本时,未正确创建 tar 文件。查看tar文件时报如下错误:

gzip: stdin: unexpected end of file
tar: Unexpected EOF in archive
tar: Error is not recoverable: exiting now

通过控制台手动调用 PHP 脚本时,会正确创建 tar 文件。 cron 日志输出显示没有错误。

这里是 PHP 脚本的 tar 调用。

 exec("cd $this->backupTempFolderName/$id; tar -czf ../../$this->backupFolderName/$tarFileName $dbDumpFileName documents");

有人知道为什么 tar 在手动调用时会正确创建而在通过 cron 调用时会失败吗?

更新:通过 cron 创建 tar 文件时给出的错误是:

tar: ../../backup/20150819-060003.tar.gz: Wrote only 4096 of 10240 bytes
tar: Error is not recoverable: exiting now

有时错误是:

tar: ../../backup/20150819-054002.tar.gz: Cannot write: Broken pipe
tar: Error is not recoverable: exiting now

如前所述,通过 cron 执行时会创建 tar 文件,但始终为正确大小的 50%(手动执行脚本时):

-rw-r--r--  1 gtz gtz 1596099468 Aug 19 06:25 20150819-042330.tar.gz <- Manually called skript, working tar
-rw-r--r--  1 gtz gtz  858570752 Aug 19 07:21 20150819-052002.tar.gz <- Script called via cron, broken tar

更新 2

在根据此处给出的输入进行进一步研究后,可能应该补充一点,调用脚本的 cron 脚本正在虚拟专用服务器上运行 - 我怀疑主机未记录的 cron 作业可能存在一些限制(仅文档中给出了最小重复时间的限制)。

【问题讨论】:

  • 确切的 crontab 条目是什么?这些变量$this-&gt;backTempFolderName/$id, $this-&gt;backupFolderName/$tarFileName, $dbDumpFileName 扩展为什么?
  • 变量只提取到带有文件夹路径的字符串(工作正常,因为脚本在手动调用时可以正常工作)并且玉米作业条目是59 23 * * 0 cd path/to/application; /opt/php53/bin/php app/console giz:backup &gt;/paht/to/application/app/logs/backup-output.logbackup-output.log 本身没有错误,因为 php 脚本本身似乎工作正常。
  • 但是扩展路径有空格吗?是相对的还是绝对的? Crown 作业是否以同一用户身份运行? Crown用户有写文件的权限吗?
  • 0) 检查系统日志。 cronjob(它是否通过 PHP 运行?)可能已终止,因为它超出了某些资源限制(时间?)
  • 在运行tar 命令之前检查磁盘空间并记录它。我怀疑您在 cron 运行时可能缺少可用磁盘空间。

标签: php cron tar


【解决方案1】:

该错误通常来自磁盘空间不足。

我会通过在 tar 执行之前和之后添加一些日志来对此主题进行更多研究。

还要检查您的配置使用哪个用户来执行您运行备份的 cron 作业。它也可以是对该用户的一些配额限制,当您在 cron 之外的控制台上运行时不会发生这种情况。

向您的供应商询问用户和进程的 VPS 配额限制......这就是这里的警钟。

【讨论】:

  • 如果可能,请检查cron 作业在哪个用户下运行,然后使用同一用户从命令行运行。 cron 用户可能会被 chroot 监禁到临时目录中的可用空间很少的 VFS 中,或者类似的事情。
【解决方案2】:

我猜你有资源限制 正如 M. Ivanov 所说,在您的 PHP 脚本中添加此命令:

shell_exec("php -info");

并在从命令行和 cron 作业执行脚本时检查此参数

memory_limit => ???

您也可以尝试通过将内存限制提高到 1600M

来运行您的 cron
php -d memory_limit=1600M scriptCompressor.php

希望有帮助:)

【讨论】:

  • 我修改了上面提到的备份脚本并通过控制台调用手动运行它。 php.ini 中设置的内存限制为memory_limit =&gt; 128M =&gt; 128M。通过 cron 调用时,内存限制也是 128M。但是在这种情况下PHP内存不应该相关吗(stackoverflow.com/a/11291704/461992)?
【解决方案3】:

您可能想尝试直接从 PHP 创建 tarball 以避免exec 调用。看到这个答案:https://stackoverflow.com/a/20062628/5260945

此外,查看您的 cron 条目,您的示例中没有前导斜杠。我知道这可能只是评论的错字,但请确保您有 cd 命令的绝对路径。 cron 作业的默认环境与您的登录 shell 不同。

【讨论】:

    【解决方案4】:

    cronjobs 本身通常没有限制。如果您使用共享主机,他们可能已经安装了一些强制脚本,但我怀疑它们也会破坏您的控制台备份。

    如果您从某个容器运行 cronjobs,例如Drupal,它们有特殊的限制。

    还可以通过以下方式检查 bash 限制: ulimit -a

    在备份开始之前和之后报告磁盘空间以防万一。在 VPS 上它通常很小。

    【讨论】:

      【解决方案5】:

      我确定它的内存或执行时间有问题。 做一件事,为只包含单个测试文件的目录运行相同的脚本并检查输出,如果您的脚本在这种情况下工作,那么 100% 确定它的内存问题。

      尝试调整内存参数并执行您的脚本。

      希望对你有所帮助。

      谢谢

      【讨论】:

        【解决方案6】:

        查看以下错误。

        tar: ../../backup/20150819-054002.tar.gz: Cannot write: Broken pipe
        tar: Error is not recoverable: exiting now
        

        我看到 PHP 脚本中的 exec 函数没有阻塞或过早导致错误。因此,在 Cron 作业期间调用的 PHP 会话在命令完成之前退出。这只是一个猜测,但您可以尝试在从 Cron 运行它时将其发送到后台。

        exec("cd $this->backupTempFolderName/$id; tar -czf ../../$this->backupFolderName/$tarFileName $dbDumpFileName documents &");
        

        这个命令应该是阻塞的,所以这只是在黑暗中的一个镜头。

        http://php.net/manual/en/function.exec.php

        【讨论】:

          【解决方案7】:

          当您尝试执行 php 文件并给出 EOF 错误时发生错误。这意味着您必须在您的 php 文件中的某处检查您的 cron 文件的代码,您可能会忘记完成条件或类等的括号......

          祝你好运['}

          【讨论】:

            【解决方案8】:

            要在通过 cron 执行时将错误写入日志,将 cron 行中的 &gt;/paht/to/application/app/logs/backup-output.log 替换为 2&gt;&amp;1 &gt;/path/to/application/app/logs/backup-output.log 还要检查 cron 行中的路径。也许 change-dir 没有像您想象的那样工作。从 cron 运行 php 脚本时,尝试将 getcwd() 打印到日志或其他内容。

            编辑:我想知道为什么这被选为not useful。提问者提到cron执行脚本时不会将错误打印到日志中。这不难想象,因为&gt; 只是将 STDOUT 而不是 STDERR(将在其上打印 php 错误)重定向到日志。所以添加2&gt;&amp;1 可能会揭示一些新信息。

            【讨论】:

              猜你喜欢
              • 1970-01-01
              • 2012-10-25
              • 2013-07-13
              • 1970-01-01
              • 1970-01-01
              • 1970-01-01
              • 2021-12-10
              • 2019-11-05
              • 1970-01-01
              相关资源
              最近更新 更多