From: Junio C Hamano <gitster@pobox.com>
Date: Mon, 22 Dec 2014 21:22:45 GMT
Subject: Re: git update-ref --stdin : too many open files
Message-ID: <xmqqoaqv8jmi.fsf@gitster.dls.corp.google.com>
In-Reply-To: <54954E44.1080906@dachary.org>

Loic Dachary <loic@dachary.org> writes:

> Hi,
>
> Steps to reproduce:
>
> $ git --version
> git version 1.9.1
> $ wc -l /tmp/1
> 9090 /tmp/1
> $ head /tmp/1
> delete refs/pull/1/head
> create refs/heads/pull/1 86b715f346e52920ca7c9dfe65424eb9946ebd61
> delete refs/pull/1/merge
> create refs/merges/1 c0633abdc5311354c9729374e0ba25c97a89f69e
> ...
> $ ulimit -n
> 1024
> $ git update-ref --stdin < /tmp/1
> fatal: Unable to create
> /home/gitmirror/repositories/Ceph/ceph/refs/heads/pull/1917.lock': Too
> many open files
> $ head -20 /tmp/1 | git update-ref --stdin
> $ echo $?
> 0
>
> The workaround is to increase ulimit -n
>
> git update-ref --stdin should probably close some files.
>
> Cheers

Sounds like the recent "ref update in a transaction" issue to me.

Stefan, want to take a look?  I think we do need to keep the .lock
files without renaming while in transaction, but we do not have to
keep them open, so I suspect that a fix may be to split the commit
function into two (one to close but not rename, the other to
finalize by renaming) or something.

Also the version of transaction series we have queued seem to lock
these refs very late in the process, but as we discussed privately
a few weeks ago, we would want to move the lock much earlier, when
the first update is attempted.