[remote rejected] master -> master (n/a (unpacker error))

[remote rejected] master -> master (n/a (unpacker error))

[Robert Buck]

Today, just after someone else committed to my public repository I
started getting errors. Until then Git worked great.

Does anyone know what is going on here? Are there particular versions
of Git with known issues around this?


uname@hostname:~/dev/workspaces/scm-evaluations/welcome.git/install/git-config$
git push
Counting objects: 7, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 922 bytes, done.
Total 4 (delta 0), reused 4 (delta 0)
error: unable to create temporary sha1 filename ./objects/e6: File
exists

fatal: failed to write object
error: unpack failed: unpacker exited with error code
To ssh://git.projectbedrock.com/var/cache/git/welcome.git
 ! [remote rejected] master -> master (n/a (unpacker error))
error: failed to push some refs to
'ssh://git.projectbedrock.com/var/cache/git/welcome.git'


As an aside, where the heck is the git bug tracker? I've searched, and
searched, and ... All I found is a Debian tracking system, which
appears to have no full text search capabilities.

Re: [remote rejected] master -> master (n/a (unpacker error))

[Chris Packham]

On Wed, May 12, 2010 at 12:45 PM, Robert Buck <buck.robert.j@gmail.com> wrote:
> Today, just after someone else committed to my public repository I
> started getting errors. Until then Git worked great.
>
> Does anyone know what is going on here? Are there particular versions
> of Git with known issues around this?
>
>
> uname@hostname:~/dev/workspaces/scm-evaluations/welcome.git/install/git-config$
> git push
> Counting objects: 7, done.
> Delta compression using up to 2 threads.
> Compressing objects: 100% (4/4), done.
> Writing objects: 100% (4/4), 922 bytes, done.
> Total 4 (delta 0), reused 4 (delta 0)
> error: unable to create temporary sha1 filename ./objects/e6: File
> exists
>
> fatal: failed to write object
> error: unpack failed: unpacker exited with error code
> To ssh://git.projectbedrock.com/var/cache/git/welcome.git
>  ! [remote rejected] master -> master (n/a (unpacker error))
> error: failed to push some refs to
> 'ssh://git.projectbedrock.com/var/cache/git/welcome.git'

This is probably a permissions problem on the server. We use git over
ssh at $dayjob and we need to make sure everyone who pushes to a
repository on the server is a member of the same group and that the
repositories are created with "git init --shared" otherwise we run
into problems like this. Its not too much of an issue for us because
we have a maintainer model and the maintainers generally have the
right permissions and don't change frequently.

I think the "shared" part is probably the problem in this case because
you can both obviously create files on the server. Rhe problem appears
to be when one of you needs to update a file (or directory) the other
created.

To fix your current problem you'll just need to ssh into that server
and find the  welcome.git/objects directory and check the permissions
on the "e6" directory and its contents. You will keep running into
this problem until the permissions/sharing is sorted. Theres probably
a config variable which dictates the permissions to use when creating
objects on the server which is changed when you pass the "--shared"
option to "git init", but I'm not sure what its is (I see some man
pages in your future).

> As an aside, where the heck is the git bug tracker? I've searched, and
> searched, and ... All I found is a Debian tracking system, which
> appears to have no full text search capabilities.

You're looking at it bugs, patches, questions all go to this mailing
list. The archive on gmane[1] is conveniently search-able.

[1] http://news.gmane.org/gmane.comp.version-control.git

Re: [remote rejected] master -> master (n/a (unpacker error))

[Jonathan Nieder]

Hi Robert,

Robert Buck wrote:

> error: unable to create temporary sha1 filename ./objects/e6: File exists

Yeah, this error message is not so great.

The relevant code is in sha1_file.c.

	fd = create_tmpfile(tmpfile, sizeof(tmpfile), filename);
	while (fd < 0 && errno == EMFILE && unuse_one_window(packed_git, -1))
		fd = create_tmpfile(tmpfile, sizeof(tmpfile), filename);
	if (fd < 0) {
		if (errno == EACCES)
			return error("insufficient permission for adding an object to repository database %s\n", get_object_directory());
		else
			return error("unable to create temporary sha1 filename %s: %s\n", tmpfile, strerror(errno));
	}

