threads / discuss / 23788

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

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

## tl;dr

8 messages between May 12, 2010 and Nov 27, 2015.

replies: 7people: 6as markdown or json

Robert Buck· May 12, 2010, 19:45 UTC · lore

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.

Chris Packham· May 13, 2010, 00:06 UTC · re: Robert Buck · lore

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

On Wed, May 12, 2010 at 12:45 PM, Robert Buck <buck.robert.j@gmail.com> wrote:
Show 23 quoted lines
> 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
Jonathan Nieder· May 13, 2010, 00:52 UTC · re: Robert Buck · lore

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

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
Robert Buck· May 13, 2010, 09:30 UTC · re: Jonathan Nieder · lore

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

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
Greg Troxel· May 13, 2010, 12:05 UTC · re: Robert Buck · lore

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

Robert Buck <buck.robert.j@gmail.com> writes:
Show 5 quoted lines
> 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.
Andreas Schwab· May 13, 2010, 13:22 UTC · re: Jonathan Nieder · lore

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

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."
Jonathan Nieder· May 13, 2010, 13:56 UTC · re: Andreas Schwab · lore

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

Andreas Schwab wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:
Show 5 quoted lines
>> 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 */
DavidLeeCrites· Nov 27, 2015, 21:37 UTC · re: Jonathan Nieder · lore

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

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.

← back to recent threads