Aws-cli: Das Hochladen von Dateien von EC2-Instanzen auf S3 schlägt bei einigen Instanztypen fehl

Erstellt am 6. Feb. 2014  ·  41Kommentare  ·  Quelle: aws/aws-cli

Wir haben ein sehr seltsames Problem. Wir laden große (10 Millionen) Dateien von einer EC2-Instanz in einen S3-Bucket in derselben Region hoch. Wir verwenden aws s3 cp für die Upload- und Instanzrollen zur Authentifizierung.

Wenn wir eine m1.small EC2-Instanz verwenden, funktioniert der Upload einwandfrei. Wenn wir jedoch die Instanzgröße erhöhen (wir haben m1.large und m3.large ausprobiert), schlägt der Upload fehl.

Hier ist der Fehler, den wir bekommen:

upload failed: <file> to <s3-address>
HTTPSConnectionPool(host='<bucket>.s3.amazonaws.com', port=443): Max retries exceeded with url: <s2-key>?partNumber=2&uploadId=Hw6FZhXeH03ZzzCtxu2XcsspmpN2lx83GxWGzrJ96I81XlajjjNCxsSj0vs0BIbf_xJmzfdZwZY_UzUL3NCT57rpqEwIuLD1qryr7KKjlR6rA0YIW_ltopZQkoo32i0qTPUAlBc55WRAYxjwJ8Iw1A-- (Caused by <class 'socket.error'>: [Errno 104] Connection reset by peer)

Dies ist vollständig reproduzierbar - ein solcher Upload war nach zehn Versuchen noch nie erfolgreich. Wir haben das Problem bei einer Instanz von m1.small in Hunderten von Versuchen noch nie gesehen.

Wir sind auf dieses Problem mit 10 Millionen Dateien gestoßen. Wir haben festgestellt, dass es bis zu etwa 1 Million reproduzierbar ist. Viel weniger als das und es funktioniert jedes Mal gut.

Irgendwelche Ideen darüber, was los ist, wären sehr dankbar.

bug

Hilfreichster Kommentar

@uldall Wenn Sie dies noch nicht gelöst haben, wurde dies für mich durch die Installation der neuesten Version von aws-cli behoben - die neueste Version von apt-get ist veraltet und Sie müssen sie mit pip installieren. Hier sind die Anweisungen:
https://www.slashroot.in/how-to-install-and-configure-aws-cli-on-ubuntu-16-04

Alle 41 Kommentare

Welche Version der CLI verwenden Sie? Dies sieht aus wie https://github.com/aws/aws-cli/pull/594 , das in 1.2.11 behoben wurde

Eigentlich war dieses Problem für Downloads, dieses ist für Uploads, also ist es wahrscheinlich ein anderes Problem. Ich muss das weiter untersuchen. Wenn Sie ein --debug -Protokoll dazu bereitstellen könnten, würde dies bei der Fehlerbehebung helfen.

Auch ungefähr wie viele 10M-Dateien laden Sie gleichzeitig hoch?

Ich habe auch Probleme beim Hochladen auf s3, aber von meinem Laptop (OSX-Außenseiter). Eine 424-KB-Datei ist fehlgeschlagen.
und eine 344KB Datei funktionierte. Ich lade jeweils eine Datei mit den folgenden Versionen hoch:

awscli==1.2.13
boto==2.24.0
botocore==0.33.0

Der Fehler ist der gleiche wie im ursprünglichen Beitrag:

upload failed: ./test to s3://<bucket>/deploys/test HTTPSConnectionPool(host='bnch.s3.amazonaws.com', port=443): Max retries exceeded with url: /deploys/test (Caused by <class 'socket.error'>: [Errno 32] Broken pipe)

Ich habe es mit --debug ausgeführt, und hier ist der Teil, der es immer wieder versucht:

