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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
