Wincent Colaiuta schrieb:
> El 6/2/2008, a las 10:40, Johannes Sixt escribió:
>
>>> This fails with the "remote end hung up unexpectedly" error:
>>>
>>> # /usr/local/bin/git-daemon --inetd --base-path=/blah -- /blah
>>
>> If you run this from the command line, you can't expect it to do anything
>> useful: It communicates with the client via stdin and stdout.
>
> Strangely, it worked with 1.5.3.8. But I just tried to reproduce it and
> now I can't, so there must have been some error in my procedure. Doh.
> The bizarre thing is that in preparing these emails I tested it at least
> twice, which means I must have made the exact same mistake at least
> twice...
>
>> Which makes me think that you xinetd doesn't pass a PATH to git-daemon
>> that includes /usr/local/bin. Add this to your /etc/xinetd.d/git:
>>
>> env = PATH=/bin:/usr/bin:/usr/local/bin
>>
>> (not tested).
>
> That works. Thanks.
>
> It's an acceptable workaround (the other is installing /usr instead of
> /usr/local). Seeing as it worked in 1.5.3.8, does this qualify as
> breakage, or should we not worry about it?
Does this patch make a difference? (It does for me.)
diff --git a/daemon.c b/daemon.c
index 41a60af..c99285e 100644
--- a/daemon.c
+++ b/daemon.c
@@ -1026,6 +1026,7 @@ int main(int argc, char **argv)
struct group *group;
gid_t gid = 0;
int i;
+ char *cmd_path = strdup(argv[0]), *slash;
/* Without this we cannot rely on waitpid() to tell
* what happened to our children.
@@ -1184,6 +1185,13 @@ int main(int argc, char **argv)
if (strict_paths && (!ok_paths || !*ok_paths))
die("option --strict-paths requires a whitelist");
+ slash = strrchr(cmd_path, '/');
+ if (slash) {
+ *slash = 0;
+ setup_path(cmd_path);
+ }
+ free(cmd_path);
+
if (inetd_mode) {
struct sockaddr_storage ss;
struct sockaddr *peer = (struct sockaddr *)&ss;
-
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