2014-02-06 21:20:17,138 - botocore.retryhandler - DEBUG - Retry needed, action of: 3.28890874908
2014-02-06 21:20:17,138 - botocore.endpoint - DEBUG - Response received to retry, sleeping for 3.28890874908 seconds
2014-02-06 21:20:20,428 - botocore.awsrequest - DEBUG - Rewinding stream: <open file u'<redacted>/test', mode 'rb' at 0x101dc6c90>
2014-02-06 21:20:20,428 - botocore.endpoint - DEBUG - Sending http request: <PreparedRequest [PUT]>
2014-02-06 21:20:20,429 - botocore.vendored.requests.packages.urllib3.connectionpool - INFO - Starting new HTTPS connection (4): <bucket>.s3.amazonaws.com
2014-02-06 21:20:21,693 - botocore.hooks - DEBUG - Event needs-retry.s3.PutObject: calling handler <botocore.retryhandler.RetryHandler object at 0x101e0d550>
2014-02-06 21:20:21,693 - botocore.retryhandler - DEBUG - retry needed, retryable exception caught: HTTPSConnectionPool(host='<bucket>.s3.amazonaws.com', port=443): Max retries exceeded with url: /deploys/test (Caused by <class 'socket.error'>: [Errno 32] Broken pipe)
Traceback (most recent call last):
  File "<redacted>/lib/python2.7/site-packages/botocore/retryhandler.py", line 262, in _should_retry
    return self._checker(attempt_number, response, caught_exception)
  File "<redacted>/lib/python2.7/site-packages/botocore/retryhandler.py", line 310, in __call__
    caught_exception)
  File "<redacted>/lib/python2.7/site-packages/botocore/retryhandler.py", line 219, in __call__
    return self._check_caught_exception(attempt_number, caught_exception)
  File "<redacted>/lib/python2.7/site-packages/botocore/retryhandler.py", line 352, in _check_caught_exception
    raise caught_exception
ConnectionError: HTTPSConnectionPool(host='<bucket>.s3.amazonaws.com', port=443): Max retries exceeded with url: /deploys/test (Caused by <class 'socket.error'>: [Errno 32] Broken pipe)
2014-02-06 21:20:21,693 - botocore.retryhandler - DEBUG - Retry needed, action of: 2.598356941
2014-02-06 21:20:21,693 - botocore.endpoint - DEBUG - Response received to retry, sleeping for 2.598356941 seconds
2014-02-06 21:20:24,293 - botocore.awsrequest - DEBUG - Rewinding stream: <open file u'<redacted>/test', mode 'rb' at 0x101dc6c90>
2014-02-06 21:20:24,293 - botocore.endpoint - DEBUG - Sending http request: <PreparedRequest [PUT]>
2014-02-06 21:20:24,294 - botocore.vendored.requests.packages.urllib3.connectionpool - INFO - Starting new HTTPS connection (5): <bucket>.s3.amazonaws.com
2014-02-06 21:20:25,888 - botocore.hooks - DEBUG - Event needs-retry.s3.PutObject: calling handler <botocore.retryhandler.RetryHandler object at 0x101e0d550>
2014-02-06 21:20:25,888 - awscli.customizations.s3.tasks - DEBUG - <redacted>/test upload failure: HTTPSConnectionPool(host='<bucket>.s3.amazonaws.com', port=443): Max retries exceeded with url: /deploys/test (Caused by <class 'socket.error'>: [Errno 32] Broken pipe)
2014-02-06 21:20:25,888 - botocore.operation - DEBUG - Operation:PutObject called with kwargs: {'body': <open file u'<redacted>/test', mode 'rb' at 0x101e61d20>, 'bucket': u'<bucket>', 'key': u'deploys/test'}
2014-02-06 21:20:25,889 - botocore.endpoint - DEBUG - Making request for Operation:PutObject (verify_ssl=True) with params: {'headers': {}, 'uri_params': {u'Bucket': u'<bucket>', u'Key': u'deploys/test'}, 'payload': <botocore.payload.Payload object at 0x101fc3ed0>}
2014-02-06 21:20:25,889 - botocore.endpoint - DEBUG - Building URI for rest endpoint.
2014-02-06 21:20:25,889 - botocore.endpoint - DEBUG - Templated URI path: /{Bucket}/{Key}
2014-02-06 21:20:25,889 - botocore.endpoint - DEBUG - Templated URI query_params:
2014-02-06 21:20:25,889 - botocore.endpoint - DEBUG - Rendered path: /<bucket>/deploys/test
2014-02-06 21:20:25,889 - botocore.endpoint - DEBUG - Rendered query_params:
2014-02-06 21:20:25,890 - botocore.hooks - DEBUG - Event before-auth.s3: calling handler <function fix_s3_host at 0x101b24410>
2014-02-06 21:20:25,890 - botocore.handlers - DEBUG - Checking for DNS compatible bucket for: https://s3-us-west-2.amazonaws.com/<bucket>/deploys/test
2014-02-06 21:20:25,890 - botocore.handlers - DEBUG - URI updated to: https://<bucket>.s3.amazonaws.com/deploys/test
2014-02-06 21:20:25,890 - botocore.auth - DEBUG - Calculating signature using hmacv1 auth.
2014-02-06 21:20:25,890 - botocore.auth - DEBUG - HTTP request method: PUT
2014-02-06 21:20:25,890 - botocore.auth - DEBUG - StringToSign:
PUT


