解决git push时卡在total

发表于 更新于 分类于 阅读次数： 本文字数： 2.4k 阅读时长 ≈ 2 分钟

整个事情的发生是这样的：有段时间没更新文章了，突然最近有点东西需要记录分享下，就写了篇文章，依旧之前的老套路调教下 hexo，啊呸，依旧推送到云服务器上的 git 仓库，这次，我挂彩了。在我正装待发时（git push）,出现了意想不到的情况：它不工作了，它定在了"Total 5 (delta 2), reused 0 (delta 0), pack-reused 0"！欲知后事如何，请啃完全文。

分析问题

直接无脑上搜索了，搜了半天，出来个这个：

1
git config --local sendpack.sideband false

抱着死马当活马医的心态，直接在项目根目录下上此命令。很平静啊，没有意思反应，我停留了片刻，这是正常现象，git 的配置设置，命令敲完不输出提示内容。当我再次git push，哇，情况好转了，至少不会卡在Total 5 (delta 2), reused 0 (delta 0), pack-reused 0了。此时，控制台抛出了错误提示，看到希望了。

错误提示内容：

1
error: remote unpack failed: unable to create temporary object directory To 120.48.58.244:/home/gitRepo/yujian.git

很好，简单翻译下：无法常见临时目录。很明显嘛，这啥……看不懂！又一次无脑上搜索，找啊找啊找解决方法。边找边想，脑袋里闪现 2 个思路：权限、存储限制。

权限这块，之前都能正常推送到远程仓库，这个思路直接砍掉。

存储，联想到 g 推送是报错内容：unable to create temporary object directory，这不就是版本答案吗。

我悟了！云服务器存储不够了，我飞快的调出平时不常用的 Xshell 7，麻了，还要更新才能用，带着激动的心情，更新好后进入云服务系统 linux debian，直接查水表，看看是不是系统剩余存储不够了。好家伙，我直接好家伙，居然被榨的一点剩余空间都没有了……呜呜呜。

1
df -h

image-20231126203833416

4e77750f5a92165a888db911018d790

b152c9c27e5362b9036721b697c0095

df70a99b5f581871edcac29f008a450

/etc/coredumps

目录 /etc/coredumps 通常用于存放核心转储文件（core dumps）的配置文件，而不是存放核心转储文件本身的目录。核心转储文件是在程序崩溃时生成的二进制文件，它包含了程序在崩溃时的内存和寄存器状态等信息，有助于开发人员分析崩溃原因。

如果你发现 /etc/coredumps 下存放的是核心转储文件而不是配置文件，那么这可能是一个误操作或者系统异常的结果。在正常情况下，核心转储文件通常存放在运行程序的工作目录（或其他指定的目录）中。

请在执行删除操作之前，确保你理解这些文件的作用以及删除可能产生的影响。如果你不确定是否可以删除 /etc/coredumps 目录中的文件，建议先备份这个目录或者咨询系统管理员。

我又查看了下/etc/coredumps目录中的文件，纠结了一会儿，果断删除，大不了重来过（重装系统，最坏的打算，提前备份好重要文件及配置）。

删除/etc/coredumps

rm 直接干

1
rm -f /etc/coredumps/*

出错误了：

1
-bash: /bin/rm: Argument list too long

这错误是因为命令行参数列表太长，导致 rm 命令无法处理这么多文件。有几种方法可以解决这个问题：

使用 find 命令删除

1
find coredumps/ -type f -exec rm -f {} \;

这个命令会使用 find 来查找 coredumps/ 目录下的所有文件，并逐一删除它们。

使用 xargs

1
find coredumps/ -type f | xargs rm -f

这个命令使用 find 找到文件，然后将它们传递给 xargs，xargs 再将它们传递给 rm。

使用 find 的 -delete 选项

1
find coredumps/ -type f -delete

这个命令直接在 find 中使用 -delete 选项，而不是使用 -exec 来调用 rm。

这三种方法都可以避免命令行参数列表过长的问题。请根据你的需求选择其中一种。在运行这些命令之前，请确保你确实想要删除这些文件，因为删除后是无法恢复的。

最终，选择了第一种，就看它顺眼：

1
find coredumps/ -type f -exec rm -f {} \;

文件 list 太多了，此时等待了下 5 分钟左右，成功删除/etc/coredumps目录中的所有文件。

限制 core dump file 大小

在 Linux 系统上，我们可以使用 ulimit 命令来设置核心转储文件（core dump file）的大小限制。以下是一些步骤和示例，演示如何设置核心转储文件的大小限制。

通过修改 /etc/security/limits.conf

  1. 打开 /etc/security/limits.conf 文件。

    这里我用的 xftp 7，直接找到文件编辑保存。

  2. 在文件的末尾添加以下行，表示设置所有用户的核心转储文件大小限制；

    1
    *    soft    core    102400

    102400：表示 100MB，1MB=1024KB

  3. 如果希望核心转储文件被完全禁用，直接：

    1
    *    soft    core    0

  4. 验证设置是否生效。

    使用 ulimit -c 再次检查核心转储文件大小限制，确保它已经被正确设置。

  5. 重新登录或重新启动云服务器的 linux debian，以使更改生效。

这样，我们就可以通过 ulimit 命令或修改 /etc/security/limits.conf 文件来设置核心转储文件的大小限制。

最后

git push走一遍，OK，成功了！我们成功啦！感谢看到这里的伙伴们，我们下篇文章见。

相关链接

[1] git push 一直卡住

[2] 【Git 学习】解决 git push 操作的时候出错，提示 error: unpack failed: unable to create temporary object directory

[3] 浅谈 linux 中/dev/vda1 文件满了解决方法