found 609405 git/1:1.7.5.1-1 clone 609406 -1 retitle -1 git-daemon-run: copes poorly when one address is in use tags 609405 + patch quit
Hi, Daniel Kahn Gillmor wrote: > This is easily fixed by adding --reuseaddr to the command line in > /etc/sv/git-daemon/run: [...] > I've tested and it works fine, even if outstanding connections are > being handled by previous instances of git. Yep. IIUC then TCP's behavior without the SO_REUSEADDR flag is supposed to protect against an existing client having the connection cut off and a new server instance confusingly picking up where it left off. If git-daemon is killed while upload-pack stays alive, there's no risk of that. > Without this flag, if outstanding connections were bound to the daemon > on both IPv4 and IPv6, then /var/log/git-daemon/current fills with > messages like this as the process is restarted every second: > > 2011-05-19_04:53:51.90733 git-daemon starting. > 2011-05-19_04:53:51.91214 fatal: unable to allocate any listen sockets on > port 9418 > 2011-05-19_04:53:52.91799 git-daemon starting. > 2011-05-19_04:53:52.92665 fatal: unable to allocate any listen sockets on > port 9418 That's not as bad as when an outstanding connection was bound on only one protocol (git-daemon contentedly listens on the other and there is no one minding the first phone!). In the "unable to allocate any listen sockets" scenario, unlike the other, eventually git-daemon wakes up again and listens on both addresses. Though both are bad. I wish the TCP stack would keep track of busy sockets instead of busy ports after a process exits, to address this problem without disabling the TIME-WAIT facility completely. But I'm probably missing something, and this is enough of an edge case that it's not worth the fuss, so... > This would be a pretty useful fix; i know several people who were > frustrated by this intermittent-seeming problem. Thanks; will apply for the next upload. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