create_tmpfile() creates a filename of the form
./objects/e6/tmp_obj_<random letters> and tries to open that file.
The random value is based on the current time and the process ID of
the current process.  If the file exists, it tries again with another
collection of random letters, up to 16384 times.

In your case, all 16384 trials yielded the same result: file already
existed.  As a workaround, I’d suggest

 rm -f .git/objects/??/tmp_obj_*

but it might be nice to get a listing with "ls -lR .git/objects" first
for post-mortem analysis.

And presumably the directory filled with temporary files that could
not be renamed to a proper name for some reason.  Probably a permissions
problem, as Chris suggested.

-- 8< --
Subject: write_loose_object(): improve error message for some mkstemp failures

If the .git/objects/ab/ directory fills up with tmp_obj_ files, the
result is a cryptic error:

  error: unable to create temporary sha1 filename ./objects/e6: File exists

Replace it with the slightly less cryptic

  error: cannot write temporary file under ./objects/e6: all the good filenames are taken

Reported-by: Robert Buck <buck.robert.j@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
> As an aside, where the heck is the git bug tracker?

Here is an answer from the last time it came up[1]:

 See http://thread.gmane.org/gmane.comp.version-control.git/136500

 Short answer: the usual method is to report bugs to the list,
 preferably with a patch for t/ or even better, a fix. 

> I've searched, and
> searched, and ... All I found is a Debian tracking system, which
> appears to have no full text search capabilities.

http://merkel.debian.org/~don/cgi/search.cgi
http://www.google.com/search?q=site:bugs.debian.org+"Package:+git"+"file+exists"

Thoughts?  Improvements?
Jonathan

[1] http://thread.gmane.org/gmane.linux.debian.devel.bugs.general/680778/focus=141598

 sha1_file.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/sha1_file.c b/sha1_file.c