Fri, 07 Feb 2014 05:20:25 GMT
/<bucket>/deploys/test
2014-02-06 21:20:25,891 - botocore.endpoint - DEBUG - Sending http request: <PreparedRequest [PUT]>
2014-02-06 21:20:25,891 - botocore.vendored.requests.packages.urllib3.connectionpool - INFO - Starting new HTTPS connection (6): <bucket>.s3.amazonaws.com
2014-02-06 21:20:27,373 - botocore.hooks - DEBUG - Event needs-retry.s3.PutObject: calling handler <botocore.retryhandler.RetryHandler object at 0x101e0d550>
2014-02-06 21:20:27,374 - botocore.retryhandler - DEBUG - retry needed, retryable exception caught: HTTPSConnectionPool(host='<bucket>.s3.amazonaws.com', port=443): Max retries exceeded with url: /deploys/test (Caused by <class 'socket.error'>: [Errno 32] Broken pipe)
Traceback (most recent call last):
  File "<redacted>/lib/python2.7/site-packages/botocore/retryhandler.py", line 262, in _should_retry
    return self._checker(attempt_number, response, caught_exception)
  File "<redacted>/lib/python2.7/site-packages/botocore/retryhandler.py", line 310, in __call__
    caught_exception)
  File "<redacted>/lib/python2.7/site-packages/botocore/retryhandler.py", line 219, in __call__
    return self._check_caught_exception(attempt_number, caught_exception)
  File "<redacted>/lib/python2.7/site-packages/botocore/retryhandler.py", line 352, in _check_caught_exception
    raise caught_exception
ConnectionError: HTTPSConnectionPool(host='<bucket>.s3.amazonaws.com', port=443): Max retries exceeded with url: /deploys/test (Caused by <class 'socket.error'>: [Errno 32] Broken pipe)
2014-02-06 21:20:27,374 - botocore.retryhandler - DEBUG - Retry needed, action of: 0.627294998584
2014-02-06 21:20:27,374 - botocore.endpoint - DEBUG - Response received to retry, sleeping for 0.627294998584 seconds

Wir verwenden Version 1.2.13. Wir haben ungefähr 200 dieser Dateien zum Hochladen, aber wir machen es in Serie. Das Problem tritt immer beim ersten auf.

Hier ist das Debug-Protokoll des von Ihnen angeforderten Fehlers: https://gist.github.com/benbc/8861033.

Gibt es ein Update zu diesem Problem? Ich sehe genau das gleiche Problem beim Versuch, in einen neu erstellten Bucket hochzuladen.

Ja, ich glaube, dies sollte jetzt in Version 1.3.0 behoben werden. Ich glaube, die Hauptursache ist dieselbe wie https://github.com/aws/aws-cli/issues/544.

Können Sie es bitte mit der neuesten CLI-Version versuchen. Wenn das Problem weiterhin auftritt, fügen Sie bitte ein --debug-Protokoll hinzu, und ich werde das Problem erneut beheben.

Ich habe immer noch dieses Problem auf s3 hochgeladen, weder von meinem Laptop noch von einem Debian-Server. Die Datei ist ungefähr 100 MB groß. Ich lade jeweils eine Datei mit den folgenden Versionen hoch:

   aws-cli/1.3.1 Python/2.7.3 Linux/3.2.0-4-amd64
   aws-cli/1.3.1 Python/2.7.5 Darwin/13.0.0

Hier ist das Problem, das ich bekomme:

Max retries exceeded with url: <myfile>?partNumber=13&uploadId=bR1a29GdR1Qb0CW4fSDv9Vvi4PKJLF3eizWErF1SGvuMxUAh4vmHLmVQ7XjVSsFGmQi0N1U8KX5dR1uukEAMaAS8JxoQA89nJN2FFmQu2MRzIlrIzeMr4re5Zwvn3Hvv.n9IKm.OXOqy4NN87yohIA-- (Caused by <class 'socket.error'>: [Errno 104] Connection reset by peer)

