Re: git-daemon breakage in 1.5.4

From: Wincent Colaiuta <win@wincent.com>
Date: Feb 5, 2008, 19:28 UTC
Message-ID: <A8C3C239-8352-4219-AC19-12280F536A8A@wincent.com>
In-Reply-To: <AC76050F-D727-4952-A528-55827D5B707B@srparish.net>

El 5/2/2008, a las 18:49, Scott Parish escribió:

Show 27 quoted lines

>
> 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