index 28c056e..a2aa301 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -2288,6 +2288,10 @@ static int write_loose_object(const unsigned char *sha1, char *hdr, int hdrlen,
 	if (fd < 0) {
 		if (errno == EACCES)
 			return error("insufficient permission for adding an object to repository database %s\n", get_object_directory());
+		else if (errno == EEXIST)
+			return error("cannot write temporary file under %s: "
+			             "all the good filenames are taken\n",
+			             tmpfile);
 		else
 			return error("unable to create temporary sha1 filename %s: %s\n", tmpfile, strerror(errno));
 	}
-- 
1.7.1

Re: [remote rejected] master -> master (n/a (unpacker error))

[Robert Buck]

Thanks.

Yes, the repository is shared by several people, and in geographically
different locations, ssh-ing to the same host, under different groups.
So your recommendation would be to use --shared. But this won't work
so well out in the wild will it? Meaning, what if people's accounts
are NOT under the same group that is?

It would sound to me like in general, when one goes to production with
a git environment that some sort of chrooted account is preferable if
not highly recommended?

Bob

Re: [remote rejected] master -> master (n/a (unpacker error))

[Greg Troxel]

[-- Attachment #1: Type: text/plain, Size: 1145 bytes --]


Robert Buck <buck.robert.j@gmail.com> writes:

> Yes, the repository is shared by several people, and in geographically
> different locations, ssh-ing to the same host, under different groups.
> So your recommendation would be to use --shared. But this won't work
> so well out in the wild will it? Meaning, what if people's accounts
> are NOT under the same group that is?

Git simply rides on filesystem permissions.  So you choose a group to
control access to the repository, chgrp -R the repo to that group, and
config shared=0660.  Then you put people in the group to give them
access; it doesn't have to be their primary gid.  I don't follow your
objection; you seem to want to use groups to control access yet not set
up a group for the repo.

On some systems (e.g. BSD), directories automatically inherit the parent
dir's group.  On others, you need setgid bit.  I have the impression
that git will deal with this all correctly if you simply have
"sharedrepository = 0660" under [core] in config; I would expect it to
chgrp new files/dirs as needed to match the repo dir's group.

I don't see how chroot would change the issues above.


[-- Attachment #2: Type: application/pgp-signature, Size: 194 bytes --]

Re: [remote rejected] master -> master (n/a (unpacker error))

[Andreas Schwab]

Jonathan Nieder <jrnieder@gmail.com> writes:

> In your case, all 16384 trials yielded the same result: file already
> existed.

IMHO it is much more likely that a race happened between two git
processes each wanting to create the .git/objects/e6 directory.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [remote rejected] master -> master (n/a (unpacker error))

[Jonathan Nieder]

Andreas Schwab wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:

>> In your case, all 16384 trials yielded the same result: file already
>> existed.
>
> IMHO it is much more likely that a race happened between two git
> processes each wanting to create the .git/objects/e6 directory.

Good catch.  But wasn’t the problem reproducible?

In any event, that such a race is possible is not so nice.  Here’s
a naïve fix; it does not address other races, such as hash-object
versus prune.  Maybe git ought to acquire some sort of lock before
writing to the object dir in a shared clone.

diff --git a/sha1_file.c b/sha1_file.c
index bbb819f..d305e53 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -2244,6 +2244,13 @@ static inline int directory_size(const char *filename)
 	return s - filename + 1;
 }
 
+static int ensure_directory_exists(const char *dir)
+{
+	if (mkdir(dir, 0777) && errno != EEXIST)
+		return -1;
+	return adjust_shared_perm(dir);
+}
+
 /*
  * This creates a temporary file in the same directory as the final
  * 'filename'
@@ -2266,7 +2273,7 @@ static int create_tmpfile(char *buffer, size_t bufsiz, const char *filename)
 		/* Make sure the directory exists */
 		memcpy(buffer, filename, dirlen);
 		buffer[dirlen-1] = 0;
-		if (mkdir(buffer, 0777) || adjust_shared_perm(buffer))
+		if (ensure_directory_exists(buffer))
 			return -1;
 
 		/* Try again */
-- 

Re: [remote rejected] master -> master (n/a (unpacker error))

[DavidLeeCrites]

I am getting the same kinds of errors, but the resolutions offered here did
not work. After using the ideas (that there was a tmp_* file I did not have
perms to write to, I started doing some global searches. 

One such was this (from inside .git/objects):
# ls -alR | grep tmp
ls: reading directory ./97: Input/output error

So I tried:
# cd 97
# ls -l
ls: reading directory .: Input/output error
total 0K

To fix it, I did this:
# cd ..
# rm -fr ./97

The git push then worked fine.

I'll add a few more pieces to the puzzle. I have some of my git repositories
on a USB drive (the ones I get this issue with). I move it from system to
system. When git works, it works okay. But this irritant hits me about once
a week. My previous solution was to blow away the repo and rebuild it
(something suggested several times here). This is the first time I have
found a workaround.

These are my private repositories that hold my private files. I have a
github account I use for my public ones, plus my company has both a public
github and their own privately hosted github. So the same exact computer
systems (laptops and VMs) use all four with impunity. Almost all of them are
linux based -- a mix of CentOS 7.x and Linux Mint 14.x; all using git
v1.9.1. The one exception is osx. Thus the (brand new Toshiba 4T) USB drive
is built with the exFAT filesystem. When it works, it works okay; but as I
said, one of my dozen git repos will fail like this on a weekly basis. 

None of the items in my dockerhub or artifactory fail, nor do my rsnapshot
processes, or VLC/Banshee, etc. 

I've pretty much isolated it down to git. It is the ONLY app that fails. I
have noted in the past few months that the frequency of errors tells me I
cannot be using the USB drive for anything else while git is accessing the
drive. [mac specific: it is better when I use a USB 2.0 hub to plug the
drive in; we all are probably aware that the mac seems to have more issues
with USB 3.0...]

Anyway, I figured I'd toss this into the mix. Since it only happens once a
week or so, I cannot guarantee I'll have an update soon, but if someone is
curious, ping me, and I'll let you know when it happens again.

DL





--
View this message in context: http://git.661346.n2.nabble.com/remote-rejected-master-master-n-a-unpacker-error-tp5043046p7643470.html
Sent from the git mailing list archive at Nabble.com.