Git推送“错误：索引包死于信号9”答案

【问题标题】：Git push "error: index-pack died of signal 9"Git推送“错误：索引包死于信号9”
【发布时间】：2011-12-20 13:42:20
【问题描述】：

我已经看到了几个similar questions，但无法解决我的问题，所以我再次询问。

我向现有的支持 git 的项目添加了一些新文件，并试图将它们向上推。当我进行推送时，它会压缩它们，然后写入它们，然后当它到达 %100 时，它会失败并出现以下错误：

error: index-pack died of signal 9 332.28 MiB | 5712 KiB/s   
error: pack-objects died with strange error
error: failed to push some refs to     '<username>@<my repo location'

到目前为止我尝试过的事情：

去 repo 并确保一切都是可写的，就像建议的 here
在 .gitattributes 中的某些文件类型上设置 binary -delta 选项
移出一些文件夹（并 git 提交删除），以便稍后单独添加它们。

我有点没有想法...：/有什么建议吗？感谢任何建议 - 最大

编辑-我后来发现这是由于dreamhost由于过多的内存消耗而终止了推送（我通过将我的应用程序文件夹复制到dreamhost上的repo服务器并从那里进行推送来做到这一点）。

我有found 一些pages，-谈论 git 中的 NO_MMAP=1 选项以帮助防止这种情况，但他们在安装 git 时谈论它。我可以在现有的 git install 中设置此选项吗？它是执行推送的 git-inited 应用程序配置的一部分，还是 repo 配置的一部分？

编辑 2 - 按照上面页面上的说明，我下载并制作了自己的本地 git 二进制文件，并设置了 NO_MMAP=1 选项。

我确保这些是在我的路径中安装了 dreamhost 的版本之前，并且“which git”显示了我的本地版本，到目前为止一切都很好。但是，我遇到了完全相同的问题。

我是否需要对我的 repo 做一些事情以使 NO_MMAP 选项起作用，或者你认为问题是什么？

【问题讨论】：

您是否维护您尝试推送到的主机？信号 9 是一个要发送的强信号，您需要确定远程主机上的谁/什么将该信号发送到 index-pack 进程。检查机器上的dmesg 或/var/log 的内容可能会发现一些问题。
服务器在什么操作系统上？您可以在 Windows 上使用 procmon 来查看文件系统等上发生了什么，或者找出在 linux 或类似系统上使用 strace/ltrace 的方法？
@EmilSit - 作为一个实验，我只是将我的 git app 文件夹复制到 repo 所在的同一服务器，并将其配置更改为指向本地 repo 文件夹，以便我的推送是只是发生在服务器上，不需要任何http请求。我得到了这个：Yikes! One of your processes (git, pid 7746) was just killed for excessive resource usage. Please contact DreamHost Support for details. 你可以看到它是一个共享的 Dreamhost 服务器（所以我的同事并不拥有它，但他至少拥有那个共享位）。
可能有问题的资源是内存。有没有办法让推送使用更少的内存？

标签： git git-push

【解决方案1】：

我在卸载 Xcode 时遇到了这个问题。但是重新安装 XCode 并没有解决问题。

然后通过运行brew uninstall git修复它

【讨论】：

【解决方案2】：

Mac 用户

在我的例子中，我使用了 brew install git，它把 xcode 的 git 搞砸了

运行 brew uninstall git 解决了这个问题

【讨论】：

这似乎是个错误。来自 homebrew 的 Git 可能比来自 Xcode 的 Git更好。
是的，没错，但我认为这是因为安装了 2 个版本的 git
当 Big Sur 更新并且我从自制软件安装了 git 时，我遇到了这个问题。我必须重新安装 Xcode 命令行工具并删除自制 git 才能让它再次工作。

【解决方案3】：

我也遇到了这个错误。我的解决方案是增加服务器上的内存容量。这样做之后，错误就消失了。

【讨论】：

【解决方案4】：

有时，由于负载问题，企业 github 也会发生这种情况。我发现一个好方法是将克隆拆分为两个操作，这样可以减轻服务器上的负载。

首先，做一个浅克隆：git clone --depth 1 myRepo.git

接下来，进入克隆，并获取所有剩余历史以进行完整克隆：cd myRepo && git fetch --unshallow

如果你有一个不支持 --unshallow 标志的旧版本的 git，那么你可以改为使用 git fetch --depth=1000000 或其他适当大的数字。

这篇博文讨论了更多替代方案：https://blogs.atlassian.com/2014/05/handle-big-repositories-git/

【讨论】：

【解决方案5】：

我遇到了这个问题，但我的问题是由 Capfile 的问题引起的 - capistrano 已更新，并且更改未反映在 capfile 中。

正在将 capfile 更新为已修复的最新标准...

【讨论】：

【解决方案6】：

如果您使用 Dreamhost 服务器来保留裸存储库，您可以在本地添加和提交，然后将您的 .git 目录同步到 DH。完成后进入服务器的 [repository name].git/config 并将 core.bare 从 false 更改为 true。

如果你想在服务器上运行工作树，我不确定你会怎么做，我还没找到。

【讨论】：

【解决方案7】：

对于某些操作，Git 会占用大量内存，通过交换内存使用来提高磁盘或网络性能。（例如，请参阅关于 other SO question 的一些讨论。）

在这种情况下，我认为您和您的同事实际上是在进行不同的成本权衡：您正在使用专业管理的 Git 托管服务（例如 GitHub 或 BitBucket）进行权衡，以换取感知到的财务节省或其他一些便利（也许是部署？）。

如果您不习惯遵循您引用的 wiki/博客文章中的各种建议，我的建议是迁移到 GitHub 或 Bitbucket。（我认为这些帖子提供了技术上准确的解决方案，FWIW。）Bitbucket 提供免费的无限私人存储库，因此使用 Dreamhost 托管您的 Git 没有真正的成本理由。

如果您需要某种部署解决方案来配合托管，您可以设计一些东西来进行推送并自动将工作目录更新到 Dreamhost 以进行托管，而无需承担托管 Git 存储库的全部成本（以及所有你的历史）在 Dreamhost 上。

【讨论】：

谢谢埃米尔。您的答案（不是特别是 github，而是“离开 dreamhost”）几乎就是我发现的。我通过将 git repo 临时移动到试图进行推送的同一台服务器解决了这个问题（很麻烦），并且在收到客户支持电子邮件后，dreamhost 实际上确实增加了我的内存限制，这很酷。但显然他们已经安装了一个新的 procwatch 守护进程，这首先应该归咎于此。
感谢您的提示。我为我的虚拟机增加了内存，它解决了这个问题。