dutchcoders/transfer.sh
1
0
Fork 0
mirror of https://github.com/dutchcoders/transfer.sh.git synced 2026-02-03 06:03:25 +00:00
Code Issues 48 Actions Packages Projects Releases Wiki Activity

transfer.sh Down? #371

New Issue
Closed
opened 2026-01-19 18:30:03 +00:00 by michael · 13 comments
michael commented 2026-01-19 18:30:03 +00:00
Owner
Copy Link

Originally created by @songgao on GitHub.

Hi there! Thanks for making and hosting such a useful service!

It looks like there's some issue with the backend right now?

$ curl -v https://transfer.sh/
*   Trying 54.77.221.1...
* Connected to transfer.sh (54.77.221.1) port 443 (#0)
* TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate: transfer.sh
* Server certificate: COMODO RSA Domain Validation Secure Server CA
* Server certificate: COMODO RSA Certification Authority
* Server certificate: AddTrust External CA Root
> GET / HTTP/1.1
> Host: transfer.sh
> User-Agent: curl/7.43.0
> Accept: */*
>
< HTTP/1.1 503 Service Unavailable: Back-end server is at capacity
< Content-Length: 0
< Connection: keep-alive
<
* Connection #0 to host transfer.sh left intact
Originally created by @songgao on GitHub. Hi there! Thanks for making and hosting such a useful service! It looks like there's some issue with the backend right now? ``` $ curl -v https://transfer.sh/ * Trying 54.77.221.1... * Connected to transfer.sh (54.77.221.1) port 443 (#0) * TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 * Server certificate: transfer.sh * Server certificate: COMODO RSA Domain Validation Secure Server CA * Server certificate: COMODO RSA Certification Authority * Server certificate: AddTrust External CA Root > GET / HTTP/1.1 > Host: transfer.sh > User-Agent: curl/7.43.0 > Accept: */* > < HTTP/1.1 503 Service Unavailable: Back-end server is at capacity < Content-Length: 0 < Connection: keep-alive < * Connection #0 to host transfer.sh left intact ```
michael commented 2026-01-19 18:30:04 +00:00
Author
Owner
Copy Link

@nl5887 commented on GitHub:

Don't expect that to solve this issue. But lets see first how it works without docker (they are running just one docker container per vm), so the docker container isn't really necessary. Was only for easy deployment, and that isn't too difficult to script.

@nl5887 commented on GitHub: Don't expect that to solve this issue. But lets see first how it works without docker (they are running just one docker container per vm), so the docker container isn't really necessary. Was only for easy deployment, and that isn't too difficult to script.
michael commented 2026-01-19 18:30:04 +00:00
Author
Owner
Copy Link

@nl5887 commented on GitHub:

Thanks for noticing. Docker and Elastic Beanstalk failed recovering from the docker process crashing. I've restarted everything and will remove the docker layer.

@nl5887 commented on GitHub: Thanks for noticing. Docker and Elastic Beanstalk failed recovering from the docker process crashing. I've restarted everything and will remove the docker layer.
michael commented 2026-01-19 18:30:04 +00:00
Author
Owner
Copy Link

@songgao commented on GitHub:

Thanks @nl5887 for the fast response! I'm gonna close the issue then.

Have you considered CoreOS? :)

@songgao commented on GitHub: Thanks @nl5887 for the fast response! I'm gonna close the issue then. Have you considered CoreOS? :)
michael commented 2026-01-19 18:30:04 +00:00
Author
Owner
Copy Link

@songgao commented on GitHub:

Got you. Was it docker itself, or the transfersh-server process within the container that crashed? I mentioned CoreOS mainly because of the rkt runtime. It has a simpler process model and is easier to manage.

But anyway hope the issue presents itself soon and gets solved!

