git-daemon

git-daemon

[Medve Emilian]

Hello,


It seems that something changed since maint/v.1.5.3.6 such that on
master and next git-daemon doesn't seem to be working anymore in inetd
mode. Can somebody please confirm this?


Thanks,
Emil.

Re: git-daemon

[Junio C Hamano]

"Medve Emilian" <Emilian.Medve@freescale.com> writes:

> It seems that something changed since maint/v.1.5.3.6 such that on
> master and next git-daemon doesn't seem to be working anymore in inetd
> mode. Can somebody please confirm this?

Sorry, I cannot quite parse.  Do you mean:

	master and next used to work.  Recently 'maint' was
	merged to them after v1.5.3.6 was cut.  master and next
	does not work anymore after that.

Or do you mean:

	maint (specifically at v1.5.3.6) works, but master and
	next contain more changes on top of them, and they do
	not work.

In either case, the only change to the daemon code between
v1.5.3.5 and master is this one:

commit c67359be45be74e1056d6293c6bb09ee6d00a54a
Author: Gerrit Pape <pape@smarden.org>
Date:   Mon Nov 5 09:16:22 2007 +0000

    git-daemon: fix remote port number in log entry
    
    The port number in struct sockaddr_in needs to be converted from network
    byte order to host byte order (on some architectures).
    
    Signed-off-by: Gerrit Pape <pape@smarden.org>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 daemon.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/daemon.c b/daemon.c
index 660e155..b8df980 100644
--- a/daemon.c
+++ b/daemon.c
@@ -540,7 +540,7 @@ static int execute(struct sockaddr *addr)
 		if (addr->sa_family == AF_INET) {
 			struct sockaddr_in *sin_addr = (void *) addr;
 			inet_ntop(addr->sa_family, &sin_addr->sin_addr, addrbuf, sizeof(addrbuf));
-			port = sin_addr->sin_port;
+			port = ntohs(sin_addr->sin_port);
 #ifndef NO_IPV6
 		} else if (addr && addr->sa_family == AF_INET6) {
 			struct sockaddr_in6 *sin6_addr = (void *) addr;
@@ -550,7 +550,7 @@ static int execute(struct sockaddr *addr)
 			inet_ntop(AF_INET6, &sin6_addr->sin6_addr, buf, sizeof(addrbuf) - 1);
 			strcat(buf, "]");
 
-			port = sin6_addr->sin6_port;
+			port = ntohs(sin6_addr->sin6_port);
 #endif
 		}
 		loginfo("Connection from %s:%d", addrbuf, port);

I do not see anything wrong in it.  The "port" variable is very
local to this function and is used only for that loginfo() call
at the end of the context.  So I am quite puzzled.

We have another irrelevant style change that is full of things
like this, but I do not think that makes any behaviour
difference either.

@@ -406,7 +406,8 @@ static struct daemon_service daemon_service[] = {
 	{ "receive-pack", "receivepack", receive_pack, 0, 1 },
 };
 
