On 22.12.2014 13:22, Junio C Hamano wrote: > Loic Dachary <loic@xxxxxxxxxxx> 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. Sounds reasonable. Though by closing the file we're giving up again a bit of safety. If we close the file everyone could tamper with the lock file. (Sure they are not supposed to touch it, but they could) > > 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. I'll look into that tomorrow. > -- > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html