Willy, Am 14.10.20 um 00:14 schrieb Willy Tarreau: >>> [pid 11946] sendto(9, "GET >>> /git/haproxy.git/objects/pack/pack-4c6bfad2590afe3d5591d203ad9b3cf2da4aef97.pack >>> HTTP/1.1\r\nHost: git.haproxy.org\r\nRange: bytes=21680737-\r\nUser-Agent: >>> git/2.28.0\r\nAccept: */*\r\n\r\n", 181, MSG_NOSIGNAL, NULL, 0) = 181 >>> [...] >>> [pid 11946] recvfrom(9, "HTTP/1.1 416 Requested Range Not >>> Satisfiable\r\nserver: nginx\r\ndate: Tue, 13 Oct 2020 17:08:56 >>> GMT\r\ncontent-type: text/html\r\ncontent-length: 206\r\ncontent-range: >>> bytes */21680737\r\n\r\n<html>\r\n<head><title>416 Requested Range Not >>> Satisfiable</title></head>\r\n<body bgcolor=\"white\">\r\n<center><h1>416 >>> Requested Range Not >>> Satisfiable</h1></center>\r\n<hr><center>nginx</center>\r\n</body>\r\n</html>\r\n", >>> 16384, 0, NULL, NULL) = 385 > > Now I understand why, it's exactly the file's size: > > $ ls -l objects/pack/pack-4c6bfad2590afe3d5591d203ad9b3cf2da4aef97.pack > -r--r--r-- 1 christopher haproxy-stable 21680737 Oct 9 17:49 > objects/pack/pack-4c6bfad2590afe3d5591d203ad9b3cf2da4aef97.pack > > However I don't know why it's trying to fetch more of it, which is a good > reason for this to fail!
I assume the following happened: 1. git started downloading the packfile into a temporary file [0] 2. git finished the download (I got all the bytes). 3. I killed git before it was able to rename the temporary file. 4. When trying again git tries to resume the download [1]. 5. Because I already got the whole file git will send an invalid range. 6. nginx does not like it and sends a 416. 7. git hard fails instead of retrying without the 'Range' header and without taking the 'content-range' response into account. So the stuff happening in step (7) would IMO be a git bug. [0] https://github.com/git/git/blob/4f0a8be78499454eac3985b6e7e144b8376ab0a5/http.c#L2331 [1] https://github.com/git/git/blob/4f0a8be78499454eac3985b6e7e144b8376ab0a5/http.c#L2350-L2358 > I've just run git fsck and am seeing this: > > $ git fsck > Checking object directories: 100% (256/256), done. > Checking objects: 100% (84716/84716), done. > dangling commit 309200e7332312e4cd7bfe2d9b21d37a6da9a698 > > Christopher faced some permission issues the first time he tried to > publish his version, so I suspect that the issue is that one file > failed to be updated and that a pack is probably bad there. > > I've run a git gc and now git fsck is happy. Please try again! > I already copied my local repository to test out whether truncating works. I could fix the issue by truncating off the last byte, causing git to send a valid range: truncate -s 21680736 pack-4c6bfad2590afe3d5591d203ad9b3cf2da4aef97.pack.temp After that worked I did the same on my real repository and called `fsck` + `gc` to make sure I did not break anything. I believe the server side `git gc` would have fixed it as well, because the pack file in question is completely gone now. It was replaced by a single large pack :-) Best regards Tim Düsterhus
