s3cmd a échoué trop de fois

Question

J'étais un utilisateur s3cmd heureux. Cependant, récemment, lorsque j'essaie de transférer un fichier zip volumineux (~ 7Gig) vers Amazon S3, le message d'erreur suivant s'affiche:

 $> s3cmd put thefile.tgz s3://thebucket/thefile.tgz

....
  20480 of 7563176329     0% in    1s    14.97 kB/s  failed
WARNING: Upload failed: /thefile.tgz ([Errno 32] Broken pipe)
WARNING: Retrying on lower speed (throttle=1.25)
WARNING: Waiting 15 sec...
thefile.tgz -> s3://thebucket/thefile.tgz  [1 of 1]
       8192 of 7563176329     0% in    1s     5.57 kB/s  failed
ERROR: Upload of 'thefile.tgz' failed too many times. Skipping that file.
 

J'utilise la dernière version de s3cmd sur Ubuntu .

Pourquoi est-ce? et comment puis-je le résoudre? S'il est insoluble, quel autre outil puis-je utiliser?

Answer 1

Et maintenant, en 2014, la aws cli a la possibilité de télécharger de gros fichiers au lieu de s3cmd.

http://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-set-up.html a des instructions d'installation / de configuration, ou souvent:

 $ wget https://s3.amazonaws.com/aws-cli/awscli-bundle.zip
$ unzip awscli-bundle.zip
$ sudo ./awscli-bundle/install -i /usr/local/aws -b /usr/local/bin/aws
$ aws configure
 

suivi par

 $ aws s3 cp local_file.tgz s3://thereoncewasans3bucket
 

vous obtiendrez des résultats satisfaisants.

Answer 2

Je viens de tomber sur ce problème moi-même. J'ai un 24GO .tar.gz le fichier à mettre en S3.

Le téléchargement de petits morceaux de l'aide.

Il est également à environ 5 go de limite de taille de fichier, et je suis donc divisé le fichier en morceaux, qui peut être ré-assemblé lorsque les morceaux sont téléchargés plus tard.

split -b100m ../input-24GB-file.tar.gz input-24GB-file.tar.gz-

La dernière partie de la ligne, est un "préfixe". Split append 'aa', 'ab', 'ac', etc pour elle. L'-b100m moyen de 100 mo morceaux. Un 24GO fichier avec environ 240 100 mo parties, appelées 'entrée-24 GO-fichier.le goudron.gz-aa " à " entrée-24 GO-fichier.le goudron.gz-jf'.

Combiner plus tard, téléchargez-les tous dans un répertoire:

cat input-24GB-file.tar.gz-* > input-24GB-file.tar.gz

Prendre md5sum de l'original et de diviser des fichiers et le stockage que dans le compartiment S3, ou mieux, si ce n'est pas si grand, à l'aide d'un système comme parchive (en anglais) pour être en mesure de vérifier, même résoudre certains des problèmes de téléchargement pourrait également être utile.

Answer 3

J'ai essayé toutes les autres réponses mais aucune n'a fonctionné. Il semble que s3cmd soit assez sensible. Dans mon cas, le compartiment s3 se trouvait dans l’UE. Les petits fichiers seraient téléchargés, mais quand ils atteignent environ 60k, ils échouent toujours.

Quand j'ai changé ~ / .s3cfg cela a fonctionné.

Voici les modifications que j'ai apportées:

host_base = s3-eu-west-1.amazonaws.com

host_bucket =% (compartiment) s.s3-eu-west-1.amazonaws.com

Answer 4

J'ai eu le même problème avec ubuntu s3cmd.

s3cmd --guess-mime-type --acl-public put test.zip s3://www.jaumebarcelo.info/teaching/lxs/test.zip
test.zip -> s3://www.jaumebarcelo.info/teaching/lxs/test.zip  [1 of 1]
 13037568 of 14456364    90% in  730s    17.44 kB/s  failed