-static void enable_service(const char *name, int ena) {
+static void enable_service(const char *name, int ena)
+{
 	int i;
 	for (i = 0; i < ARRAY_SIZE(daemon_service); i++) {
 		if (!strcmp(daemon_service[i].name, name)) {

RE: git-daemon

[Medve Emilian]

Hello Junio,


v1.5.3.6 works but the HEAD of master and next don't. I considered the
patches below but they seemed harmless. I think the problem comes form
upload-pack (and below it). Weirdly enough running git-daemon standalone
seems to work fine. Cloning over ssh or on the same file system seems to
work fine too.

I was hoping somebody can repeat the experiment (build the latest master
or maint) and invalidate my experience.


Cheers,
Emil.


> -----Original Message-----
> From: Junio C Hamano [mailto:gitster@pobox.com] 
> Sent: Monday, November 19, 2007 4:24 PM
> To: Medve Emilian
> Cc: git@vger.kernel.org
> Subject: Re: git-daemon
> 
> "Medve Emilian" <Emilian.Medve@freescale.com> writes:
> 
> > It seems that something changed since maint/v.1.5.3.6 such that on
> > master and next git-daemon doesn't seem to be working 
> anymore in inetd
> > mode. Can somebody please confirm this?
> 
> Sorry, I cannot quite parse.  Do you mean:
> 
> 	master and next used to work.  Recently 'maint' was
> 	merged to them after v1.5.3.6 was cut.  master and next
> 	does not work anymore after that.
> 
> Or do you mean:
> 
> 	maint (specifically at v1.5.3.6) works, but master and
> 	next contain more changes on top of them, and they do
> 	not work.
> 
> In either case, the only change to the daemon code between
> v1.5.3.5 and master is this one:
> 
> commit c67359be45be74e1056d6293c6bb09ee6d00a54a
> Author: Gerrit Pape <pape@smarden.org>
> Date:   Mon Nov 5 09:16:22 2007 +0000
> 
>     git-daemon: fix remote port number in log entry
>     
>     The port number in struct sockaddr_in needs to be 
> converted from network
>     byte order to host byte order (on some architectures).
>     
>     Signed-off-by: Gerrit Pape <pape@smarden.org>
>     Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
>  daemon.c |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/daemon.c b/daemon.c
> index 660e155..b8df980 100644
> --- a/daemon.c
> +++ b/daemon.c
> @@ -540,7 +540,7 @@ static int execute(struct sockaddr *addr)
>  		if (addr->sa_family == AF_INET) {
>  			struct sockaddr_in *sin_addr = (void *) addr;
>  			inet_ntop(addr->sa_family, 
> &sin_addr->sin_addr, addrbuf, sizeof(addrbuf));
> -			port = sin_addr->sin_port;
> +			port = ntohs(sin_addr->sin_port);
>  #ifndef NO_IPV6
>  		} else if (addr && addr->sa_family == AF_INET6) {
>  			struct sockaddr_in6 *sin6_addr = (void *) addr;
> @@ -550,7 +550,7 @@ static int execute(struct sockaddr *addr)
>  			inet_ntop(AF_INET6, 
> &sin6_addr->sin6_addr, buf, sizeof(addrbuf) - 1);
>  			strcat(buf, "]");
>  
> -			port = sin6_addr->sin6_port;
> +			port = ntohs(sin6_addr->sin6_port);
>  #endif
>  		}
>  		loginfo("Connection from %s:%d", addrbuf, port);
> 
> I do not see anything wrong in it.  The "port" variable is very
> local to this function and is used only for that loginfo() call
> at the end of the context.  So I am quite puzzled.
> 
> We have another irrelevant style change that is full of things
> like this, but I do not think that makes any behaviour
> difference either.
> 
> @@ -406,7 +406,8 @@ static struct daemon_service daemon_service[] = {
>  	{ "receive-pack", "receivepack", receive_pack, 0, 1 },
>  };
>  
> -static void enable_service(const char *name, int ena) {
> +static void enable_service(const char *name, int ena)
> +{
>  	int i;
>  	for (i = 0; i < ARRAY_SIZE(daemon_service); i++) {
>  		if (!strcmp(daemon_service[i].name, name)) {

Re: git-daemon

[Jeff King]

On Mon, Nov 19, 2007 at 03:49:36PM -0700, Medve Emilian wrote:

> v1.5.3.6 works but the HEAD of master and next don't. I considered the
> patches below but they seemed harmless. I think the problem comes form
> upload-pack (and below it). Weirdly enough running git-daemon standalone
> seems to work fine. Cloning over ssh or on the same file system seems to
> work fine too.
> 
> I was hoping somebody can repeat the experiment (build the latest master
> or maint) and invalidate my experience.

I can't find any breakage on the current master (ea559605). Can you be
more specific about what you are trying, how it is breaking, other
details of your setup, etc?

-Peff

RE: git-daemon

[Medve Emilian]

Hi Jeff,


I just built and installed the latest master (and next) and then I tried
to clone (as I usualy do) one of my repositories. I run git-daemon only
with the upload-pack service enabled.

On the client side this is the symptom:

client:~> git-clone git://server/srv/scm/linux-2.6.git
Initialized empty Git repository in /home/user/linux-2.6/.git/
fatal: The remote end hung up unexpectedly
fetch-pack from 'git://server/srv/scm/linux-2.6.git' failed.

On the server side I get this message:

xined.log:

07/11/20@10:17:04: START: git from=10.82.124.104
07/11/20@10:17:04: EXIT: git status=255 duration=0(sec)

messages:

Nov 20 10:17:04 emmedve1-12 git-daemon: [3921] Connection from
10.82.124.104:2978
Nov 20 10:17:04 emmedve1-12 git-daemon: [3921] Extended attributes (18
bytes) exist <host=server>
Nov 20 10:17:04 emmedve1-12 git-daemon: [3921] Request upload-pack for
'/srv/scm/linux-2.6.git'

And here is a small tcpdump snippet:

10:25:09.817726 IP client.msfrs > server.git: S 1311107296:1311107296(0)
win 65535 <mss 1260,nop,nop,sackOK>
10:25:09.817820 IP server.git > client.msfrs: S 3324794408:3324794408(0)
ack 1311107297 win 5840 <mss 1460,nop,nop,sackOK>
10:25:09.818028 IP client.msfrs > server.git: . ack 1 win 65535
10:25:09.817726 IP (tos 0x0, ttl 128, id 16243, offset 0, flags [DF],
proto: TCP (6), length: 48) client.msfrs > server.git: S, cksum 0x093b
(correct), 1311107296:1311107296(0) win 65535 <mss 1260,nop,nop,sackOK>
10:25:09.817820 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], proto:
TCP (6), length: 48) server.git > client.msfrs: S, cksum 0xd53c
(correct), 33247944
08:3324794408(0) ack 1311107297 win 5840 <mss 1460,nop,nop,sackOK>
10:25:09.818028 IP (tos 0x0, ttl 128, id 16244, offset 0, flags [DF],
proto: TCP (6), length: 40) client.msfrs > server.git: ., cksum 0x18d1
(correct), 1:1(0) ack 1 win 65535
10:25:09.819114 IP (tos 0x0, ttl 128, id 16246, offset 0, flags [DF],
proto: TCP (6), length: 102) client.msfrs > server.git: P 1:63(62) ack 1
win 65535
10:25:09.819159 IP (tos 0x0, ttl  64, id 14907, offset 0, flags [DF],
proto: TCP (6), length: 40) server.git > client.msfrs: ., cksum 0x01c3
(correct), 1:1(0) ack 63 win 5840
10:25:09.819114 IP client.msfrs > server.git: P 1:63(62) ack 1 win 65535
10:25:09.819159 IP server.git > client.msfrs: . ack 63 win 5840
10:25:09.821531 IP server.git > client.msfrs: F 1:1(0) ack 63 win 5840
10:25:09.821531 IP (tos 0x0, ttl  64, id 14908, offset 0, flags [DF],
proto: TCP (6), length: 40) server.git > client.msfrs: F, cksum 0x01c2
(correct), 1:1(0) ack 63 win 5840
10:25:09.821769 IP (tos 0x0, ttl 128, id 16248, offset 0, flags [DF],
proto: TCP (6), length: 40) client.msfrs > server.git: ., cksum 0x1892
(correct), 63:63(0) ack 2 win 65535
10:25:09.821769 IP client.msfrs > server.git: . ack 2 win 65535
10:25:09.826015 IP client.msfrs > server.git: F 63:63(0) ack 2 win 65535
10:25:09.826040 IP server.git > client.msfrs: . ack 64 win 5840
10:25:09.826015 IP (tos 0x0, ttl 128, id 16249, offset 0, flags [DF],
proto: TCP (6), length: 40) client.msfrs > server.git: F, cksum 0x1891
(correct), 63:63(0) ack 2 win 65535
10:25:09.826040 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], proto:
TCP (6), length: 40) server.git > client.msfrs: ., cksum 0x01c1
(correct), 2:2(0) ack 64 win 5840

I'm not sure what other details would be relevant: tools versions,
kernel version?

Did you try this and is working for you?


Cheers,
Emil.


> -----Original Message-----
> From: git-owner@vger.kernel.org 
> [mailto:git-owner@vger.kernel.org] On Behalf Of Jeff King
> Sent: Monday, November 19, 2007 11:08 PM
> To: Medve Emilian
> Cc: git@vger.kernel.org
> Subject: Re: git-daemon
> 
> On Mon, Nov 19, 2007 at 03:49:36PM -0700, Medve Emilian wrote:
> 
> > v1.5.3.6 works but the HEAD of master and next don't. I 
> considered the
> > patches below but they seemed harmless. I think the problem 
> comes form
> > upload-pack (and below it). Weirdly enough running 
> git-daemon standalone
> > seems to work fine. Cloning over ssh or on the same file 
> system seems to
> > work fine too.
> > 
> > I was hoping somebody can repeat the experiment (build the 
> latest master
> > or maint) and invalidate my experience.
> 
> I can't find any breakage on the current master (ea559605). Can you be
> more specific about what you are trying, how it is breaking, other
> details of your setup, etc?
> 
> -Peff
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git-daemon

[Jeff King]

On Tue, Nov 20, 2007 at 09:54:13AM -0700, Medve Emilian wrote:

> I just built and installed the latest master (and next) and then I tried
> to clone (as I usualy do) one of my repositories. I run git-daemon only
> with the upload-pack service enabled.
> [...]
> 
> Nov 20 10:17:04 emmedve1-12 git-daemon: [3921] Connection from
> 10.82.124.104:2978
> Nov 20 10:17:04 emmedve1-12 git-daemon: [3921] Extended attributes (18
> bytes) exist <host=server>
> Nov 20 10:17:04 emmedve1-12 git-daemon: [3921] Request upload-pack for
> '/srv/scm/linux-2.6.git'

I don't see anything useful there.  Have you tried running git-daemon
with --verbose? If that doesn't turn up anything, can you try running
with GIT_TRACE=1 to see the upload pack command that is being executed
(and try running it yourself)?

> Did you try this and is working for you?

Yes, it works fine (though I ran it under tcpserver, not xinetd).

-Peff

RE: git-daemon

[Medve Emilian]

Hi Jeff,


I think I found the explanation why v1.5.3.6 works for me (and others
apparently) but master and next don't. The fairly recent changes to the
PATH handling in exec_cmd.c done by Scott R Parish <srp@srparish.net>, I
believe, didn't make it into maint. Adjusting the PATH git-daemon sees
is fixing my problem even in master and next.

Thanks for your help and time.


Cheers,
Emil.


> -----Original Message-----
> From: Jeff King [mailto:peff@peff.net] 
> Sent: Tuesday, November 20, 2007 12:26 PM
> To: Medve Emilian
> Cc: git@vger.kernel.org
> Subject: Re: git-daemon
> 
> On Tue, Nov 20, 2007 at 09:54:13AM -0700, Medve Emilian wrote:
> 
> > I just built and installed the latest master (and next) and 
> then I tried
> > to clone (as I usualy do) one of my repositories. I run 
> git-daemon only
> > with the upload-pack service enabled.
> > [...]
> > 
> > Nov 20 10:17:04 emmedve1-12 git-daemon: [3921] Connection from
> > 10.82.124.104:2978
> > Nov 20 10:17:04 emmedve1-12 git-daemon: [3921] Extended 
> attributes (18
> > bytes) exist <host=server>
> > Nov 20 10:17:04 emmedve1-12 git-daemon: [3921] Request 
> upload-pack for
> > '/srv/scm/linux-2.6.git'
> 
> I don't see anything useful there.  Have you tried running git-daemon
> with --verbose? If that doesn't turn up anything, can you try running
> with GIT_TRACE=1 to see the upload pack command that is being executed
> (and try running it yourself)?
> 
> > Did you try this and is working for you?
> 
> Yes, it works fine (though I ran it under tcpserver, not xinetd).
> 
> -Peff