I've seen several reports of what seems to be the following
problem, but no fixes. I do not understand the root-cause.
I have found, however, what seems to be a work-around.
I'm starting v1.5.2.5 (the Kubuntu 7.10 package) git-daemon
(as a normal-user, *not* super-user) as:
export GIT_TRACE=/tmp/LOG-git-daemon
exec \
git daemon --detach --syslog --verbose --base-path=/pub/scm
The repositories being served are simple (non-bare) clones,
with nothing strange/weird. The remote machine (CentOS),
running a self-built un-modified v1.5.5, can access them Ok:
$ git ls-remote git://SERVER/repo
... works ...
$
However, an invalid path causes both the git-daemon and the
client to hang (I'm too impatient and do not know if either
times out):
$ git ls-remote git://SERVER/repo/garbage
... hangs ...
I can ^C the client, but the server is still hung, and will
not respond to *any* requests. I must kill the git-daemon.
The GIT_TRACE log's contents do not seem to be interesting.
The last entries in the syslog are:
git-daemon: [3705] Connection from <REMOTE>
git-daemon: [3705] Extended attributes (17 bytes) exist <...>
git-daemon: [3705] Request upload-pack for '/repo/garbage'
git-daemon: [3705] '/pub/scm/repo/garbage': unable to chdir or not a git archive
Annoyingly, strace(1)ing git-daemon causes the problem to
vanish! Everything then seems to be work as expected.
But now the syslog contains an additional, 5th, line:
git-daemon: [3705] Disconnected (with error)
(The "with error" is present only in the .../garbage case.)
Attaching to a hung git-daemon with strace shows that it's
hung in futex(2):
$ strace -p3705
Process 3705 attached - interrupt to quit
futex(0x2b502cbf3980, FUTEX_WAIT, 2, NULL <unfinished ...>
... hangs ...
Attaching to a hung git-daemon with gdb(1) results in the
following backtrace:
(gdb) where
#0 0x00002b502c97d1d8 in ?? () from /lib/libc.so.6
#1 0x00002b502c913698 in ?? () from /lib/libc.so.6
#2 0x00002b502c912960 in realloc () from /lib/libc.so.6
#3 0x00002b502c905eb4 in ?? () from /lib/libc.so.6
#4 0x00002b502c8fd897 in fclose () from /lib/libc.so.6
#5 0x00002b502c96d371 in __vsyslog_chk () from /lib/libc.so.6
#6 0x00002b502c96d8a0 in syslog () from /lib/libc.so.6
#7 0x0000000000403896 in ?? ()
#8 <signal handler called>
#9 0x00002b502c9373ab in fork () from /lib/libc.so.6
#10 0x0000000000404443 in ?? ()
#11 0x0000000000404c99 in ?? ()
#12 0x00002b502c8bab44 in __libc_start_main () from /lib/libc.so.6
#13 0x0000000000403179 in ?? ()
#14 0x00007fff7e63eab8 in ?? ()
#15 0x0000000000000000 in ?? ()
(gdb)
It's fairly clear it's hung doing the syslog(3) of the (missing)
"Disconnected (with error)" message. A interesting point is the
SIGCHLD handler in (git-)daemon.c appears to have been called
before the parent's fork(2) returned. I presume there is a race
here, but admit I do not see it. This (broadly) makes sense; the
server is a Very Fast machine. And strace'ing slows things down.
The workaround is to omit --verbose and hence never try to syslog
the "Disconnected ..." message.
cheers!
-blf-
--
“How many surrealists does it take to | Brian Foster
change a lightbulb? Three. One calms | somewhere in south of France
the warthog, and two fill the bathtub | Stop E$$o (ExxonMobil)!
with brightly-coloured machine tools.” | http://www.stopesso.com
--
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
