Ubuntu Linux git gc says error: failed to run repack

Question

I am reading other threads with similar titles but seems not related to me. I have a git repo in my local ubuntu box. The files I have is mysql dump I split into 2mb files each. When I git gc, this is the output:

git@pc:~/repos/x$ git gc
Counting objects: 17244, done.
Delta compression using up to 4 threads.
Killedssing objects:  90% (2491/2767)   
error: failed to run repack

Is there a way to trace what is causing? I already tried

git config --global pack.windowMemory "20m"
git config --global pack.packSizeLimit "20m"
git config --global pack.threads "1"

But this is the output

git@pc:~/repos/x$ git gc
Counting objects: 17244, done.
Killedssing objects:   3% (88/2767)   
error: failed to run repack

Edit

This worked for me:

git config --global pack.windowMemory "20m"
git config --global pack.packSizeLimit "20m"
git config --global pack.threads "4"
git config --global pack.window "2"
git config --global pack.depth "10"

It seems because I only have 256 ram vps. and other process already eating 100mb. I will try also to upgrade my vps because this config makes git gc and git clone very slow.

Edit Again After more investigation, it is because of the threads. I have 4 virtual cores assigned to my vps, and when I put the pack.threads "2" without the others, the problem went away.

I asked my provider to give me more ram but that did not help. Only when I configure the threads. Hope this help others

Answer 1

From your output, it looks like the process is being killed by an external process such as the Linux OOM Killer, or some other resource management process, during the delta compression stage. If you're running out of memory or disk space, then that gives you a logical place to start your investigation.

You might also consider running your process under strace. This will often tell you what the program was doing when it receives the signal, but may not always tell you who the signal sender actually was.

If strace fails you, the Git source currently has 12 references to sigaction(2), which you might be able to leverage to determine the signal sender by examining the siginfo_t struct. This would most likely require a core dump or an interactive debugger such as gdb.