Aws-cli: Le téléchargement de fichiers vers S3 à partir d'instances EC2 échoue sur certains types d'instances

Quelle version de la CLI utilisez-vous? Cela ressemble à https://github.com/aws/aws-cli/pull/594 , qui a été corrigé dans la version 1.2.11

En fait, ce problème concernait les téléchargements, celui-ci concerne les téléchargements, il s'agit donc probablement d'un problème différent. Je vais devoir approfondir cette question. Si vous pouviez fournir un journal --debug de ceci, cela aiderait au dépannage.

Aussi, environ combien de fichiers 10M téléchargez-vous à la fois?

J'ai également des problèmes de téléchargement vers s3, mais depuis mon ordinateur portable (OSX mavericks). Un fichier de 424 Ko a échoué,
et un fichier de 344 Ko a fonctionné. Je télécharge un fichier à la fois, avec les versions suivantes:

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

L'erreur est la même que le message d'origine:

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)

Je l'ai exécuté avec --debug, et voici la partie qui continue de réessayer:

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

Nous utilisons la version 1.2.13. Nous avons environ 200 de ces fichiers à télécharger, mais nous le faisons en série. Le problème se produit toujours sur le premier.

Voici le journal de débogage de l'échec que vous avez demandé: https://gist.github.com/benbc/8861033.

Y a-t-il une mise à jour sur ce problème. Je vois exactement le même problème en essayant de télécharger dans un bucket nouvellement créé.

Oui, je pense que cela devrait être corrigé maintenant dans la version 1.3.0. La cause première, je crois, est la même que https://github.com/aws/aws-cli/issues/544.

Pouvez-vous essayer avec la dernière version de la CLI. Si vous rencontrez toujours le problème, veuillez joindre un journal --debug et je repoen le problème.

Je rencontre toujours ce problème lors du téléchargement vers s3, ni depuis mon ordinateur portable, ni depuis le serveur Debian. Le fichier fait environ 100 Mo. Je télécharge un fichier à la fois, avec les versions suivantes:

   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

Voici le problème que je reçois:

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

Voici le journal de débogage:

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)

Ce problème persiste en utilisant aws cp et aws sync sur un nouveau bucket. Les fichiers plus petits n'ont subi aucun problème, les fichiers plus volumineux échouent de manière fiable comme décrit ici et # 544

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>

Comme d'autres l'ont signalé, cela fonctionne maintenant correctement après l'effacement du code TemporaryRedirect -

$ 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>%

Je rencontre toujours ce problème avec la version 1.3.4 sur un nouveau bucket Ireland.

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

Journal de débogage: https://gist.github.com/anonymous/9814978

Même bug pour moi lors de l'utilisation de 'aws s3 sync'
$ aws --version
aws-cli / 1.3.4 Python / 2.7.3 Linux / 3.2.0-57-virtual

Mon seau est en Irlande.

journal de débogage: https://paste.buntux.org/?c511ef0a27305636#e1/B5RiyBuZq60LHmLNpZt59wz2zDyY2KVdjCM + mO7E =

edit: J'ai testé sur un bucket dans la région "US Standard" -> pas de problème
edit2: nouvelle URL pour le journal de débogage https://paste.jeekajoo.eu/?c511ef0a27305636#e1/B5RiyBuZq60LHmLNpZt59wz2zDyY2KVdjCM + mO7E =

Je rouvre ce numéro. Après avoir débogué cela, je peux confirmer ce que les autres ont dit. Ce problème se produit lorsque vous essayez de télécharger un fichier volumineux dans un bucket nouvellement créé qui ne se trouve pas dans la région classique.

D'après ce que je peux dire, la CLI réessaye correctement les demandes et suit 307 redirections. Le problème, cependant, est que la CLI envoie la demande _entire_ puis attend une réponse. Cependant, S3 enverra immédiatement la réponse 307 avant que nous ayons fini d'envoyer le corps. Finalement, cela fermera simplement la connexion, et si nous sommes toujours en train de diffuser le corps, nous ne verrons pas la réponse. Au lieu de cela, nous obtenons le ConnectionError comme indiqué dans les différents journaux de débogage ci-dessus.

La manière normale de résoudre ce problème serait d'utiliser l'en-tête expect 100 continue. Cependant, le client HTTP que nous utilisons (requêtes) ne prend pas en charge cela. Il existe peut-être un moyen de contourner ce problème, mais je vais devoir fouiller dans la bibliothèque de requêtes pour voir la meilleure façon de résoudre ce problème.

Je mettrai à jour ce problème lorsque j'en saurai plus.

Des nouvelles?

mes tests montrent que même lorsque la bibliothèque boto échoue, l'AWS CLI fonctionne correctement. que fait l'AWS CLI différemment?

Je ne pense pas qu'il existe des moyens de contourner ce problème dans la bibliothèque de requêtes. Je pense que notre meilleure option (mis à part l'écriture de notre propre client HTTP qui prend en charge expect 100 continue) est une solution de contournement spécifique dans le code S3.

Je viens de frapper ça aussi. Mon fichier n'est pas volumineux, juste quelques mégaoctets.

Obtenir cela avec un fichier CSS de 323 Ko.

Travailler sur un correctif pour cela, sera mis à jour lorsque j'aurai plus d'informations.

Obtenir le même problème lors du téléchargement de gros fichiers (3 Go) dans S3. Le téléchargement de petits fichiers est très bien.

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)
... 

Ma version aws;
aws-cli / 1.3.13 Python / 2.7.3 Linux / 3.2.0-61-virtuel

