{"thread":{"id":"11899","subject":"git-daemon breakage in 1.5.4","startedAt":"2008-02-05T15:39:00Z","lastAt":"2008-02-06T12:02:00Z","messageCount":13,"participants":["Wincent Colaiuta","Junio C Hamano","Scott Parish","Johannes Sixt","Adam Piatyszek"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"67530","messageId":"BE051395-F4E1-428B-89B3-5D01BEA42C71@wincent.com","threadId":"11899","inReplyTo":null,"subject":"git-daemon breakage in 1.5.4","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2008-02-05T15:39:00Z","receivedAt":"2008-02-05T15:39:00Z","isPatch":false,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"I just noticed that my copy of git-daemon running from xinetd on Red  \nHat Enterprise Linux 3 has been broken since upgrading to 1.5.4.\n\nOn the client side this is what you see (\"git clone\" used in the  \nexample but you get the same issue with \"git ls-remote\"):\n\n   git clone git://git.wincent.com/wikitext.git\n   Initialized empty Git repository in /tmp/wikitext/.git/\n   fatal: The remote end hung up unexpectedly\n   fetch-pack from 'git://git.wincent.com/wikitext.git' failed.\n\nNothing printed to the logs on the server side: it simply hangs up. By  \nconnecting via telnet I've confirmed that git-daemon is running and  \ndoes accept the initial connection.\n\nThe verdict according to \"git bisect\" is that  \n511707d42b3b3e57d9623493092590546ffeae80 is first bad commit:\n\ncommit 511707d42b3b3e57d9623493092590546ffeae80\nAuthor: Scott R Parish <srp@srparish.net>\nDate:   Sun Oct 28 04:17:20 2007 -0700\n\n     use only the $PATH for exec'ing git commands\n\n     We need to correctly set up $PATH for non-c based git commands.\n     Since we already do this, we can just use that $PATH and execvp,\n     instead of looping over the paths with execve.\n\n     This patch adds a setup_path() function to exec_cmd.c, which sets\n     the $PATH order correctly for our search order. execv_git_cmd() is\n     stripped down to setting up argv and calling execvp(). git.c's\n     main() only only needs to call setup_path().\n\n     Signed-off-by: Scott R Parish <srp@srparish.net>\n     Signed-off-by: Junio C Hamano <gitster@pobox.com>\n\n:100644 100644 33b17a6b45699e73a9b58f0ff02135eae913b47d  \n2d0a75851284392aa8ae44bc486df6a034d0af13 M\texec_cmd.c\n:100644 100644 da99287552b5d3eafc495f998a936df81ee3f8b9  \na892355c8212298130fb3925c6cba352ed6999b6 M\texec_cmd.h\n:100644 100644 c7cabf5f348118f318d7c3abe55853b576869a98  \n4e10581101c26444da5c7c44a80219b11607705b M\tgit.c\n\nDoes that look like it might be the issue? Anyone familiar with that  \npart of the code care to comment? Any other info I can provide that  \nmight shed light on the problem?\n\nCheers,\nWincent\n"},{"id":"67608","messageId":"AC76050F-D727-4952-A528-55827D5B707B@srparish.net","threadId":"11899","inReplyTo":"BE051395-F4E1-428B-89B3-5D01BEA42C71@wincent.com","subject":"Re: git-daemon breakage in 1.5.4","fromName":"Scott Parish","fromEmail":"srp@srparish.net","sentAt":"2008-02-05T17:49:22Z","receivedAt":"2008-02-05T17:49:22Z","isPatch":false,"sender":{"key":"srp@srparish.net","avatar":"https://gravatar.com/avatar/870e5b6fc4f710cf4db5684bd9af7f2cee5734b3dab3209b13e00cf64f6c9f0e?d=mp&s=160"},"body":"\nOn Feb 5, 2008, at 7:39 AM, Wincent Colaiuta wrote:\n\n> I just noticed that my copy of git-daemon running from xinetd on  \n> Red Hat Enterprise Linux 3 has been broken since upgrading to 1.5.4.\n>\n> Nothing printed to the logs on the server side: it simply hangs up.  \n> By connecting via telnet I've confirmed that git-daemon is running  \n> and does accept the initial connection.\n>\n> The verdict according to \"git bisect\" is that  \n> 511707d42b3b3e57d9623493092590546ffeae80 is first bad commit:\n>\n> Does that look like it might be the issue? Anyone familiar with  \n> that part of the code care to comment? Any other info I can provide  \n> that might shed light on the problem?\n\nPrior to that patch, execv_git_cmd called execve in a loop to find  \nthe command to run. The above patch added a setup_path() api to setup  \nPATH and then called execvp() to do the looping. The problem in this  \ncase is that daemon is never calling setup_path(), so the builtin  \npath (among others) aren't getting included in the PATH.\n\nYou should see the problem go away if you run \"git daemon\" instead of  \n\"git-daemon\". Given that directly using the dash versions of the  \ncommands are discouraged, it probably wouldn't hurt doing this  \nanyway. I'll work up a patch later today.\n\nsRp\n"},{"id":"67540","messageId":"A8C3C239-8352-4219-AC19-12280F536A8A@wincent.com","threadId":"11899","inReplyTo":"AC76050F-D727-4952-A528-55827D5B707B@srparish.net","subject":"Re: git-daemon breakage in 1.5.4","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2008-02-05T19:28:06Z","receivedAt":"2008-02-05T19:28:06Z","isPatch":false,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"\nEl 5/2/2008, a las 18:49, Scott Parish escribió:\n\n>\n> On Feb 5, 2008, at 7:39 AM, Wincent Colaiuta wrote:\n>\n>> I just noticed that my copy of git-daemon running from xinetd on  \n>> Red Hat Enterprise Linux 3 has been broken since upgrading to 1.5.4.\n>>\n>> Nothing printed to the logs on the server side: it simply hangs up.  \n>> By connecting via telnet I've confirmed that git-daemon is running  \n>> and does accept the initial connection.\n>>\n>> The verdict according to \"git bisect\" is that  \n>> 511707d42b3b3e57d9623493092590546ffeae80 is first bad commit:\n>>\n>> Does that look like it might be the issue? Anyone familiar with  \n>> that part of the code care to comment? Any other info I can provide  \n>> that might shed light on the problem?\n>\n> Prior to that patch, execv_git_cmd called execve in a loop to find  \n> the command to run. The above patch added a setup_path() api to  \n> setup PATH and then called execvp() to do the looping. The problem  \n> in this case is that daemon is never calling setup_path(), so the  \n> builtin path (among others) aren't getting included in the PATH.\n>\n> You should see the problem go away if you run \"git daemon\" instead  \n> of \"git-daemon\". Given that directly using the dash versions of the  \n> commands are discouraged, it probably wouldn't hurt doing this  \n> anyway. I'll work up a patch later today.\n\nInteresting. I use the dashless form on my desktop but I hadn't  \nthought about using it on the server; I'd think that explicitly  \nproviding the absolute path should always work anyway (at least, it's  \nmeant to, isn't it?).\n\nIn any case I did a little more investigation.\n\nAs I mentioned in my original email, the daemon is being launched by  \nxinetd. The xinetd configuration launches it with the full path to the  \nexecutable; eg:\n\n   /usr/local/bin/git-daemon --inetd --base-path=/blah -- /blah\n\nChanging that to:\n\n   /usr/local/bin/git daemon --inetd --base-path=/blah -- /blah\n\nWe still get the failure.\n\nBut dropping the --inetd flag and launching the daemon manually it  \nworks both as:\n\n   /usr/local/bin/git daemon --inetd --base-path=/blah -- /blah\n\nAnd:\n\n   /usr/local/bin/git-daemon --inetd --base-path=/blah -- /blah\n\nSo there's some kind of funky interaction going on. On seeing your  \npatch come up in the \"git bisect\" run I wondered what kind of  \ninteraction might be happening with the PATH (I imagine the PATH  \nenvironment inherited by processes that xinetd launches must be pretty  \nanemic), but seeing as I can reproduce the problem from the command  \nline (with a well-stocked PATH) that doesn't seem to be the problem.\n\nCheers,\nWincent\n"},{"id":"67543","messageId":"7vr6fr9noj.fsf@gitster.siamese.dyndns.org","threadId":"11899","inReplyTo":"BE051395-F4E1-428B-89B3-5D01BEA42C71@wincent.com","subject":"Re: git-daemon breakage in 1.5.4","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-02-05T20:02:36Z","receivedAt":"2008-02-05T20:02:36Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Wincent Colaiuta <win@wincent.com> writes:\n\n> I just noticed that my copy of git-daemon running from xinetd on Red\n> Hat Enterprise Linux 3 has been broken since upgrading to 1.5.4.\n>\n> On the client side this is what you see (\"git clone\" used in the\n> example but you get the same issue with \"git ls-remote\"):\n>\n>   git clone git://git.wincent.com/wikitext.git\n>   Initialized empty Git repository in /tmp/wikitext/.git/\n>   fatal: The remote end hung up unexpectedly\n>   fetch-pack from 'git://git.wincent.com/wikitext.git' failed.\n>\n> Nothing printed to the logs on the server side: it simply hangs up. By\n> connecting via telnet I've confirmed that git-daemon is running and\n> does accept the initial connection.\n>\n> The verdict according to \"git bisect\" is that\n> 511707d42b3b3e57d9623493092590546ffeae80 is first bad commit:\n>\n> commit 511707d42b3b3e57d9623493092590546ffeae80\n> Author: Scott R Parish <srp@srparish.net>\n> Date:   Sun Oct 28 04:17:20 2007 -0700\n>\n>     use only the $PATH for exec'ing git commands\n\nPerhaps you did not install git on the PATH processes launched\nby your inetd implementation would use?\n"},{"id":"67624","messageId":"C8E50E14-B50F-4385-A581-B69262E8E6A5@wincent.com","threadId":"11899","inReplyTo":"7vr6fr9noj.fsf@gitster.siamese.dyndns.org","subject":"Re: git-daemon breakage in 1.5.4","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2008-02-06T08:05:14Z","receivedAt":"2008-02-06T08:05:14Z","isPatch":false,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 5/2/2008, a las 21:02, Junio C Hamano escribió:\n\n> Wincent Colaiuta <win@wincent.com> writes:\n>\n>> I just noticed that my copy of git-daemon running from xinetd on Red\n>> Hat Enterprise Linux 3 has been broken since upgrading to 1.5.4.\n>>\n>> On the client side this is what you see (\"git clone\" used in the\n>> example but you get the same issue with \"git ls-remote\"):\n>>\n>>  git clone git://git.wincent.com/wikitext.git\n>>  Initialized empty Git repository in /tmp/wikitext/.git/\n>>  fatal: The remote end hung up unexpectedly\n>>  fetch-pack from 'git://git.wincent.com/wikitext.git' failed.\n>>\n>> Nothing printed to the logs on the server side: it simply hangs up.  \n>> By\n>> connecting via telnet I've confirmed that git-daemon is running and\n>> does accept the initial connection.\n>>\n>> The verdict according to \"git bisect\" is that\n>> 511707d42b3b3e57d9623493092590546ffeae80 is first bad commit:\n>>\n>> commit 511707d42b3b3e57d9623493092590546ffeae80\n>> Author: Scott R Parish <srp@srparish.net>\n>> Date:   Sun Oct 28 04:17:20 2007 -0700\n>>\n>>    use only the $PATH for exec'ing git commands\n>\n> Perhaps you did not install git on the PATH processes launched\n> by your inetd implementation would use?\n\nI don't know what PATH environment xinetd provides, but I can  \nreproduce this directly as follows from the command line without any  \ninvolvement from xientd:\n\nFirst, set up PATH with all the standard locations, with directories  \nunder /usr/local specified first. Git 1.5.4 is installed in /usr/local/ \nbin:\n\n   # export PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/ \nsbin:/sbin\n\nThis fails with the \"remote end hung up unexpectedly\" error:\n\n   # /usr/local/bin/git-daemon --inetd --base-path=/blah -- /blah\n\nDrop the --inetd option and it works with no errors:\n\n   # /usr/local/bin/git-daemon --base-path=/blah -- /blah\n\nNow, if I downgrade to Git 1.5.3.8, it works both with and without the  \n--inetd option.\n\nThe above behaviour is the same regardless of how I specify the path  \nto git-daemon (ie. absolute or relative, dashed or dashless).\n\nIs there anything I can do to get \"git daemon\" to be more verbose on  \nfailing?\n\nCheers,\nWincent\n"},{"id":"67630","messageId":"7v3as6321y.fsf@gitster.siamese.dyndns.org","threadId":"11899","inReplyTo":"C8E50E14-B50F-4385-A581-B69262E8E6A5@wincent.com","subject":"Re: git-daemon breakage in 1.5.4","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-02-06T08:46:17Z","receivedAt":"2008-02-06T08:46:17Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Wincent Colaiuta <win@wincent.com> writes:\n\n> This fails with the \"remote end hung up unexpectedly\" error:\n>\n>    # /usr/local/bin/git-daemon --inetd --base-path=/blah -- /blah\n>\n> Drop the --inetd option and it works with no errors:\n\nDo you mean you run the above from your command line and it\nfails?\n\nI do not think --inetd mode is supposed to work as a daemon that\naccepts connections.  Wouldn't it be talking with a single peer\nvia its stdin/stdout?\n\nPuzzled.\n"},{"id":"67641","messageId":"47A98092.2070509@viscovery.net","threadId":"11899","inReplyTo":"C8E50E14-B50F-4385-A581-B69262E8E6A5@wincent.com","subject":"Re: git-daemon breakage in 1.5.4","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2008-02-06T09:40:34Z","receivedAt":"2008-02-06T09:40:34Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Wincent Colaiuta schrieb:\n> El 5/2/2008, a las 21:02, Junio C Hamano escribió:\n>> Perhaps you did not install git on the PATH processes launched\n>> by your inetd implementation would use?\n> \n> I don't know what PATH environment xinetd provides, but I can reproduce\n> this directly as follows from the command line without any involvement\n> from xientd:\n> \n> First, set up PATH with all the standard locations, with directories\n> under /usr/local specified first. Git 1.5.4 is installed in /usr/local/bin:\n> \n>   # export\n> PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin\n> \n> This fails with the \"remote end hung up unexpectedly\" error:\n> \n>   # /usr/local/bin/git-daemon --inetd --base-path=/blah -- /blah\n\nIf you run this from the command line, you can't expect it to do anything\nuseful: It communicates with the client via stdin and stdout.\n\n> Drop the --inetd option and it works with no errors:\n> \n>   # /usr/local/bin/git-daemon --base-path=/blah -- /blah\n\nWhen I run git-daemon with a reduced path similar to this:\n\n   PATH=/bin:/usr/bin /usr/local/bin/git-daemon ...\n\ni.e. git is installed in /usr/local/bin, but it is not in PATH, then I\nalso get \"hung up unexpectedly\" from a client that connects to this server.\n\nWhich makes me think that you xinetd doesn't pass a PATH to git-daemon\nthat includes /usr/local/bin. Add this to your /etc/xinetd.d/git:\n\n    env = PATH=/bin:/usr/bin:/usr/local/bin\n\n(not tested).\n\n-- Hannes\n"},{"id":"67642","messageId":"EA30530E-B917-48CA-A43B-FAAF9721A9ED@wincent.com","threadId":"11899","inReplyTo":"7v3as6321y.fsf@gitster.siamese.dyndns.org","subject":"Re: git-daemon breakage in 1.5.4","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2008-02-06T09:44:53Z","receivedAt":"2008-02-06T09:44:53Z","isPatch":false,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 6/2/2008, a las 9:46, Junio C Hamano escribió:\n\n> Wincent Colaiuta <win@wincent.com> writes:\n>\n>> This fails with the \"remote end hung up unexpectedly\" error:\n>>\n>>   # /usr/local/bin/git-daemon --inetd --base-path=/blah -- /blah\n>>\n>> Drop the --inetd option and it works with no errors:\n>\n> Do you mean you run the above from your command line and it\n> fails?\n\nYes.\n\n> I do not think --inetd mode is supposed to work as a daemon that\n> accepts connections.  Wouldn't it be talking with a single peer\n> via its stdin/stdout?\n\nI don't know exactly what it does under the covers (will look now).  \nPerhaps it detects that its running from an interactive login and  \nmodifies its behaviour. But all I can confirm is that in 1.5.3.8 (and  \nbefore 511707d42b3b3e57d9623493092590546ffeae80) \"git daemon\" works  \nfrom the command line both with and without the --inetd option, and in  \n1.5.4 (from that commit onwards) \"git daemon\" doesn't work for me with  \nthe --inetd option but it does without it. The testing from the  \ncommand line is really only a diagnostic thing (perhaps misguided),  \nbut it does exhibit the same behaviour as issuing the same command  \nwithin xinetd.\n\nCheers,\n>\n\nWincent\n"},{"id":"67647","messageId":"27E0A387-5A6B-4577-AAF4-ACE65A24E306@wincent.com","threadId":"11899","inReplyTo":"47A98092.2070509@viscovery.net","subject":"Re: git-daemon breakage in 1.5.4","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2008-02-06T10:12:23Z","receivedAt":"2008-02-06T10:12:23Z","isPatch":false,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 6/2/2008, a las 10:40, Johannes Sixt escribió:\n\n>> This fails with the \"remote end hung up unexpectedly\" error:\n>>\n>>  # /usr/local/bin/git-daemon --inetd --base-path=/blah -- /blah\n>\n> If you run this from the command line, you can't expect it to do  \n> anything\n> useful: It communicates with the client via stdin and stdout.\n\nStrangely, it worked with 1.5.3.8. But I just tried to reproduce it  \nand now I can't, so there must have been some error in my procedure.  \nDoh. The bizarre thing is that in preparing these emails I tested it  \nat least twice, which means I must have made the exact same mistake at  \nleast twice...\n\n> Which makes me think that you xinetd doesn't pass a PATH to git-daemon\n> that includes /usr/local/bin. Add this to your /etc/xinetd.d/git:\n>\n>    env = PATH=/bin:/usr/bin:/usr/local/bin\n>\n> (not tested).\n\nThat works. Thanks.\n\nIt's an acceptable workaround (the other is installing /usr instead  \nof /usr/local). Seeing as it worked in 1.5.3.8, does this qualify as  \nbreakage, or should we not worry about it?\n\nCheers,\nWincent\n"},{"id":"67650","messageId":"47A98BD9.5040306@viscovery.net","threadId":"11899","inReplyTo":"27E0A387-5A6B-4577-AAF4-ACE65A24E306@wincent.com","subject":"Re: git-daemon breakage in 1.5.4","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2008-02-06T10:28:41Z","receivedAt":"2008-02-06T10:28:41Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Wincent Colaiuta schrieb:\n> El 6/2/2008, a las 10:40, Johannes Sixt escribió:\n> \n>>> This fails with the \"remote end hung up unexpectedly\" error:\n>>>\n>>>  # /usr/local/bin/git-daemon --inetd --base-path=/blah -- /blah\n>>\n>> If you run this from the command line, you can't expect it to do anything\n>> useful: It communicates with the client via stdin and stdout.\n> \n> Strangely, it worked with 1.5.3.8. But I just tried to reproduce it and\n> now I can't, so there must have been some error in my procedure. Doh.\n> The bizarre thing is that in preparing these emails I tested it at least\n> twice, which means I must have made the exact same mistake at least\n> twice...\n> \n>> Which makes me think that you xinetd doesn't pass a PATH to git-daemon\n>> that includes /usr/local/bin. Add this to your /etc/xinetd.d/git:\n>>\n>>    env = PATH=/bin:/usr/bin:/usr/local/bin\n>>\n>> (not tested).\n> \n> That works. Thanks.\n> \n> It's an acceptable workaround (the other is installing /usr instead of\n> /usr/local). Seeing as it worked in 1.5.3.8, does this qualify as\n> breakage, or should we not worry about it?\n\nDoes this patch make a difference? (It does for me.)\n\ndiff --git a/daemon.c b/daemon.c\nindex 41a60af..c99285e 100644\n--- a/daemon.c\n+++ b/daemon.c\n@@ -1026,6 +1026,7 @@ int main(int argc, char **argv)\n \tstruct group *group;\n \tgid_t gid = 0;\n \tint i;\n+\tchar *cmd_path = strdup(argv[0]), *slash;\n\n \t/* Without this we cannot rely on waitpid() to tell\n \t * what happened to our children.\n@@ -1184,6 +1185,13 @@ int main(int argc, char **argv)\n \tif (strict_paths && (!ok_paths || !*ok_paths))\n \t\tdie(\"option --strict-paths requires a whitelist\");\n\n+\tslash = strrchr(cmd_path, '/');\n+\tif (slash) {\n+\t\t*slash = 0;\n+\t\tsetup_path(cmd_path);\n+\t}\n+\tfree(cmd_path);\n+\n \tif (inetd_mode) {\n \t\tstruct sockaddr_storage ss;\n \t\tstruct sockaddr *peer = (struct sockaddr *)&ss;\n"},{"id":"67659","messageId":"47A99B11.8080506@viscovery.net","threadId":"11899","inReplyTo":"47A98092.2070509@viscovery.net","subject":"Re: git-daemon breakage in 1.5.4","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2008-02-06T11:33:37Z","receivedAt":"2008-02-06T11:33:37Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Johannes Sixt schrieb:\n> Wincent Colaiuta schrieb:\n>> Drop the --inetd option and it works with no errors:\n>>\n>>   # /usr/local/bin/git-daemon --base-path=/blah -- /blah\n> \n> When I run git-daemon with a reduced path similar to this:\n> \n>    PATH=/bin:/usr/bin /usr/local/bin/git-daemon ...\n> \n> i.e. git is installed in /usr/local/bin, but it is not in PATH, then I\n> also get \"hung up unexpectedly\" from a client that connects to this server.\n> \n> Which makes me think that you xinetd doesn't pass a PATH to git-daemon\n> that includes /usr/local/bin. Add this to your /etc/xinetd.d/git:\n> \n>     env = PATH=/bin:/usr/bin:/usr/local/bin\n> \n> (not tested).\n\nAnd if I run it this way:\n\n    PATH=/bin:/usr/bin /usr/local/bin/git daemon ...\n\n(notice the dash-less form) it works, too. Although I don't know if this\nsomehow would interfere with --inetd mode.\n\n-- Hannes\n"},{"id":"67660","messageId":"57A122D1-6D7E-4210-A624-75D19ECC0258@wincent.com","threadId":"11899","inReplyTo":"47A98BD9.5040306@viscovery.net","subject":"Re: git-daemon breakage in 1.5.4","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2008-02-06T11:39:36Z","receivedAt":"2008-02-06T11:39:36Z","isPatch":false,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 6/2/2008, a las 11:28, Johannes Sixt escribió:\n\n>>> Which makes me think that you xinetd doesn't pass a PATH to git- \n>>> daemon\n>>> that includes /usr/local/bin. Add this to your /etc/xinetd.d/git:\n>>>\n>>>   env = PATH=/bin:/usr/bin:/usr/local/bin\n>>>\n>>> (not tested).\n>>\n>> That works. Thanks.\n>>\n>> It's an acceptable workaround (the other is installing /usr instead  \n>> of\n>> /usr/local). Seeing as it worked in 1.5.3.8, does this qualify as\n>> breakage, or should we not worry about it?\n>\n> Does this patch make a difference? (It does for me.)\n\nNope. I applied this on top of \"maint\", removed the PATH setup from / \netc/xinetd.d/git, and get the \"remote end hung up unexpectedly\" again.  \nIf I restore the PATH setup then it works, but then, so does does 1.5.4.\n\nCheers,\nWincent\n\n> diff --git a/daemon.c b/daemon.c\n> index 41a60af..c99285e 100644\n> --- a/daemon.c\n> +++ b/daemon.c\n> @@ -1026,6 +1026,7 @@ int main(int argc, char **argv)\n> \tstruct group *group;\n> \tgid_t gid = 0;\n> \tint i;\n> +\tchar *cmd_path = strdup(argv[0]), *slash;\n>\n> \t/* Without this we cannot rely on waitpid() to tell\n> \t * what happened to our children.\n> @@ -1184,6 +1185,13 @@ int main(int argc, char **argv)\n> \tif (strict_paths && (!ok_paths || !*ok_paths))\n> \t\tdie(\"option --strict-paths requires a whitelist\");\n>\n> +\tslash = strrchr(cmd_path, '/');\n> +\tif (slash) {\n> +\t\t*slash = 0;\n> +\t\tsetup_path(cmd_path);\n> +\t}\n> +\tfree(cmd_path);\n> +\n> \tif (inetd_mode) {\n> \t\tstruct sockaddr_storage ss;\n> \t\tstruct sockaddr *peer = (struct sockaddr *)&ss;\n"},{"id":"67662","messageId":"47A9A1B8.5090501@users.sourceforge.net","threadId":"11899","inReplyTo":"47A98092.2070509@viscovery.net","subject":"Re: git-daemon breakage in 1.5.4","fromName":"Adam Piatyszek","fromEmail":"ediap@users.sourceforge.net","sentAt":"2008-02-06T12:02:00Z","receivedAt":"2008-02-06T12:02:00Z","isPatch":false,"sender":{"key":"ediap@users.sourceforge.net","avatar":null},"body":"* Johannes Sixt [6 II 2008 10:40]:\n> When I run git-daemon with a reduced path similar to this:\n> \n>    PATH=/bin:/usr/bin /usr/local/bin/git-daemon ...\n> \n> i.e. git is installed in /usr/local/bin, but it is not in PATH, then I\n> also get \"hung up unexpectedly\" from a client that connects to this server.\n> \n> Which makes me think that you xinetd doesn't pass a PATH to git-daemon\n> that includes /usr/local/bin. Add this to your /etc/xinetd.d/git:\n> \n>     env = PATH=/bin:/usr/bin:/usr/local/bin\n\nYou can also run \"git daemon\" passing --exec-path as a git argument. \nThis should help.  For instance, I use the following configuration in \ninetd.conf (SunOS 5.9):\n\n   git   stream   tcp   nowait   gituser   /usr/local/bin/git \\\n     git --exec-path=/usr/local/bin daemon --inetd \\\n     --base-path=/export/home/gituser/git /export/home/gituser/git\n\nBR,\n/Adam\n\n\n-- \n.:.  Adam Piatyszek (ediap)  .:.....................................:.\n.:.  ediap@users.sourceforge.net  .:................................:.\n"}]}