WARNING: Upload failed: /teaching/lxs/test.zip (timed out)
WARNING: Retrying on lower speed (throttle=0.00)
WARNING: Waiting 3 sec...
test.zip -> s3://www.jaumebarcelo.info/teaching/lxs/test.zip  [1 of 1]
  2916352 of 14456364    20% in  182s    15.64 kB/s  failed
WARNING: Upload failed: /teaching/lxs/test.zip (timed out)
WARNING: Retrying on lower speed (throttle=0.01)
WARNING: Waiting 6 sec...

La solution a été de mettre à jour s3cmd avec les instructions de s3tools.org:

Debian Et Ubuntu

Notre dépôt a été soigneusement créé dans le plus compatible façon – il doit travailler pour Debian 5 (Lenny), Debian 6 (Squeeze), Ubuntu 10.04 LTS (Lucid Lynx) et toutes les nouvelles et, éventuellement, pour certaines anciennes versions d'Ubuntu. Procédez comme suit à partir de la ligne de commande:

• Importation S3tools clé de signature:
  
  wget -O- -q http://s3tools.org/repo/deb-all/stable/s3tools.key | sudo apt-key add -

• Ajouter le repo de sources.liste:
  
  sudo wget -O/etc/apt/sources.list.d/s3tools.list http://s3tools.org/repo/deb-all/stable/s3tools.list

• Actualiser le cache des paquets et installer la dernière s3cmd:
  
  sudo apt-get update && sudo apt-get install s3cmd

Answer 5

Cette erreur se produit lorsque Amazon renvoie une erreur: ils semblent alors débrancher la prise pour vous empêcher de téléchargement de gigaoctets de demande pour revenir "pas de, qui a échoué" dans la réponse. C'est pourquoi les gens sont-elle due à l'clock skew, certaines personnes sont-il dû à des erreurs de stratégie, et d'autres sont en cours d'exécution dans les limites de la taille exigeant l'utilisation de la partie multi-upload de l'API. Ce n'est pas que tout le monde est mauvais, ou sont encore à la recherche à différents problèmes: ce sont tous des symptômes différents de la même comportement sous-jacent dans s3cmd.

Comme la plupart des conditions d'erreur sont va être déterministe, s3cmd du comportement de jeter le message d'erreur et de réessayer plus lent est un peu fou malheureux :(. Itthen D'obtenir le véritable message d'erreur, vous pouvez aller dans /usr/share/s3cmd/S3/S3.py (se souvenir de supprimer la .pyc afin que les changements sont utilisés) et d'ajouter un print e dans le send_file fonction de l' except Exception, e: bloc.

Dans mon cas, j'ai essayé de définir le Type de Contenu du fichier téléchargé en "application/x-debian-package". Apparemment, s3cmd S3.object_put 1) n'a pas l'honneur d'un Type de Contenu transmis via --add-d'en-tête et pourtant 2) ne parvient pas à remplacer le Type de Contenu ajouté par --add-d'en-tête comme il stocke les en-têtes dans un dictionnaire avec la casse des clés. Le résultat est qu'il n'a qu'une signature de calcul à l'aide de sa valeur de "content-type", puis finit par (au moins avec de nombreuses demandes, ce qui peut être basé sur une sorte de hachage de la commande de quelque part) envoi "Content-Type" à Amazon, aboutissant à la signature d'erreur.

Dans mon cas précis aujourd'hui, il semble que -M serait la cause de s3cmd à deviner de quel Type de Contenu, mais il semble qu'en fonction de leur nom seul... j'aurais espéré qu'elle serait d'utiliser la mimemagic base de données basée sur le contenu du fichier. Honnêtement, si: s3cmd n'arrivons même pas à retourner l'échec d'une coquille de statut de sortie quand il ne parvient pas à télécharger le fichier, ce qui combiné avec l'ensemble de ces questions, il est probablement préférable de simplement écrire votre propre one-off outil pour faire la seule chose dont vous avez besoin... il est presque certain qu'à la fin, il vous fera économiser du temps lorsque vous faire mordre par quelque coin de cas de cet outil :(.