Hier ist das Debug-Protokoll:

Wed, 19 Mar 2014 03:28:03 GMT
/<mybucket>/<myfile>?partNumber=9&uploadId=psq_ysXJSW9eplwLTW97ueGw1BMzG2qEXVoP9XiQsm06RP0_N_J_qPS1vZf4OOj0W33Bwdey2w4KNsbEltH_GIWO3jOQbcP64MEfTMd.OSUVsmZKsMIWCxZoqdbmspb1bD0YzAbG92F9R8pQQrXdkA--
2014-03-19 11:28:03,343 - botocore.endpoint - DEBUG - Sending http request: <PreparedRequest [PUT]>
partNumber=8&uploadId=psq_ysXJSW9eplwLTW97ueGw1BMzG2qEXVoP9XiQsm06RP0_N_J_qPS1vZf4OOj0W33Bwdey2w4KNsbEltH_GIWO3jOQbcP64MEfTMd.OSUVsmZKsMIWCxZoqdbmspb1bD0YzAbG92F9R8pQQrXdkA-- (Caused by <class 'socket.error'>: [Errno 104] Connection reset by peer)
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/botocore/retryhandler.py", line 262, in _should_retry
    return self._checker(attempt_number, response, caught_exception)
  File "/usr/local/lib/python2.7/dist-packages/botocore/retryhandler.py", line 310, in __call__
    caught_exception)
  File "/usr/local/lib/python2.7/dist-packages/botocore/retryhandler.py", line 219, in __call__
    return self._check_caught_exception(attempt_number, caught_exception)
  File "/usr/local/lib/python2.7/dist-packages/botocore/retryhandler.py", line 352, in _check_caught_exception
    raise caught_exception
ConnectionError: HTTPSConnectionPool(host='<mybucket>.s3.amazonaws.com', port=443): Max retries exceeded with url: /<myfile>?partNumber=8&uploadId=psq_ysXJSW9eplwLTW97ueGw1BMzG2qEXVoP9XiQsm06RP0_N_J_qPS1vZf4OOj0W33Bwdey2w4KNsbEltH_GIWO3jOQbcP64MEfTMd.OSUVsmZKsMIWCxZoqdbmspb1bD0YzAbG92F9R8pQQrXdkA-- (Caused by <class 'socket.error'>: [Errno 104] Connection reset by peer)
2014-03-19 11:28:05,374 - botocore.retryhandler - DEBUG - Retry needed, action of: 0.41042383996
2014-03-19 11:28:05,374 - botocore.endpoint - DEBUG - Response received to retry, sleeping for 0.41042383996 seconds
2014-03-19 11:28:05,579 - botocore.hooks - DEBUG - Event needs-retry.s3.UploadPart: calling handler <botocore.retryhandler.RetryHandler object at 0x308bfd0>
2014-03-19 11:28:05,580 - botocore.retryhandler - DEBUG - retry needed, retryable exception caught: HTTPSConnectionPool(host=<mybucket>.s3.amazonaws.com', port=443): Max retries exceeded with url: /<myfile>?partNumber=1&uploadId=psq_ysXJSW9eplwLTW97ueGw1BMzG2qEXVoP9XiQsm06RP0_N_J_qPS1vZf4OOj0W33Bwdey2w4KNsbEltH_GIWO3jOQbcP64MEfTMd.OSUVsmZKsMIWCxZoqdbmspb1bD0YzAbG92F9R8pQQrXdkA-- (Caused by <class 'socket.error'>: [Errno 104] Connection reset by peer)
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/botocore/retryhandler.py", line 262, in _should_retry
    return self._checker(attempt_number, response, caught_exception)
  File "/usr/local/lib/python2.7/dist-packages/botocore/retryhandler.py", line 310, in __call__
    caught_exception)
  File "/usr/local/lib/python2.7/dist-packages/botocore/retryhandler.py", line 219, in __call__
    return self._check_caught_exception(attempt_number, caught_exception)
  File "/usr/local/lib/python2.7/dist-packages/botocore/retryhandler.py", line 352, in _check_caught_exception
    raise caught_exception
