inted problems when upgrading to 1.6.0.4
Hi All,
At my company we have been using git for the past months, and except for a few people, everyone is happy with it. Last week, we discovered that the mac version of git was misbehaving (v1.5.6.4), but upgrading the client to the latest one (v1.6.0.4) fixed the issue. Fearing consistency issue between version, I decided to update the version of the central repository (ie, the place were people can go and synchronize their code) on a RHEL4 box from 1.5.6.4 to 1.6.0.4. went to my git directory, pulled, checkout v1.6.0.4, and compiled with 'make --prefix=/usr/loca/ all' and installed with the same comamnd. xinted dameon was restarted and then all hell broke loose.
All push/pull/clone operations were failing with the dreaded 'fatal: The remote end hung up unexpectedly'. After a few tests, this is what I found:
- I can clone/pull/push if I do it through ssh (ie, git clone ssh://server/project)
- I can clone/pull/push if I start git daemon on the command line through
git daemon --syslog --verbose --export-all --base-path=/vol0/git/projects --verbose --reuseaddr
But the way I had setup git, through xinetd is broken.
This is my current xinetd config:
service git
{
disable = yes socket_type = stream wait = no user = git type = UNLISTED protocol = tcp log_on_failure += USERID port = 9418 server = /usr/local/bin/git server_args = daemon --inetd --syslog --verbose --export-all
--base-path=/vol0/git/projects --allow-override=uploadpack }
And I'm getting the following errors:
Quoted 1 line
git clone
git://romanticism/tutorialtutorial.git
Initialized empty Git repository in /tmp/tutorial.git/.git/
fatal: protocol error: bad line length character
before adding the --allow-override=uploadpack I was getting this:
Quoted 1 line
git clone
git://romanticism/tutorialtutorial.git
Initialized empty Git repository in /tmp/tutorial.git/.git/
fatal: The remote end hung up unexpectedly
Since the error appeared after the upgrade, it seems likely it is either a but, or something change regarding inte/xinetd, but I can't find any documentation about changes here.
Any help will be appreciated.
Luis Gutierrez
On Tue, 2008-11-25 at 09:29 +0000, Luis Gutierrez wrote:
<snip>
Quoted 10 lines
All push/pull/clone operations were failing with the dreaded 'fatal: The remote end hung up unexpectedly'. After a few tests, this is what I found:
- I can clone/pull/push if I do it through ssh (ie, git clone ssh://server/project)
- I can clone/pull/push if I start git daemon on the command line through git daemon --syslog --verbose --export-all --base-path=/vol0/git/projects --verbose --reuseaddrBut the way I had setup git, through xinetd is broken.
I'm just guessing, as I'm too new to the git world to respond with more expertise, but I will suggest that perhaps your problem is that your $PATH is different with the xinitd configuration as contrasted with your ssh configuration, as the locations of the git binaries could be different.
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 23 lines · Luis Gutierrez
Quoted 12 lines · Arafangion
On Tue, 2008-11-25 at 09:29 +0000, Luis Gutierrez wrote:
<snip>Quoted 9 lines
All push/pull/clone operations were failing with the dreaded 'fatal: The remote end hung up unexpectedly'. After a few tests, this is what I found:
- I can clone/pull/push if I do it through ssh (ie, git clone ssh://server/project)
- I can clone/pull/push if I start git daemon on the command line through git daemon --syslog --verbose --export-all --base-path=/vol0/git/projects --verbose --reuseaddrQuoted 10 lines
Quoted 2 lines
But the way I had setup git, through xinetd is broken.
I'm just guessing, as I'm too new to the git world to respond with more expertise, but I will suggest that perhaps your problem is that your $PATH is different with the xinitd configuration as contrasted with your ssh configuration, as the locations of the git binaries could be different.
Quoted 4 lines
I've tried that, they are the same:
# which git /usr/local/bin/git
What about the other git-* commands?
Quoted 1 line
Quoted 27 lines · Arafangion
Quoted 25 lines · Luis Gutierrez
Quoted 23 lines · Arafangion
On Tue, 2008-11-25 at 09:29 +0000, Luis Gutierrez wrote:
<snip>Quoted 11 lines
All push/pull/clone operations were failing with the dreaded 'fatal: The remote end hung up unexpectedly'. After a few tests, this is what I found:
- I can clone/pull/push if I do it through ssh (ie, git clone ssh://server/project)
- I can clone/pull/push if I start git daemon on the command line through git daemon --syslog --verbose --export-all --base-path=/vol0/git/projects --verbose --reuseaddrBut the way I had setup git, through xinetd is broken.
I'm just guessing, as I'm too new to the git world to respond with more expertise, but I will suggest that perhaps your problem is that your $PATH is different with the xinitd configuration as contrasted with your ssh configuration, as the locations of the git binaries could be different.
Quoted 9 lines
Quoted 5 lines
I've tried that, they are the same:
# which git /usr/local/bin/gitWhat about the other git-* commands?
This is what I have now:
ls /usr/local/bin/git*
git git-cvsserver gitk git-receive-pack git-shell git-upload-archive git-upload-pack
it seems.. a lot less than it used to be, but then again, perhaps this is why the git-* commands were deprecated?
Signature · 2 lines
* Luis Gutierrez | * XMOS Semiconductor <http://www.xmos.com> Venturers House, King Street, Bristol BS1 4PB, UK
On Tue, 2008-11-25 at 10:54 +0000, Luis Gutierrez wrote:
<snip>
Quoted 6 lines
This is what I have now:
ls/usr/local/bin/git*
git git-cvsserver gitk git-receive-pack git-shell git-upload-archive git-upload-pack
it seems.. a lot less than it used to be, but then again, perhaps this is why the git-* commands were deprecated?
As Johannes Sixt mentioned, they have been moved from the bindir to the new gitexecdir.
Quoted 4 lines · On Tuesday 25 November 2008 10:29:14 Luis Gutierrez wrote:
[ ... ]
This is my current xinetd config:
service git
{
Quoted 11 lines
disable = yes
socket_type = stream
wait = no
user = git
type = UNLISTED
protocol = tcp
log_on_failure += USERID
port = 9418
server = /usr/local/bin/git
server_args = daemon --inetd --syslog --verbose --export-all --base-path=/vol0/git/projects --allow-override=uploadpack
} In the past I also had a problem when git was installed
in /usr/local/bin and git-daemon was launched from xinetd. I don't recall the details now, but believe all the obvious suspects (conflicting git installation, /usr/local/bin not in PATH, mis-installed/mis-configured git, et al.) seemed Ok. In any case, I debugged the problem by adding:
env += GIT_TRACE=/tmp/LOG-git-daemon
to the xinetd config. I suggest trying that and seeing what the logfile contains.
cheers!
-blf-
p.s. In my case, *using the information in the logfile*,
I eventually worked-around it by adding ‘--exec-path=/usr/local/bin’ to the ‘server_args’. I never did work out exactly what was going wrong (this was with a self-built git v1.5.5 on CentOS release 5).
Signature · 4 lines
“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
Quoted 9 lines · Luis Gutierrez
At my company we have been using git for the past months, and except for a few people, everyone is happy with it. Last week, we discovered that the mac version of git was misbehaving (v1.5.6.4), but upgrading the client to the latest one (v1.6.0.4) fixed the issue. Fearing consistency issue between version, I decided to update the version of the central repository (ie, the place were people can go and synchronize their code) on a RHEL4 box from 1.5.6.4 to 1.6.0.4.
went to my git directory, pulled, checkout v1.6.0.4, and compiled with 'make --prefix=/usr/loca/ all' and installed with the same comamnd.
It's not necessarily the cause of your problems, but didn't make install warn you:
!! You have installed git-* commands to new gitexecdir. !! Old version git-* commands still remain in bindir. !! Mixing two versions of Git will lead to problems. !! Please remove old version commands in bindir now.
Did you do as you were told?
-- Hannes
Quoted 4 lines · Luis Gutierrez
This is my current xinetd config:
service git
{
disable = yes
Remove this line.
-- Hannes