| Summary: | rsync://147.32.127.222/gentoo-portage not sending file list | ||
|---|---|---|---|
| Product: | Mirrors | Reporter: | Raphael Das Gupta <bugs.gentoo.org> |
| Component: | Server Problem | Assignee: | Mirror Admins <mirror-admin> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | burn, james |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | quote from terminal output of `emerge --sync' | ||
Created attachment 111404 [details]
quote from terminal output of `emerge --sync'
This is the output down to the message where emerge --rsync hangs.
Confirmed, rsync is broken, sits at receiving file list ... , however no data is recieved. Hmmm, this rsync mirror IS working, it is just extremely slow to build the file list
[10:02:10]<root@rage:~> SYNC='rsync://147.32.127.222/gentoo-portage' emerge --sync
>>> Updating Portage cache: 100%
[10:25:57]<root@rage:~>
ok, now it is really broken....
@ERROR: chroot failed
rsync error: error starting client-server protocol (code 5) at main.c(1386) [receiver=2.6.9]
>>> Retrying...
Seems alive for now. Will give it another chance... |
rsyncing from rsync://147.32.127.222/gentoo-portage stopps at the "recieving file list ..." message Reproducible: Sometimes Steps to Reproduce: 1. a) run $> sudo emerge --sync with SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" in your /etc/make.conf b) for sake of reproduction one might set SYNC="rsync://147.32.127.222/gentoo-portage" 2. If the mirror-rotation connects you to rsync://147.32.127.222/gentoo-portage of if you have taken Reproduction Step 1.b) then you get the results described in 'Actual Results' Actual Results: When the terminal has displayed (see Attachment) "receiving file list ..." one of the following happens: In about 80% of the cases, the process just stays here, until it's being killed. In about 15% of the cases, the process continues after a long wait (several minutes), finishishing rsyncing as expected. In about 5 % of the cases, the process runs through without ever being delayed. I didn't do any serious statistics here at all, so these percentages are more like 'felt values'. Expected Results: rsyncing should run through without being delayed for longer than some seconds, like it is on all the other gentoo-portage mirrors I was being connected to until now, OR the server should state in a message that one's IP is banned for rsyncing too much (like it could happen when trying to reproduce this bug, I guess)