From: Wincent Colaiuta Date: Tue, 05 Feb 2008 19:28:06 GMT Subject: Re: git-daemon breakage in 1.5.4 Message-ID: In-Reply-To: El 5/2/2008, a las 18:49, Scott Parish escribió: > > On Feb 5, 2008, at 7:39 AM, Wincent Colaiuta wrote: > >> I just noticed that my copy of git-daemon running from xinetd on >> Red Hat Enterprise Linux 3 has been broken since upgrading to 1.5.4. >> >> Nothing printed to the logs on the server side: it simply hangs up. >> By connecting via telnet I've confirmed that git-daemon is running >> and does accept the initial connection. >> >> The verdict according to "git bisect" is that >> 511707d42b3b3e57d9623493092590546ffeae80 is first bad commit: >> >> Does that look like it might be the issue? Anyone familiar with >> that part of the code care to comment? Any other info I can provide >> that might shed light on the problem? > > Prior to that patch, execv_git_cmd called execve in a loop to find > the command to run. The above patch added a setup_path() api to > setup PATH and then called execvp() to do the looping. The problem > in this case is that daemon is never calling setup_path(), so the > builtin path (among others) aren't getting included in the PATH. > > You should see the problem go away if you run "git daemon" instead > of "git-daemon". Given that directly using the dash versions of the > commands are discouraged, it probably wouldn't hurt doing this > anyway. I'll work up a patch later today. Interesting. I use the dashless form on my desktop but I hadn't thought about using it on the server; I'd think that explicitly providing the absolute path should always work anyway (at least, it's meant to, isn't it?). In any case I did a little more investigation. As I mentioned in my original email, the daemon is being launched by xinetd. The xinetd configuration launches it with the full path to the executable; eg: /usr/local/bin/git-daemon --inetd --base-path=/blah -- /blah Changing that to: /usr/local/bin/git daemon --inetd --base-path=/blah -- /blah We still get the failure. But dropping the --inetd flag and launching the daemon manually it works both as: /usr/local/bin/git daemon --inetd --base-path=/blah -- /blah And: /usr/local/bin/git-daemon --inetd --base-path=/blah -- /blah So there's some kind of funky interaction going on. On seeing your patch come up in the "git bisect" run I wondered what kind of interaction might be happening with the PATH (I imagine the PATH environment inherited by processes that xinetd launches must be pretty anemic), but seeing as I can reproduce the problem from the command line (with a well-stocked PATH) that doesn't seem to be the problem. Cheers, Wincent