git 2.0 git gc --auto does not work because kLIBC setsid() fails

[Steven Levine]

kLIBC's setsid() is stubbed to always fail. This prevents git gc from continuing.

[dmik]

What is it expected to do? Here it just ends w/o any output (as well as git 2.8 on Mac). Could you give more details and also provide a test repo (in zip)?

[dmik]

Steven, the new git RPM 2.11.0 is online. Please recheck this. Feel free to reopen If it still gives you any problem but please provide a ZIP with a test repo in such a case so that I could reproduce it.

[dryeo]

This still fails for me with some repositories that I've been pulling from for years. Unluckily my testcase zips to 162 MBs so can't imagine uploading it. I'll look at my oldest backup of it.
Note that IIRC, this worked with the bauxite release of git

[dryeo]

FFmpeg is one repository that seems to develop a lot of garbage. Perhaps doing a daily git pull will generate the automatic garbage collection for you.

[dmik]

Steven, the problem you are experiencing with setuid is due to a missing kLIBC user setup. This is a known problem and it's not only related to git — any application that uses setuid and friends will suffer from various problems if the Unix-like user is not set up properly. This worked for me well because I've always had the samba server installed (which performs Unix/kLIBC user setup at installation). Now we solved it in a general manner by providing a klusrmgr RPM package. Once installed, you should get rid of your setuid problem.

There is, however, another minor problem with the gc command. It creates pack files named like .tmp-XXX-YYY.pack and doesn't remove this .tmp-XXX prefix upon termination. Perhaps, a usual rename before close issue. I will look into it.

Dave, I will fix this .tmp-XXX problem and then try it on a huge GCC or Mozilla repo with a lot of separate objects to see if it works now.

[dmik]

Turns out that the reason for the above is a failed flush operation on TCP sockets during piping, just the same as the one in #146. So this is also resolved by a LIBCx fix ​from ​https://github.com/bitwiseworks/libcx/issues/31.

Also, git gc worked quite well with my gcc repo which had a hundred unpacked objects and several big pack files. It took 11 minutes, ate around 700M of RAM while running and created a single pack file of 1.6G in the end. I also tried our Mozilla GitHub repo too, it had a even more unpacked objects but it's smaller per se (we lack a lot of history) so completed in 7 minutes with a 300M resulting pack file. I'm more than happy with this.

Expect a new git and libcx RPM soon.