{"thread":{"id":"39256","subject":"RE: t5570 - not cloned error","startedAt":"2015-05-05T19:28:20Z","lastAt":"2015-05-07T18:24:46Z","messageCount":6,"participants":["Randall S. Becker","Junio C Hamano","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"260614","messageId":"013701d08769$a5bbab80$f1330280$@nexbridge.com","threadId":"39256","inReplyTo":null,"subject":"RE: t5570 - not cloned error","fromName":"Randall S. Becker","fromEmail":"rsbecker@nexbridge.com","sentAt":"2015-05-05T19:28:20Z","receivedAt":"2015-05-05T19:28:20Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"Sorry to repost - ended up in my own spam trap.\n\nOn May 1, 2015 11:05 AM, I wrote, in my haste:\n> \n> Greetings - and asking for a bit of help resolving test failures.\n> \n> I'm having an issue with t5570 at 2.3.7 which seems to be a regression\nfrom\n> 2.3.3 (currently installed), but I cannot be sure. This test failed prior\nto\n> 2.3.0 in the box, worked from 2.3.0 to 2.3.3 - suggesting that it may be\n> environmental, not actually in git. Making some assumptions, it looks like\n> the URL for the test repository is not correct and may depend on localhost\n> resolving properly - which DNS does not do well on this box (outside my\n> control, we are multi-home, and localhost does not resolve to 127.0.0.1 or\n> [::1]). Only t5570 #'s 3-5 fail and I found a strange message in the\noutput\n> of the test seemingly referring to a bad repo name. I would really\n> appreciate some pointers on where to look next and how to go about\nresolving\n> this. I am happy to try to work through this on 2.4.0 if that would be\nmore\n> efficient for the team. Anything relating to git-daemon makes me nervous\nin\n> terms of installing the code.\n> \n> Platform is HP NonStop (Posix-esque environment):\n> \n> In the test output:\n> *** t5570-git-daemon.sh ***\n> <snip>\n> not ok 3 - clone git repository\n> #\n> #               git clone \"$GIT_DAEMON_URL/repo.git\" clone &&\n> #               test_cmp file clone/file\n> #\n> not ok 4 - fetch changes via git protocol\n> #\n> #               echo content >>file &&\n> #               git commit -a -m two &&\n> #               git push public &&\n> #               (cd clone && git pull) &&\n> #               test_cmp file clone/file\n> #\n> not ok 5 - remote detects correct HEAD\n> #\n> #               git push public master:other &&\n> #               (cd clone &&\n> #                git remote set-head -d origin &&\n> #                git remote set-head -a origin &&\n> \n> And\n> \n> ../git/t/trash directory.t5570-git-daemon: cat output\n> fatal: remote error: repository not exported: /repo.git\n> \n> Additional context: t0025, t0301, t3900, t9001, t9020 are not 100% but the\n> issues are acceptable - we can discuss separately.\n\nWe definitely have an issue with localhost. When forcing the DNS resolver to\nreturn 127.0.0.1, we pass 1-16 then 17 fails as I expected to happen based\non my DNS futzing. Heads up that this test is not-surprisingly sensitive to\nDNS problems. My environment is still in a messy state where I can reproduce\nthe original problem so it might be a useful moment for me to find a way to\nmodify the test script to harden it. Any suggestion on that score (as in\nwhere and\nroughly how it might be made more reliable)?\n\nNote: Since the original post, I moved the fork to 2.4.0.\n\nCheers,\nRandall\n\n"},{"id":"260624","messageId":"xmqqr3qud6qm.fsf@gitster.dls.corp.google.com","threadId":"39256","inReplyTo":"013701d08769$a5bbab80$f1330280$@nexbridge.com","subject":"Re: t5570 - not cloned error","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-05-05T22:01:05Z","receivedAt":"2015-05-05T22:01:05Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Randall S. Becker\" <rsbecker@nexbridge.com> writes:\n\n> We definitely have an issue with localhost. When forcing the DNS resolver to\n> return 127.0.0.1, we pass 1-16 then 17 fails as I expected to happen based\n> on my DNS futzing. Heads up that this test is not-surprisingly sensitive to\n> DNS problems. My environment is still in a messy state where I can reproduce\n> the original problem so it might be a useful moment for me to find a way to\n> modify the test script to harden it. Any suggestion on that score\n> (as in where and roughly how it might be made more reliable)?\n\nI do not think this counts as a useful \"suggestion\", but is this\n\"resolver does not work for local as expected\" case even worth\nprotecting our tests against?\n"},{"id":"260626","messageId":"017401d08782$24d6f5b0$6e84e110$@nexbridge.com","threadId":"39256","inReplyTo":"xmqqr3qud6qm.fsf@gitster.dls.corp.google.com","subject":"RE: t5570 - not cloned error","fromName":"Randall S. Becker","fromEmail":"rsbecker@nexbridge.com","sentAt":"2015-05-05T22:23:41Z","receivedAt":"2015-05-05T22:23:41Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"\nOn May 5, 2015 6:01 PM Junio C Hamano wrote:\n> \"Randall S. Becker\" <rsbecker@nexbridge.com> writes:\n> > We definitely have an issue with localhost. When forcing the DNS\nresolver to\n> > return 127.0.0.1, we pass 1-16 then 17 fails as I expected to happen\nbased\n> > on my DNS futzing. Heads up that this test is not-surprisingly sensitive\nto\n> > DNS problems. My environment is still in a messy state where I can\nreproduce\n> > the original problem so it might be a useful moment for me to find a way\nto\n> > modify the test script to harden it. Any suggestion on that score\n> > (as in where and roughly how it might be made more reliable)?\n> \n> I do not think this counts as a useful \"suggestion\", but is this\n> \"resolver does not work for local as expected\" case even worth\n> protecting our tests against?\n\nI see your point, but after having spent \"way too much time\" away from the\n$DAYJOB tracking this down, I was hoping to catch the root cause earlier\nnext time. Perhaps adding a test step validating that localhost comes back\nwith a reasonable value - whatever that may be in context. I'm just not sure\nwhat the test really needs at its heart to run properly - obviously the IP\naddress of the system as  visible in our DMZ is not working for the test. \n"},{"id":"260628","messageId":"20150505225521.GB18817@peff.net","threadId":"39256","inReplyTo":"017401d08782$24d6f5b0$6e84e110$@nexbridge.com","subject":"Re: t5570 - not cloned error","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-05-05T22:55:21Z","receivedAt":"2015-05-05T22:55:21Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, May 05, 2015 at 06:23:41PM -0400, Randall S. Becker wrote:\n\n> \n> On May 5, 2015 6:01 PM Junio C Hamano wrote:\n> > \"Randall S. Becker\" <rsbecker@nexbridge.com> writes:\n> > > We definitely have an issue with localhost. When forcing the DNS\n> resolver to\n> > > return 127.0.0.1, we pass 1-16 then 17 fails as I expected to happen\n> based\n> > > on my DNS futzing. Heads up that this test is not-surprisingly sensitive\n> to\n> > > DNS problems. My environment is still in a messy state where I can\n> reproduce\n> > > the original problem so it might be a useful moment for me to find a way\n> to\n> > > modify the test script to harden it. Any suggestion on that score\n> > > (as in where and roughly how it might be made more reliable)?\n> > \n> > I do not think this counts as a useful \"suggestion\", but is this\n> > \"resolver does not work for local as expected\" case even worth\n> > protecting our tests against?\n> \n> I see your point, but after having spent \"way too much time\" away from the\n> $DAYJOB tracking this down, I was hoping to catch the root cause earlier\n> next time. Perhaps adding a test step validating that localhost comes back\n> with a reasonable value - whatever that may be in context. I'm just not sure\n> what the test really needs at its heart to run properly - obviously the IP\n> address of the system as  visible in our DMZ is not working for the test.\n\nI'm having trouble even understanding who is looking up \"localhost\"\nhere.  All of the git-daemon tests should be directly using 127.0.0.1 in\nthe URLs (i.e., what is in $GIT_DAEMON_URL). If that is a problem, I\nthink you might be able to parameterize the way we set up\n$GIT_DAEMON_URL (and how we invoked git-daemon; see lib-git-daemon.sh).\n\nIn the interpolation tests, we do use the string \"localhost\" but we\nshould never do a lookup on it. We set an environment variable that\ntells the git client to _tell_ the server we looked up localhost, but we\nshould still be accessing it as 127.0.0.1.\n\nSo I'm confused about what the actual problem is, or why the test cares\nabout resolving \"localhost\" in the first place.\n\n-Peff\n"},{"id":"260637","messageId":"019401d08796$0bf9f880$23ede980$@nexbridge.com","threadId":"39256","inReplyTo":"20150505225521.GB18817@peff.net","subject":"RE: t5570 - not cloned error","fromName":"Randall S. Becker","fromEmail":"rsbecker@nexbridge.com","sentAt":"2015-05-06T00:46:09Z","receivedAt":"2015-05-06T00:46:09Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On May 5, 2015 6:55 PM Jeff King wrote:\n> On Tue, May 05, 2015 at 06:23:41PM -0400, Randall S. Becker wrote:\n> > On May 5, 2015 6:01 PM Junio C Hamano wrote:\n> > > \"Randall S. Becker\" <rsbecker@nexbridge.com> writes:\n> > > > We definitely have an issue with localhost. When forcing the DNS\n> > resolver to\n> > > > return 127.0.0.1, we pass 1-16 then 17 fails as I expected to happen\n> > based\n> > > > on my DNS futzing. Heads up that this test is not-surprisingly sensitive\n> > to\n> > > > DNS problems. My environment is still in a messy state where I can\n> > reproduce\n> > > > the original problem so it might be a useful moment for me to find a way\n> > to\n> > > > modify the test script to harden it. Any suggestion on that score\n> > > > (as in where and roughly how it might be made more reliable)?\n> > >\n> > > I do not think this counts as a useful \"suggestion\", but is this\n> > > \"resolver does not work for local as expected\" case even worth\n> > > protecting our tests against?\n> >\n> > I see your point, but after having spent \"way too much time\" away from the\n> > $DAYJOB tracking this down, I was hoping to catch the root cause earlier\n> > next time. Perhaps adding a test step validating that localhost comes back\n> > with a reasonable value - whatever that may be in context. I'm just not sure\n> > what the test really needs at its heart to run properly - obviously the IP\n> > address of the system as  visible in our DMZ is not working for the test.\n> \n> I'm having trouble even understanding who is looking up \"localhost\"\n> here.  All of the git-daemon tests should be directly using 127.0.0.1 in\n> the URLs (i.e., what is in $GIT_DAEMON_URL). If that is a problem, I\n> think you might be able to parameterize the way we set up\n> $GIT_DAEMON_URL (and how we invoked git-daemon; see lib-git-daemon.sh).\n> \n> In the interpolation tests, we do use the string \"localhost\" but we\n> should never do a lookup on it. We set an environment variable that\n> tells the git client to _tell_ the server we looked up localhost, but we\n> should still be accessing it as 127.0.0.1.\n> \n> So I'm confused about what the actual problem is, or why the test cares\n> about resolving \"localhost\" in the first place.\n\nThat gives me a pretty good idea of where to start looking. I will first hunt down the resolution and go from there. Stay tuned - it may be a day or two before I have a chance to do more than a cursory debug.\n\nCheers,\nRandall\n"},{"id":"260765","messageId":"009401d088f3$18d53200$4a7f9600$@nexbridge.com","threadId":"39256","inReplyTo":"019401d08796$0bf9f880$23ede980$@nexbridge.com","subject":"RE: t5570 - not cloned error","fromName":"Randall S. Becker","fromEmail":"rsbecker@nexbridge.com","sentAt":"2015-05-07T18:24:46Z","receivedAt":"2015-05-07T18:24:46Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On May 5, 2015 8:46 PM, I wrote in my haste:\n> On May 5, 2015 6:55 PM Jeff King wrote:\n> > On Tue, May 05, 2015 at 06:23:41PM -0400, Randall S. Becker wrote:\n> > > On May 5, 2015 6:01 PM Junio C Hamano wrote:\n> > > > \"Randall S. Becker\" <rsbecker@nexbridge.com> writes:\n> > > > > We definitely have an issue with localhost. When forcing the DNS\n> > > resolver to\n> > > > > return 127.0.0.1, we pass 1-16 then 17 fails as I expected to happen\n> > > based\n> > > > > on my DNS futzing. Heads up that this test is not-surprisingly sensitive\n> > > to\n> > > > > DNS problems. My environment is still in a messy state where I can\n> > > reproduce\n> > > > > the original problem so it might be a useful moment for me to find a way\n> > > to\n> > > > > modify the test script to harden it. Any suggestion on that score\n> > > > > (as in where and roughly how it might be made more reliable)?\n> > > >\n> > > > I do not think this counts as a useful \"suggestion\", but is this\n> > > > \"resolver does not work for local as expected\" case even worth\n> > > > protecting our tests against?\n> > >\n> > > I see your point, but after having spent \"way too much time\" away from the\n> > > $DAYJOB tracking this down, I was hoping to catch the root cause earlier\n> > > next time. Perhaps adding a test step validating that localhost comes back\n> > > with a reasonable value - whatever that may be in context. I'm just not sure\n> > > what the test really needs at its heart to run properly - obviously the IP\n> > > address of the system as  visible in our DMZ is not working for the test.\n> >\n> > I'm having trouble even understanding who is looking up \"localhost\"\n> > here.  All of the git-daemon tests should be directly using 127.0.0.1 in\n> > the URLs (i.e., what is in $GIT_DAEMON_URL). If that is a problem, I\n> > think you might be able to parameterize the way we set up\n> > $GIT_DAEMON_URL (and how we invoked git-daemon; see lib-git-\n> daemon.sh).\n> >\n> > In the interpolation tests, we do use the string \"localhost\" but we\n> > should never do a lookup on it. We set an environment variable that\n> > tells the git client to _tell_ the server we looked up localhost, but we\n> > should still be accessing it as 127.0.0.1.\n> >\n> > So I'm confused about what the actual problem is, or why the test cares\n> > about resolving \"localhost\" in the first place.\n> \n> That gives me a pretty good idea of where to start looking. I will first hunt\n> down the resolution and go from there. Stay tuned - it may be a day or two\n> before I have a chance to do more than a cursory debug.\n\nI found the root cause, being that the multi-IP stack configuration on this platform is not being passed correctly through bash to the shell that make starts when running tests. When running the test under ksh, which has a deeper port, the test behaves correctly. As it turns out, this is a platform-specific issue with our bash port.\n\nThis is not git's issue at all, nor the DNS resolver configuration (although I did find an independent problem there). Sorry to be a bother.\n\nCheers,\nRandall\n"}]}