@songgao commented on GitHub: Got you. Was it docker itself, or the `transfersh-server` process within the container that crashed? I mentioned CoreOS mainly because of the `rkt` runtime. It has a [simpler process model](https://coreos.com/rkt/docs/latest/rkt-vs-other-projects.html#process-model) and is easier to manage. But anyway hope the issue presents itself soon and gets solved!
michael commented 2026-01-19 18:30:04 +00:00
Author
Owner
Copy Link

@nl5887 commented on GitHub:

It was docker itself, not the binary. And strange this is also that this isn't detected by Amazon Elastic Beanstalk, because there are multiple instances. It just said that it failed, but didn't took appropriate action.

@nl5887 commented on GitHub: It was docker itself, not the binary. And strange this is also that this isn't detected by Amazon Elastic Beanstalk, because there are multiple instances. It just said that it failed, but didn't took appropriate action.
michael commented 2026-01-19 18:30:04 +00:00
Author
Owner
Copy Link

@nl5887 commented on GitHub:

Actually I found out that the difference between 1.4.2 and 1.6 in SSL
handling was causing the issue. I was reading and writing to S3 with https,
causing the cpu to overflow. For now this has been solved by not https 'ing
internal traffic.

On Fri, May 20, 2016 at 8:46 PM Song Gao notifications@github.com wrote:

This is a pretty long shot, but was the error in Accept() and something
like "ran out of file descriptors" by any chance? I got bit by that once
and solved by setting Timeouts for http stuff

—
You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub
https://github.com/dutchcoders/transfer.sh/issues/51#issuecomment-220687682

Remco Verhoef

gpg: https://keybase.io/remcov/key.asc
personal twitter: @remco_verhoef
twitter: @dutchcoders
blog: blog.dutchcoders.io

@nl5887 commented on GitHub: Actually I found out that the difference between 1.4.2 and 1.6 in SSL handling was causing the issue. I was reading and writing to S3 with https, causing the cpu to overflow. For now this has been solved by not https 'ing internal traffic. On Fri, May 20, 2016 at 8:46 PM Song Gao notifications@github.com wrote: > This is a pretty long shot, but was the error in Accept() and something > like "ran out of file descriptors" by any chance? I got bit by that once > and solved by setting Timeouts for http stuff > > — > You are receiving this because you were mentioned. > > Reply to this email directly or view it on GitHub > https://github.com/dutchcoders/transfer.sh/issues/51#issuecomment-220687682 > > ## --- Remco Verhoef gpg: https://keybase.io/remcov/key.asc personal twitter: @remco_verhoef twitter: @dutchcoders blog: blog.dutchcoders.io
michael commented 2026-01-19 18:30:04 +00:00
Author
Owner
Copy Link

@sophuric commented on GitHub:

I'm having the same issue. I'm using restSharp. Whyyy???

@sophuric commented on GitHub: I'm having the same issue. I'm using [restSharp](http://restsharp.org/). <sup>_Whyyy???_</sup>
michael commented 2026-01-19 18:30:04 +00:00
Author
Owner
Copy Link

@songgao commented on GitHub:

This is a pretty long shot, but was the error in Accept() and something like "ran out of file descriptors" by any chance? I got bit by that once and solved by setting Timeouts for http stuff

@songgao commented on GitHub: This is a pretty long shot, but was the error in `Accept()` and something like "ran out of file descriptors" by any chance? I got bit by that once and solved by setting Timeouts for `http` stuff
michael commented 2026-01-19 18:30:04 +00:00
Author
Owner
Copy Link

@dschep commented on GitHub:

@nl5887 is https://transfer.sh down again?

$ curl -I https://transfer.sh
HTTP/1.1 503 Service Unavailable: Back-end server is at capacity
Connection: keep-alive
@dschep commented on GitHub: @nl5887 is https://transfer.sh down again? ``` shell $ curl -I https://transfer.sh HTTP/1.1 503 Service Unavailable: Back-end server is at capacity Connection: keep-alive ```
michael commented 2026-01-19 18:30:04 +00:00
Author
Owner
Copy Link

@songgao commented on GitHub:

Interesting. But high CPU load shouldn't cause process to be killed, right? Was it using a lot of memory?

Just genuinely interested in the root cause :D

@songgao commented on GitHub: Interesting. But high CPU load shouldn't cause process to be killed, right? Was it using a lot of memory? Just genuinely interested in the root cause :D
michael commented 2026-01-19 18:30:04 +00:00
Author
Owner
Copy Link

@mckaygerhard commented on GitHub:

hi @wooden-utensil , @songgao , as explained in comment 51#issuecomment-219301538 it's not down.. just internal process problem..

@mckaygerhard commented on GitHub: hi @wooden-utensil , @songgao , as explained in comment 51#issuecomment-219301538 it's not down.. just internal process problem..
michael commented 2026-01-19 18:30:04 +00:00
Author
Owner
Copy Link

@sophuric commented on GitHub:

@nl5887 is https://transfer.sh down again?

$ curl -I https://transfer.sh
HTTP/1.1 503 Service Unavailable: Back-end server is at capacity
Connection: keep-alive

You can check down for everyone or just me.

@sophuric commented on GitHub: > @nl5887 is https://transfer.sh down again? > > ```shell > $ curl -I https://transfer.sh > HTTP/1.1 503 Service Unavailable: Back-end server is at capacity > Connection: keep-alive > ``` You can check [down for everyone or just me](https://downforeveryoneorjustme.com/transfer.sh).
michael commented 2026-01-19 18:30:04 +00:00
Author
Owner
Copy Link

@g33k247 commented on GitHub:

curl -I https://transfer.sh
curl: (7) Failed to connect to transfer.sh port 443: Connection refused

@g33k247 commented on GitHub: curl -I https://transfer.sh curl: (7) Failed to connect to transfer.sh port 443: Connection refused
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
docker
enhancement
hacktoberfest
help wanted
invalid
question
storage provider
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
michael
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: dutchcoders/transfer.sh#371
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?