1

I have my git bare repo initialized in remote server folder /home/bare/mygit.git

I've cloned this repo:

git clone user@ip.of.my.server:/home/bare/mygit.git .

Then I was working with project, doing commits/pushs, etc...

But today I noticed when I was doing a push this error:

user@host:/var/www/mygit (master)$ git push origin master
user@ip.of.my.server's password: 
Counting objects: 5, done.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 297 bytes, done.
Total 3 (delta 2), reused 0 (delta 0)
fatal: Unable to create '/home/bare/mygit.git/refs/heads/master.lock': Invalid argument
fatal: The remote end hung up unexpectedly
fatal: recursion detected in die handler

I searched this issue, but seems like mostly people have problem with a permissions. But in that case error looks different (like Permission denied or something).

Rights is ok, clonning/pulling/fetching is okay. No errors in log or something like that.

Ilia Shakitko
  • 1,417
  • 2
  • 18
  • 25
  • I think you have problem with permissions. Try doing chmod and chown on server side – forvaidya Sep 15 '13 at 15:10
  • @forvaidya I thought it was clear that I did it and re-check according to my post :) – Ilia Shakitko Sep 15 '13 at 16:17
  • 1
    @forvaidya: `EINVAL` is the "wrong" error code for a permissions issue (those should result in `EACCES`). What version of git is this (client and server both) and what file system do these repos live on? – torek Sep 15 '13 at 16:23
  • I also wonder if you tried to do `ssh user@ip.of.my.server touch /home/bare/mygit.git/refs/heads/master.lock` -- that would be *the* way to check permissions (don't forget to remove the file if `touch`ing succeeds. – kostix Sep 15 '13 at 16:24
  • @torek git version 1.7.9.5; ext4 – Ilia Shakitko Sep 15 '13 at 16:29
  • @IliaShakitko, do you have anything funky like SELinux enabled? The `open(2)` manpage on my Debian Wheezy system does not list `EINVAL` among the "expected" return codes, and only mention it could be returned by FS drivers not understanding the `O_DIRECT` flag, which Git's implementation of lock files does not use (it uses `O_RDWR | O_CREAT | O_EXCL`). – kostix Sep 15 '13 at 16:35
  • @kostix $: ssh root@ip.of.my.server touch /home/bare/mygit.git/refs/heads/master.lock root@ip.of.my.server's password: touch: setting times of `/home/bare/mygit.git/refs/heads/master.lock': No such file or directory – Ilia Shakitko Sep 15 '13 at 16:35
  • @kostix It is just fresh Ubuntu 12.04. Well, not fresh, but just used as a server for git repos. – Ilia Shakitko Sep 15 '13 at 16:36
  • @IliaShakitko, uhm, first, I hope you don't really use `root` to work with Git on the remote box, if you do, please stop. The next thing is that touch should have created the file if it doesn't exist. Another funky thing is that "setting times" message: I've never seen it say something like this on my GNU/Linux systems (since ca. 1997). You could try running `: >/home/bare/mygit.git/refs/heads/master.lock` to create the file (yes, `:` is a no-op command). By the way, `touch` I was referring to is a part of GNU coreutils. – kostix Sep 15 '13 at 16:39
  • I checked out a 1.7.9.5 version of git. `git grep 'recursion detected'` shows that this string does not appear anywhere in "normal" git. Perhaps Ubuntu modified git somehow? – torek Sep 15 '13 at 16:50
  • @torek, googling for this exact error message turns up a number of pages related to Git. Well, anyway, at this point I'd post to the *developers'* (main) mailing list (Ilia, see [this](https://gist.github.com/tfnico/4441562) for more info). – kostix Sep 15 '13 at 16:59
  • @kostix no, it is for check :) I tried your command: bash: /home/bare/mygit.git/refs/heads/master.lock: Invalid argument ... May be it is not a git related ? – Ilia Shakitko Sep 15 '13 at 17:17
  • @kostix: yes, it's in *current* git, but it is not in 1.7.9.5. (I could have put this more clearly.) – torek Sep 15 '13 at 17:43
  • Looks like I can't touch any file :\ – Ilia Shakitko Sep 15 '13 at 17:54
  • Of course it's not Git-related! The whole idea of testing is to know if you're able to create the files on your filesystem while Git itself is seemingly not able to do that. But are you sure you have run a correct command? I mean, exactly a colon followed by " less than sign followed by the file name? If yes, try to log in into the remote system and `cd` the whole path under scrutiny *one component at a time* (first `/` then `home` and so on)? Does this work? While in the final directory, does touching work? – kostix Sep 16 '13 at 07:28
  • @kostix I have already fixed this thing just with reboot. When I saw dmesg info and a lot of FS errors it became clear. Thank you guys for effort helping! – Ilia Shakitko Sep 16 '13 at 08:45

2 Answers2

1

It was not a git related issue. Eventually I was not able to create some of new files.

When I ran dmesg I saw a lot of errors from kernel. I decided to reboot server first and then dig deeper, but after server has been restarted issue has gone.

Thanks everyone for helping!

Ilia Shakitko
  • 1,417
  • 2
  • 18
  • 25
0

Note, with Git 2.14.x/2.15 (Q3 2017), that error message will be less frequent.

See commit 4ff0f01 (21 Aug 2017) by Michael Haggerty (mhagger).
(Merged by Junio C Hamano -- gitster -- in commit f2dd90f, 27 Aug 2017)

The code to acquire a lock on a reference (e.g. while accepting a push from a client) used to immediately fail when the reference is already locked.

Now it waits for a very short while and retries, which can make it succeed if the lock holder was holding it during a read-only operation.

More precisely:

refs: retry acquiring reference locks for 100ms

The philosophy of reference locking has been, "if another process is changing a reference, then whatever I'm trying to do to it will probably fail anyway because my old-SHA-1 value is probably no longer current".

But this argument falls down if the other process has locked the reference to do something that doesn't actually change the value of the reference, such as pack-refs or reflog expire.
There actually is a decent chance that a planned reference update will still be able to go through after the other process has released the lock.

So when trying to lock an individual reference (e.g., when creating "refs/heads/master.lock"), if it is already locked, then retry the lock acquisition for approximately 100 ms before giving up. This should eliminate some unnecessary lock conflicts without wasting a lot of time.

Add a configuration setting, core.filesRefLockTimeout, to allow this setting to be tweaked.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250