ConnectionError: HTTPSConnectionPool(host='<mybucket>.s3.amazonaws.com', port=443): Max retries exceeded with url: /<myfile>?partNumber=1&uploadId=psq_ysXJSW9eplwLTW97ueGw1BMzG2qEXVoP9XiQsm06RP0_N_J_qPS1vZf4OOj0W33Bwdey2w4KNsbEltH_GIWO3jOQbcP64MEfTMd.OSUVsmZKsMIWCxZoqdbmspb1bD0YzAbG92F9R8pQQrXdkA-- (Caused by <class 'socket.error'>: [Errno 104] Connection reset by peer)

Dieses Problem wird immer noch mit aws cp und aws sync in einem neuen Bucket angezeigt. Kleinere Dateien haben kein Problem durchlaufen, größere Dateien schlagen zuverlässig fehl, wie hier und Nr. 544 beschrieben

aws --version
aws-cli/1.3.3 Python/2.7.5+ Linux/3.8.0-35-generic
>>> print botocore.__version__
>>> 0.37.0
upload failed: ./file.tar.gz to s3://mybucket/file.tar.gz
HTTPSConnectionPool(host='mybucket.s3.amazonaws.com', port=443): Max retries exceeded with url: /file.tar.gz?partNumber=... (Caused by <class 'socket.error'>: [Errno 104] Connection reset by peer)
curl https://mybucket.s3.amazonaws.com
<?xml version="1.0" encoding="UTF-8"?>
<Error><Code>TemporaryRedirect</Code><Message>Please re-send this request to the specified temporary endpoint. Continue to use the original request endpoint for future requests.</Message><RequestId>...</RequestId><Bucket>mybucket</Bucket><HostId>...</HostId><Endpoint>mybucket.s3-us-west-1.amazonaws.com</Endpoint></Error>

Wie andere berichtet haben, funktioniert dies jetzt einwandfrei, nachdem der TemporaryRedirect-Code gelöscht wurde -

$ curl https://mybucket.s3.amazonaws.com
<?xml version="1.0" encoding="UTF-8"?>
<Error><Code>AccessDenied</Code><Message>Access Denied</Message><RequestId>...</RequestId><HostId>...</HostId></Error>%

Ich habe immer noch dieses Problem mit Version 1.3.4 auf einem neuen Irland-Bucket.

ubuntu@ip-172-31-40-164:~$ aws --version
aws-cli/1.3.4 Python/2.7.5+ Linux/3.11.0-15-generic

Debug-Protokoll: https://gist.github.com/anonymous/9814978

Gleicher Fehler für mich bei Verwendung von 'aws s3 sync'
$ aws --version
aws-cli / 1.3.4 Python / 2.7.3 Linux / 3.2.0-57-virtual

Mein Eimer ist in Irland.

Debug-Protokoll: https://paste.buntux.org/?c511ef0a27305636#e1/B5RiyBuZq60LHmLNpZt59wz2zDyY2KVdjCM + mO7E =

edit: Ich habe an einem Bucket in der Region "US Standard" getestet -> kein Problem
edit2: Neue URL für das Debug-Protokoll https://paste.jeekajoo.eu/?c511ef0a27305636#e1/B5RiyBuZq60LHmLNpZt59wz2zDyY2KVdjCM + mO7E =

Ich öffne dieses Problem erneut. Nach dem Debuggen kann ich bestätigen, was andere gesagt haben. Dieses Problem tritt auf, wenn versucht wird, eine große Datei in einen neu erstellten Bucket hochzuladen, der sich nicht in der klassischen Region befindet.

Soweit ich weiß, wiederholt die CLI Anforderungen ordnungsgemäß und folgt 307 Weiterleitungen. Das Problem ist jedoch, dass die CLI die gesamte Anforderung sendet und dann auf eine Antwort wartet. S3 sendet jedoch sofort die 307-Antwort, bevor wir den Text gesendet haben. Schließlich wird nur die Verbindung geschlossen, und wenn wir noch dabei sind, den Körper zu streamen, wird die Antwort nicht angezeigt. Stattdessen erhalten wir den ConnectionError, wie in den verschiedenen Debug-Protokollen oben gezeigt.

Der normale Weg, dies zu beheben, wäre die Verwendung des Expect-100-Continue-Headers. Der von uns verwendete HTTP-Client (Anfragen) unterstützt dies jedoch nicht. Möglicherweise gibt es eine Möglichkeit, dies zu umgehen, aber ich muss mich in der Anforderungsbibliothek umsehen, um herauszufinden, wie dieses Problem am besten behoben werden kann.

Ich werde dieses Problem aktualisieren, wenn ich mehr weiß.

