Bug 397524

Comment 1 Eclipse Webmaster 2013-01-07 10:39:08 EST

I've taken a look in the Gerrit logs and I don't see any errors that appear related to this.

It looks like the hudson plugin voted no, could that be what's blocking the push?

-M.

Comment 2 Alexander Kurtakov 2013-01-07 10:43:25 EST

There is also:
https://git.eclipse.org/r/#/c/9499/ and if you look at the https://hudson.eclipse.org/sandbox/job/linuxtools/884/console it fails on fetching that's what make me thought there is a problem with either gerrit or the git repo.

Comment 3 Eclipse Webmaster 2013-01-07 11:22:28 EST

I tried cloning the repo directly and got:

hudsonbuild@sandbox:> git clone git://git.eclipse.org/gitroot/linuxtools/org.eclipse.linuxtools.git
Initialized empty Git repository in /tmp/t/org.eclipse.linuxtools/.git/
remote: fatal: object 9125f76f5e0d50625b5b1e5f0d49cd1683588cbc is corrupted
remote: aborting due to possible repository corruption on the remote side.
fatal: early EOF
fatal: index-pack failed

But when I looked at the repo I couldn't find that object.  Then just for grins I did a local checkout on git.eclipse.org via the file:/// URL and that was fine.  So I ran the git garbage collector and now the repo checks out ok on the sandbox.

-M.

Comment 4 Denis Roy 2013-01-07 14:59:56 EST

Since jGit does not run gc, we'll need to run gc on repos periodically to prevent these problems where Too Many Open Files prevent git operations

Comment 5 Denis Roy 2013-02-28 09:18:50 EST

We could/should do this as the gerrit user to avoid having permissions issues.  We could walk /gitroot and find all repos that belong to gerrit, then step into them ang git gc.

Comment 6 Denis Roy 2013-02-28 11:16:21 EST

git gc will be run once a month on all gerrit-owned repos.

Comment 7 Denis Roy 2013-02-28 11:17:17 EST

For our own notes, the job runs on the gerrit server itself, and is essentually just a one-liner:

for i in $(find . -maxdepth 3 -type d -name '*.git' -user gerrit); do cd "$i" && git gc && cd -; done