mainSavannah Administration - Support: sr #110712, Cannot pull/push from savannah any...

 
 

sr #110712: Cannot pull/push from savannah any more

Submitter:  None
Submitted:  Sun 04 Sep 2022 05:09:25 AM UTC
   
 
Category:  Source code repositories - developer access Priority:  5 - Normal
Severity:  4 - Important Status:  None
Privacy:  Public Assigned to:  None
Originator Email:  -email is unavailable- Operating System:  GNU/Linux
Open/Closed:  Open
* Mandatory Fields

Add a New Comment Rich Markup
   

Fri 09 Sep 2022 05:18:45 AM UTC, comment #4: 

comment #3:

> Just so there is no misunderstanding it seems that a year ago people were having trouble with git on Savannah but instead of opening a discussion about it with any Savannah or FSF admins they talked about it elsewhere on a non-free platform where no one with any connection to Savannah would see it. That's a correct assessment, right?


Partially. The main discussion indeed happened in the past. And they indeed did not bother reporting to Savannah admins. However, AFAIK, the issue with unstable fetching from savannah is being discussed on other non-free platforms relatively regularly.

In any case, I only mentioned the above in order to emphasise that the problem is not limited to a single user with weird setup. It is relatively common.

As for the bug report at hand, the failed git fetch is unlikely to be caused by a funny git config. From the discussion with the topic author, git fetch simply stopped working at some point without any changes made to git configuration.

Anonymous
Thu 08 Sep 2022 09:27:56 PM UTC, comment #3: 

Just so there is no misunderstanding it seems that a year ago people were having trouble with git on Savannah but instead of opening a discussion about it with any Savannah or FSF admins they talked about it elsewhere on a non-free platform where no one with any connection to Savannah would see it. That's a correct assessment, right?

Bob Proulx <rwp>
Site Administrator
Thu 08 Sep 2022 01:55:42 PM UTC, comment #2: 

comment #1:

> And that is all I can think of at the moment.  No one else is
> reporting unusuably slow data transfer.  Therefore it seems the
> problem is most likely on your end of the connection.  In which case
> only you on your end can debug it.


For reference, I have seen multiple complaints from people on GitHub and reddit about savannah issues with cloning. For example, https://github.com/doomemacs/doomemacs/issues/1707 or https://github.com/doomemacs/doomemacs/issues/5655. Some projects even go as far as maintaining savannah mirrors to avoid failures.

I myself also experienced slowdowns and failures fetching from savannah. Sometimes they go away after a while. Sometimes, connecting from an alternative location via VPN helps.

Ihor Radchenko <yantar92>
Thu 08 Sep 2022 01:39:10 AM UTC, comment #1: 

Sorry I didn't respond sooner.  I read your report.  But I couldn't
think of any reason why things might be very slow for you.  This is my
first chance to post that I am sorry but I don't have a clue.  It
works for me and I can clone and push to repositories and things are
fast for me.

rwp@angst:/tmp/junk$ time git clone git.savannah.gnu.org:/srv/git/emacs/org-mode.git
Cloning into 'org-mode'...
remote: Counting objects: 135896, done.
remote: Compressing objects: 100% (29366/29366), done.
remote: Total 135896 (delta 106451), reused 135807 (delta 106390)
Receiving objects: 100% (135896/135896), 88.42 MiB | 2.34 MiB/s, done.
Resolving deltas: 100% (106451/106451), done.

real    1m2.819s
user    0m58.152s
sys     0m2.361s
rwp@angst:/tmp/junk$ cd org-mode
bob@hysteria:/tmp/junk/org-mode$ time git pull
Already up to date.

real    0m4.458s
user    0m0.203s
sys     0m0.022s

I am in Colorado so this has to work across the country.  I do have a
fast home connection on a fiber network.  (Finally!)  But it is a good
test across the country and across the Internet router connections.

> debug1: /home/tec/.ssh/config line 81: Applying options for *
> debug1: /usr/etc/ssh/ssh_config line 27: Applying options for *


What options are being applied there?  They might be incompatible.

