Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cargo publish timeouts always #4264

Closed
hasufell opened this issue Jul 9, 2017 · 10 comments
Closed

cargo publish timeouts always #4264

hasufell opened this issue Jul 9, 2017 · 10 comments
Labels
A-interacts-with-crates.io Area: interaction with registries C-bug Category: bug Command-publish

Comments

@hasufell
Copy link

hasufell commented Jul 9, 2017

Followed all instructions from http://doc.crates.io/crates-io.html and created a token etc.

Cargo version is cargo 0.21.0-nightly (abf01e1ed 2017-06-25). Also tried with stable, fails in the same way.

jule@localhost ~/git/rust-libnotify-sys $ cargo publish 
    Updating registry `https://github.com/rust-lang/crates.io-index`
   Packaging libnotify-sys v0.5.0 (file:///home/jule/git/rust-libnotify-sys)
   Verifying libnotify-sys v0.5.0 (file:///home/jule/git/rust-libnotify-sys)
    Updating registry `https://github.com/rust-lang/crates.io-index`
   Compiling bitflags v0.8.2
   Compiling pkg-config v0.3.9
   Compiling libc v0.2.26
   Compiling gtypes v0.2.0
   Compiling libnotify-sys v0.5.0 (file:///home/jule/git/rust-libnotify-sys/target/package/libnotify-sys-0.5.0)
   Compiling gio-sys v0.3.4
   Compiling glib-2-0-sys v0.46.4
   Compiling gobject-2-0-sys v0.46.4
   Compiling gobject-sys v0.3.4
   Compiling gdk-pixbuf-sys v0.3.4
   Compiling glib-sys v0.3.4
    Finished dev [unoptimized + debuginfo] target(s) in 12.95 secs
   Uploading libnotify-sys v0.5.0 (file:///home/jule/git/rust-libnotify-sys)
error: [28] Timeout was reached (Operation too slow. Less than 10 bytes/sec transferred the last 30 seconds)

I don't see any useful way to debug this. It basically doesn't tell me anything, where the error happens, why etc.

@alexcrichton
Copy link
Member

cc @carols10cents do you know if crates.io had any hiccups over the weekend?

@carols10cents
Copy link
Member

I saw H28 Client Connection Idle errors in the logs around the time that @hasufell reported this in IRC, but I didn't see any systemic hiccups. This sounds similar to the issue we had reported to help@crates.io from Dennis April 8/9, but I don't think we ever figured that out.

@milibopp
Copy link

milibopp commented Aug 5, 2017

I have the same issue. I can't publish anything, although I am on a stable connection (I can browse crates.io without issue, anyway.) I'm using cargo 0.18.0.

@milibopp
Copy link

As mentioned in rust-lang/rust#43658, my problem vanished when I switched to another wifi. So perhaps it was just a network issue of some sort.

@carols10cents carols10cents added A-interacts-with-crates.io Area: interaction with registries C-bug Category: bug Command-publish labels Aug 30, 2017
@hasufell
Copy link
Author

hasufell commented Sep 1, 2017

Problem didn't vanish here. Still the same, reproducible on 2 machines.

@jan-hudec
Copy link

jan-hudec commented Oct 3, 2017

Seen this today and it was clearly problems somewhere between the ISP and S3. On different internet connection it didn't happen.

It would help if cargo printed the URLs and addresses it's trying to download from or upload to in verbose mode so one can diagnose it with curl, traceroute and similar tools.

@bgermann
Copy link

bgermann commented Feb 17, 2018

I get the same error. If I set a larger timeout, the following error is printed:

error: failed to get a 200 OK response, got 499
headers:
  HTTP/1.1 100 Continue

  HTTP/1.1 499 Client Disconnected
  Connection: keep-alive
  Server: Cowboy
  Date: Sat, 17 Feb 2018 21:17:07 GMT
  Content-Length: 506
  Content-Type: text/html; charset=utf-8
  Cache-Control: no-cache, no-store

body:
<!DOCTYPE html>
  <html>
    <head>
      <meta name="viewport" content="width=device-width, initial-scale=1">
      <meta charset="utf-8">
      <title>Application Error</title>
      <style media="screen">
        /* ... */
      </style>
    </head>
    <body>
      <iframe src="//www.herokucdn.com/error-pages/application-error.html"></iframe>
    </body>
  </html>

@bgermann
Copy link

bgermann commented Feb 17, 2018

I am on a Dual-Stack Lite Internet connection. Heroku is IPv4-only. I guess this could be the cause as the same laptop can publish on another IPv4 only network.

Debugging curl I could see that the upload was fine before the error was printed.

@stale
Copy link

stale bot commented Sep 16, 2018

As there hasn't been any activity here in over 6 months I've marked this as stale and if no further activity happens for 7 days I will close it.

I'm a bot so this may be in error! If this issue should remain open, could someone (the author, a team member, or any interested party) please comment to that effect?

The team would be especially grateful if such a comment included details such as:

  • Is this still relevant?
  • If so, what is blocking it?
  • Is it known what could be done to help move this forward?

Thank you for contributing!

(The cargo team is currently evaluating the use of Stale bot, and using #6035 as the tracking issue to gather feedback.)

If you're reading this comment from the distant future, fear not if this was closed automatically. If you believe it's still an issue please leave a comment and a team member can reopen this issue. Opening a new issue is also acceptable!

@stale stale bot added the stale label Sep 16, 2018
@stale
Copy link

stale bot commented Oct 18, 2018

As I didn't see any updates in 30 days I'm going to close this. Please see the previous comment for more information!

@stale stale bot closed this as completed Oct 18, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-interacts-with-crates.io Area: interaction with registries C-bug Category: bug Command-publish
Projects
None yet
Development

No branches or pull requests

6 participants