Irgendwelche Neuigkeiten?

Meine Tests zeigen, dass die AWS CLI auch dann einwandfrei funktioniert, wenn die Botobibliothek ausfällt. Was macht die AWS CLI anders?

Ich glaube nicht, dass es in der Anforderungsbibliothek Möglichkeiten gibt, dies zu umgehen. Ich denke, unsere beste Option (abgesehen vom Schreiben eines eigenen HTTP-Clients, der Expect 100 Continue unterstützt) ist eine bestimmte Problemumgehung im S3-Code.

Ich habe das auch gerade getroffen. Meine Datei ist nicht groß, nur ein paar Megabyte.

Abrufen mit einer 323 KB CSS-Datei.

Wenn ich an einem Fix für dieses Problem arbeite, wird es aktualisiert, wenn ich weitere Informationen habe.

Gleiches Problem beim Hochladen einer großen Datei (3 GB) in S3. Das Hochladen einer kleinen Datei ist in Ordnung.

upload failed: ../../tmp/anonymousAction.log.2014-05-12.tokyo1b-http-4-1.20140513T003001 to s3://between-data-analysis-temp/anonymousAction.log.2014-05-12.tokyo1b-http-4-1.20140513T003001
HTTPSConnectionPool(host='between-data-analysis-temp.s3.amazonaws.com', port=443): Max retries exceeded with url: /anonymousAction.log.2014-05-12.tokyo1b-http-4-1.20140513T003001?partNumber=6&uploadId=Wdj8309FlXToB8mXw6JHnz8Xf8f4ADIC2SiaM3a6foSDJXH9t7xLk2uFK_EgTtjMn.OyCWdTJjP9al3rgISEltpMwj9j77Irfjc5wqssG2zgnUKhXM2gEUU5QfAuH0kuJNg8deDipYvwBkE0r7k3Qw-- (Caused by <class 'socket.error'>: [Errno 104] Connection reset by peer)
... 

Meine aws Version;
aws-cli / 1.3.13 Python / 2.7.3 Linux / 3.2.0-61-virtual