> debug1: auto-mux: Trying existing master
> debug1: multiplexing control connection
> debug2: fd 13 setting O_NONBLOCK
> debug3: fd 13 is O_NONBLOCK
> debug1: channel 5: new [mux-control]
> debug3: channel_post_mux_listener: new mux channel 5 fd 13
> debug3: mux_master_read_cb: channel 5: hello sent
> debug3: mux_master_read_cb: channel 5 packet type 0x00000001 len 4
> debug2: mux_master_process_hello: channel 5 client version 4
> debug3: mux_master_read_cb: channel 5 packet type 0x10000004 len 4
> debug2: mux_master_process_alive_check: channel 5: alive check
> debug3: mux_master_read_cb: channel 5 packet type 0x10000002 len 70
> debug2: mux_master_process_new_session: channel 5: request tty 1, X 0, agent 0, subsys 0, term "xterm-256color", cmd "", env 1
> debug3: mux_master_process_new_session: got fds stdin 14, stdout 15, stderr 16
> debug1: channel 6: new [client-session]
> debug2: mux_master_process_new_session: channel_new: 6 linked to control channel 5
> debug2: channel 6: send open
> debug3: send packet: type 90


This looks like your configuration is trying to use a ControlMaster to
reuse a previous connection.  That can't work.  And, I don't know, but
it feels suspicious that this might be part of the problem.  I suggest
removing any ControlMaster configuration for Savannah as that requires
both a persistent connection and auxiliary ports both of which are
restricted.

I believe you can configure ssh to avoid specific sites.  For example
I am pretty sure (needs to be tested) that one can specify a host
section this way and avoid having it take effect for the negated
pattern.

Host !.gnu.org

And that is all I can think of at the moment.  No one else is
reporting unusuably slow data transfer.  Therefore it seems the
problem is most likely on your end of the connection.  In which case
only you on your end can debug it.

I am happy to help in the debugging in any way possible.  Let me know
how I can help.

Bob Proulx <rwp>
Site Administrator
Sun 04 Sep 2022 05:09:25 AM UTC, original submission:  

Previously, savannah has been unstable and taken surprisingly long to pull/push with (~a minute on occasion). Now, I can't pull/push with savannah at all. Running

git fetch origin

with the remote
tec@git.savannah.gnu.org:/srv/git/emacs/org-mode.git, after waiting 15 minutes all I see is:

❯ git fetch origin
mux_client_request_session: read from master failed: Broken pipe

Similarly, ssh -email is unavailable- does not succeed. With ssh -v -email is unavailable- I see the following:

OpenSSH_8.9p1, OpenSSL 1.1.1q  5 Jul 2022
debug1: Reading configuration data /home/tec/.ssh/config
debug1: /home/tec/.ssh/config line 81: Applying options for *
debug1: Reading configuration data /usr/etc/ssh/ssh_config
debug1: /usr/etc/ssh/ssh_config line 19: include /usr/etc/ssh/ssh_config.d/*.conf matched no files
debug1: /usr/etc/ssh/ssh_config line 25: include /etc/ssh/ssh_config.d/*.conf matched no files
debug1: /usr/etc/ssh/ssh_config line 27: Applying options for *
debug1: auto-mux: Trying existing master
debug1: multiplexing control connection
debug2: fd 13 setting O_NONBLOCK
debug3: fd 13 is O_NONBLOCK
debug1: channel 5: new [mux-control]
debug3: channel_post_mux_listener: new mux channel 5 fd 13
debug3: mux_master_read_cb: channel 5: hello sent
debug3: mux_master_read_cb: channel 5 packet type 0x00000001 len 4
debug2: mux_master_process_hello: channel 5 client version 4
debug3: mux_master_read_cb: channel 5 packet type 0x10000004 len 4
debug2: mux_master_process_alive_check: channel 5: alive check
debug3: mux_master_read_cb: channel 5 packet type 0x10000002 len 70
debug2: mux_master_process_new_session: channel 5: request tty 1, X 0, agent 0, subsys 0, term "xterm-256color", cmd "", env 1
debug3: mux_master_process_new_session: got fds stdin 14, stdout 15, stderr 16
debug1: channel 6: new [client-session]
debug2: mux_master_process_new_session: channel_new: 6 linked to control channel 5
debug2: channel 6: send open
debug3: send packet: type 90

It would be good if I could actually push and pull commits.

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by yantar92 (Posted a comment)
  • -email is unavailable- added by rwp (Posted a comment)
  • -email is unavailable- added by rwp
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-09-08 rwp Carbon-Copy- Added -email is unavailable-

    Back to the top

    Powered by Savane 3.13-3230.
    Corresponding source code