Je reçois un problème similaire par intermittence (environ 1 fichier sur 20, les fichiers font environ 500 Mo) en utilisant directement la bibliothèque de requêtes alors que nous travaillons via notre API de stockage spécifique. Il s'agit d'un téléchargement depuis une instance EC2.

  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)

Juste une mise à jour, je travaille toujours là-dessus. L'approche la plus viable jusqu'à présent a été de sous-classer HTTPConnection et d'essayer d'implémenter la logique expect 100-continue dans notre sous-classe. Nous placerons ensuite cela dans les pools de connexion d'urllib3, qui seront récupérés par les requêtes (qui est la bibliothèque http que nous utilisons).

Je pense donc avoir une solution potentielle, mais elle nécessite plus de tests. Mettra à jour quand j'aurai plus d'informations.

@jamesls dès que vous aurez une branche publique à tester, je l'utiliserai :)

Salut,

puisque ce n'est pas explicitement dit dans le thread, vous pouvez toujours utiliser la commande "aws" pour télécharger des fichiers vers une autre région en spécifiant le paramètre --region.

• Celui-ci échoue
  aws s3 cp ./really_big_file s3: // MON-SEAU /
• Celui-ci fonctionne
  aws --region eu-west-1 s3 cp ./really_big_file s3: // MON-SEAU /

@ inedit00 Merci! Je n'avais aucune idée que cela était lié au problème.

Le correctif pour cela est ici: https://github.com/boto/botocore/pull/303

Mais j'aimerais faire plus de tests à ce sujet. Je veux aussi voir ce que fait l'envoi de l'en-tête expect 100-continue à perf.

Nous obtenons également cette erreur lors de la copie d'un fichier volumineux (~ 3 Go) de local vers S3 (Irlande). En utilisant aws-cli / 1.3.17 Python / 2.6.6 Linux / 2.6.32-71.29.1.el6.x86_64 et botocore 0.51.0.

Juste une mise à jour rapide, le correctif pour cela se trouvait dans boto / botocore # 303, mais nous avons attrapé une régression qui n'était que dans python2.6, nous avons donc dû annuler le PR.

Je pense qu'il est toujours possible de résoudre ce problème, mais ce sera légèrement plus invasif en raison des changements internes de httplib de python2.6 à> python2.6. Je mettrai à jour ceci lorsque j'aurai plus d'informations.

J'ai pu résoudre le problème python2.6 dans le précédent PR pour résoudre ce problème. Tous les tests réussissent avec ce changement, et je peux confirmer que cela résout le problème de l'impossibilité de télécharger des fichiers volumineux vers des compartiments S3 non standard nouvellement créés. Veuillez me faire savoir si vous rencontrez toujours des problèmes et merci de votre patience pendant que nous avons résolu ce problème.

Merci pour le correctif @jamesls. Dans quelle version awscli est / sera ce correctif?

Ceci est disponible dans la dernière version de la CLI (v1.3.18).

De plus, si quelqu'un a besoin de déboguer cela à l'avenir, vous verrez les journaux de débogage liés à l'en-tête expect 100 continue:

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

Je crois que c'est toujours un problème par # 823.

Cela ressemble à un problème différent. L'errno est différent, en particulier.

a eu le même problème.

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

Vous avez atteint la limite de performances d'AWS s3?
https://stackoverflow.com/questions/23397460/error-handling-boto-error-104-connection-reset-by-peer

Je rencontre le même problème. Ce fil est assez ancien. Ce problème fait-il toujours l'objet d'une enquête?

('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

Face au même problème

`` ``

aws s3 cp /opt/tradetracker/dataStream/tracker-hits-2018-04-30_11:00:00.log s3: // tt-feeder-dumps
échec du téléchargement: ../dataStream/tracker-hits-2018-04-30_11:00:00.log vers s3: // tt-feeder-dumps / tracker-hits-2018-04-30_11: 00: 00.log ( 'Connection abandonnée.', ConnectionResetError (104, 'Connection reset by peer'))

ls -hal /opt/tradetracker/dataStream/tracker-hits-2018-04-30_11:00:00.log
-rw-rw-rw- 1 www-data www-data 13M 30 avril 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
`` ``

Idem. +1
Taille du fichier: 1G
aws-cli/1.15.12 Python/3.4.3 Linux/4.4.0-71-generic botocore/1.10.12

Pour ma configuration, cela a été résolu en définissant:
s3 =
max_concurrent_requests = 5
max_bandwidth = 210 Ko / s

dans le fichier .aws / config du profil que j'utilisais. Voir ici: https://docs.aws.amazon.com/cli/latest/topic/s3-config.html#

J'ai également le même problème, lorsque j'ai essayé de télécharger un fichier dans s3 bucket à l'aide du package python boto3.

Il fonctionnait bien jusqu'à il y a environ 4 jours, et depuis lors, il a des problèmes de téléchargement.

J'ai le même problème avec un bucket nouvellement créé dans la région eu-west-1.

Commande utilisée:
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

Ce problème est-il lié au réseau auquel je suis connecté? Le téléchargement échouait lorsque je m'étais connecté à un dongle 4G, alors que lorsque j'étais connecté à mon routeur wifi, tout allait bien.

Mais le dongle 4G me donnait une vitesse de 10 Mbps. Donc, je ne sais pas où est le problème

@uldall Si vous ne l'avez pas déjà résolu, cela a été résolu pour moi en installant la dernière version de aws-cli - la dernière version d'apt-get est obsolète et vous devez donc l'installer en utilisant pip. Voici les instructions:
https://www.slashroot.in/how-to-install-and-configure-aws-cli-on-ubuntu-16-04

Sur ubuntu 18
Installez python 3
sudo apt-get installer python3-pip
pip3 installer awscli --upgrade --user
aws s3 sync ./ s3: // mybucket01

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