Ich bekomme zeitweise ein ähnliches Problem (ungefähr 1 Datei pro 20, Dateien sind ungefähr 500 MB groß), wenn ich die Anforderungsbibliothek direkt verwende, während wir über unsere spezifische Speicher-API arbeiten. Dies wird von einer EC2-Instanz hochgeladen.

  File "/data/opi/upload.py", line 174, in upload
    response = requests.put(url, data=data, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/requests-2.1.0-py2.7.egg/requests /api.py", line 99, in put
    return request('put', url, data=data, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/requests-2.1.0-py2.7.egg/requests /api.py", line 44, in request
    return session.request(method=method, url=url, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/requests-2.1.0-py2.7.egg/requests /sessions.py", line 382, in request
    resp = self.send(prep, **send_kwargs)
  File "/usr/local/lib/python2.7/dist-packages/requests-2.1.0-py2.7.egg/requests /sessions.py", line 485, in send
    r = adapter.send(request, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/requests-2.1.0-py2.7.egg/requests /adapters.py", line 372, in send
    raise ConnectionError(e)
requests.exceptions.ConnectionError: HTTPSConnectionPool(host='our-bucket.s3.amazonaws.com', port=443): Max retries exceeded with url: /folder/subfolder/filename?Signature=XXX&Expires=1401262800&AWSAccessKeyId=YYY -amz-acl=private (Caused by <class 'socket.error'>: [Errno 104] Connection reset  by peer)

Nur ein Update, an dem noch gearbeitet wird. Der bisher praktikabelste Ansatz bestand darin, die Unterklasse HTTPConnection und zu versuchen, die erwartete 100-Fortsetzungslogik in unserer Unterklasse zu implementieren. Wir würden dies dann in die Verbindungspools von urllib3 ausloten, die von Anfragen erfasst werden (dies ist die von uns verwendete http-Bibliothek).

Ich glaube, ich habe eine mögliche Lösung, aber es müssen weitere Tests durchgeführt werden. Wird aktualisiert, wenn ich weitere Informationen habe.

@jamesls sobald du einen öffentlichen Zweig zum Testen hast, werde ich ihn verwenden :)

Hallo,

Da dies im Thread nicht explizit angegeben ist, können Sie den Befehl "aws" weiterhin verwenden, um Dateien in eine andere Region hochzuladen, indem Sie den Parameter --region angeben.

  • Dieser scheitert
    aws s3 cp ./really_big_file s3: // MY-BUCKET /
  • Dieser funktioniert
    aws --region eu-west-1 s3 cp ./really_big_file s3: // MY-BUCKET /

@ inedit00 Danke! Ich hatte keine Ahnung, dass dies mit dem Problem zusammenhängt.

Das Update hierfür finden Sie hier: https://github.com/boto/botocore/pull/303

Aber ich würde gerne mehr Tests dazu machen. Ich möchte auch sehen, was das Senden des erwarteten 100-Fortsetzungs-Headers für perf bewirkt.

Wir erhalten diesen Fehler auch beim Kopieren einer großen Datei (~ 3 GB) von lokal nach S3 (Irland). Verwenden von aws-cli / 1.3.17 Python / 2.6.6 Linux / 2.6.32-71.29.1.el6.x86_64 und Botocore 0.51.0.

Nur ein kurzes Update, das Update dafür war in Boto / Botocore # 303, aber wir haben eine Regression festgestellt, die nur in Python2.6 war, sodass wir die PR zurücksetzen mussten.

Ich denke, es ist immer noch möglich, dies zu beheben, aber es wird aufgrund interner Änderungen in httplib von python2.6 zu> python2.6 etwas invasiver sein. Ich werde dies aktualisieren, wenn ich weitere Informationen habe.

Ich konnte das Python2.6-Problem in der vorherigen PR beheben, um dieses Problem zu beheben. Alle Tests werden mit dieser Änderung bestanden, und ich kann bestätigen, dass das Problem behoben ist, dass keine großen Dateien in neu erstellte nicht standardmäßige S3-Buckets hochgeladen werden können. Bitte lassen Sie mich wissen, wenn Sie immer noch Probleme sehen, und bedanken Sie sich für Ihre Geduld, während wir dieses Problem behoben haben.

Danke für das Update @jamesls. In welcher awscli-Version befindet sich dieses Update?

Dies ist in der neuesten Version der CLI (v1.3.18) verfügbar.

Wenn jemand dies in Zukunft debuggen muss, werden Debug-Protokolle angezeigt, die sich auf den Header "Erwarten 100" beziehen:

2014-06-23 10:40:32,495 - Thread-4 - botocore.hooks - DEBUG - Event before-call.s3.UploadPart: calling handler <function add_expect_header at 0x10d3469b0>
2014-06-23 10:40:32,495 - Thread-4 - botocore.handlers - DEBUG - Adding expect 100 continue header to request.
2014-06-23 10:40:32,500 - Thread-4 - botocore.endpoint - DEBUG - Sending http request: <PreparedRequest [PUT]>
2014-06-23 10:40:32,502 - Thread-4 - botocore.awsrequest - DEBUG - Waiting for 100 Continue response.
2014-06-23 10:40:32,506 - Thread-4 - botocore.awsrequest - DEBUG - Received a non 100 Continue response from the server, NOT sending request body.
2014-06-23 10:40:32,512 - Thread-4 - botocore.awsrequest - DEBUG - Redirect received, rewinding stream: <awscli.customizations.s3.utils.ReadFileChunk object at 0x10d7f1450>
2014-06-23 10:40:32,512 - Thread-4 - botocore.awsrequest - DEBUG - Rewinding stream: <awscli.customizations.s3.utils.ReadFileChunk object at 0x10d7f1450>
2014-06-23 10:40:32,513 - Thread-4 - botocore.awsrequest - DEBUG - Waiting for 100 Continue response.
2014-06-23 10:40:32,533 - Thread-4 - botocore.awsrequest - DEBUG - 100 Continue response seen, now sending request body.
...
2014-06-23 10:40:34,530 - Thread-4 - awscli.errorhandler - DEBUG - HTTP Response Code: 200

Ich glaube, das ist immer noch ein Problem gemäß # 823.

Das sieht nach einem anderen Problem aus. Das Errno ist insbesondere anders.

habe das gleiche Problem.

upload failed: images1/1103/142_b2d35e8005321b582ce891ca835df65d_75.jpg to s3://opgirl-v2/images/images1/1103/142_b2d35e8005321b582ce891ca835df65d_75.jpg A client error (RequestTimeout) occurred when calling the PutObject operation: Your socket connection to the server was not read from or written to within the timeout period. Idle connections will be closed.
Cleaning up. Please wait...
upload failed: images1/1103/142_d0754d4c8708dc2d7c68cc27da2ad2fa_100.jpg to s3://opgirl-v2/images/images1/1103/142_d0754d4c8708dc2d7c68cc27da2ad2fa_100.jpg The write operation timed out
upload failed: images1/1103/1430_0a6a493f08b693789cba32fbbc6ade83_75.jpg to s3://opgirl-v2/images/images1/1103/1430_0a6a493f08b693789cba32fbbc6ade83_75.jpg ('Connection aborted.', error(104, 'Connection reset by peer'))
# aws --version
aws-cli/1.9.15 Python/2.6.6 Linux/3.2.0-0.bpo.1-amd64 botocore/1.3.15

Das Leistungslimit von AWS s3 erreichen?
https://stackoverflow.com/questions/23397460/error-handling-boto-error-104-connection-reset-by-peer

Ich habe das gleiche Problem. Dieser Thread ist ziemlich alt. Wird dieses Problem noch untersucht?

('Connection aborted.', ConnectionResetError(104, 'Connection reset by peer'))

# aws --version aws-cli/1.11.13 Python/3.5.2 Linux/4.4.0-1055-aws botocore/1.4.70

Konnte das gleiche Problem

`` ``

aws s3 cp /opt/tradetracker/dataStream/tracker-hits-2018-04-30_11:00:00.log s3: // tt-feeder-dumps
Upload fehlgeschlagen: ../dataStream/tracker-hits-2018-04-30_11:00:00.log to s3: // tt-feeder-dumps / tracker-Hits-2018-04-30_11: 00: 00.log ( 'Verbindung abgebrochen.', ConnectionResetError (104, 'Verbindung durch Peer zurückgesetzt'))

ls -hal /opt/tradetracker/dataStream/tracker-hits-2018-04-30_11:00:00.log
-rw-rw-rw- 1 www-Daten www-Daten 13M 30. April 13:56 /opt/tradetracker/dataStream/tracker-hits-2018-04-30_11:00:00.log

aws --version
aws-cli / 1.11.13 Python / 3.5.2 Linux / 4.4.0-1049-aws botocore / 1.4.70
`` ``

Das Gleiche gilt. +1
Dateigröße: 1G
aws-cli/1.15.12 Python/3.4.3 Linux/4.4.0-71-generic botocore/1.10.12


Für mein Setup wurde dies durch die Einstellung behoben:
s3 =
max_concurrent_requests = 5
max_bandwidth = 210 KB / s

in der .aws / config-Datei für das von mir verwendete Profil. Siehe hier: https://docs.aws.amazon.com/cli/latest/topic/s3-config.html#

Ich habe das gleiche Problem auch, als ich versuchte, eine Datei mit dem boto3-Python-Paket in den s3-Bucket hochzuladen.

Bis vor ungefähr 4 Tagen funktionierte es einwandfrei und seitdem gab es Probleme beim Hochladen.

Ich habe das gleiche Problem mit einem neu geschaffenen Eimer in der Region eu-west-1.

Befehl verwendet:
aws s3 sync . s3://<bucket_name> --profile test --region eu-west-1

$ aws --version
aws-cli/1.11.13 Python/3.5.2 Linux/4.13.0-45-generic botocore/1.4.70

Hängt dieses Problem mit dem Netzwerk zusammen, mit dem ich verbunden bin? Der Upload schlug fehl, als ich eine Verbindung zu einem 4G-Dongle hergestellt hatte, während bei der Verbindung zu meinem WLAN-Router alles in Ordnung war.

Aber der 4G-Dongle gab mir 10 Mbit / s Geschwindigkeit. Ich bin mir also nicht sicher, wo das Problem liegt

@uldall Wenn Sie dies noch nicht gelöst haben, wurde dies für mich durch die Installation der neuesten Version von aws-cli behoben - die neueste Version von apt-get ist veraltet und Sie müssen sie mit pip installieren. Hier sind die Anweisungen:
https://www.slashroot.in/how-to-install-and-configure-aws-cli-on-ubuntu-16-04

Am Ubuntu 18
Installieren Sie Python 3
sudo apt-get install python3-pip
pip3 installiere awscli --upgrade --user
aws s3 sync ./ s3: // mybucket01

https://linuxhint.com/install_aws_cli_ubuntu/
https://linuxhint.com/install_aws_cli_ubuntu/

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen