New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 675345 link

Starred by 3 users

Issue metadata

Status: Fixed
Owner:
User never visited
Closed: Jan 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 0
Type: Bug



Sign in to add a comment

Cloning from chromium.googlesource.com stalls

Project Member Reported by sdefresne@chromium.org, Dec 17 2016

Issue description

Today, trying to clone some repository from chromium.googlesource.com just stalls. This has been experienced by multiple individual developers (in cc:) working from home (both when connected to Google VPN or not) but also from corp machine (when ssh-ing to them over VPN) and also by bots (see for example https://uberchromegw.corp.google.com/i/internal.bling.tryserver/builders/canary-device/builds/311).

Here is the output of git clone when setting GIT_CURL_VERBOSE=1. I've stopped the command with ^C after a couple of minutes because nothing happens (no network packets, no cpu used, the app just stalls there).

$ GIT_CURL_VERBOSE=1 git clone https://chromium.googlesource.com/external/github.com/material-components/material-components-ios src
Cloning into 'src'...
* Couldn't find host chromium.googlesource.com in the .netrc file; using defaults
*   Trying 74.125.133.82...
* Connected to chromium.googlesource.com (74.125.133.82) port 443 (#0)
* TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate: *.googlecode.com
* Server certificate: Google Internet Authority G2
* Server certificate: GeoTrust Global CA
> GET /external/github.com/material-components/material-components-ios/info/refs?service=git-upload-pack HTTP/1.1
Host: chromium.googlesource.com
User-Agent: git/2.10.1.613.g6021889
Accept: */*
Accept-Encoding: gzip
Cookie: XXXXX-Removed-As-Not-Relevant-XXXXX
Pragma: no-cache

< HTTP/1.1 200 OK
< Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
< Expires: Fri, 01 Jan 1980 00:00:00 GMT
< Pragma: no-cache
< Cache-Control: no-cache, max-age=0, must-revalidate
< Content-Type: application/x-git-upload-pack-advertisement
< Content-Encoding: gzip
< Date: Sat, 17 Dec 2016 11:53:04 GMT
< X-Content-Type-Options: nosniff
< X-Frame-Options: SAMEORIGIN
< X-XSS-Protection: 1; mode=block
< Server: GSE
< Alt-Svc: quic=":443"; ma=2592000; v="35,34"
< Transfer-Encoding: chunked
< 
* Connection #0 to host chromium.googlesource.com left intact
* Couldn't find host chromium.googlesource.com in the .netrc file; using defaults
* Found bundle for host chromium.googlesource.com: 0x7fdd9ed000a0 [can pipeline]
* Re-using existing connection! (#0) with host chromium.googlesource.com
* Connected to chromium.googlesource.com (74.125.133.82) port 443 (#0)
> POST /external/github.com/material-components/material-components-ios/git-upload-pack HTTP/1.1
Host: chromium.googlesource.com
User-Agent: git/2.10.1.613.g6021889
Accept-Encoding: gzip
Cookie: XXXXX-Removed-As-Not-Relevant-XXXXX
Content-Type: application/x-git-upload-pack-request
Accept: application/x-git-upload-pack-result
Content-Encoding: gzip
Content-Length: 1892

* upload completely sent off: 1892 out of 1892 bytes
^C


 
Cc: rohitrao@chromium.org
Labels: -Pri-0 Pri-1
Reducing priority as it only occurs for https://chromium.googlesource.com/external/github.com/material-components/material-components-ios, not other repositories.

Comment 2 by mmoss@chromium.org, Dec 19 2016

Components: -Infra Infra>Git
Labels: Infra-Troopers
This is happening again, this time for a regular git fetch. Could this be due to really low quota for that repository?
Cc: -rohitrao@chromium.org pinkerton@chromium.org rohit...@chromium.orgm justincohen@chromium.org
Labels: -Pri-1 Pri-0
It appears that the fetch or clone eventually complete. As data point, my fetch completed after making no apparent progress for almost 9 minutes (8:43). Justin also reported a git clone taking more than 20 minutes.

Can someone investigate whether the repository is incorrectly configured (it was created last Thursday/Friday)? Maybe there is not enough quota. This is going to hurt everyone working on Chrome on iOS (including the bots).
Cc: -rohit...@chromium.orgm smut@chromium.org rohitrao@chromium.org

Comment 6 by s...@google.com, Dec 20 2016

Cc: -smut@chromium.org
Owner: smut@chromium.org
Status: ExternalDependency (was: Untriaged)
We cannot tweak quotas. The repository was created the same way as all others, however.

Filed https://b.corp.google.com/issues/33760128 for gerritcodereview-team.
Project Member

Comment 7 by sheriffbot@chromium.org, Jan 2 2017

Pri-0 bugs are critical regressions or serious emergencies, and this bug has not been updated in three days. Could you please provide an update, or adjust the priority to a more appropriate level if applicable?

If a fix is in active development, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Labels: Disable-Nags

Comment 9 by s...@google.com, Jan 18 2017

Status: Fixed (was: ExternalDependency)

Sign in to add a comment