s3cmd a échoué trop de fois
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 le dernier s3cmd sur Ubuntu .
Pourquoi est-ce? et comment puis-je le résoudre? S'il est insoluble, quel autre outil puis-je utiliser?
Dans mon cas, la raison de l’échec était que le serveur était en avance sur l’heure S3. Depuis que j'ai utilisé GMT + 4 sur mon serveur (situé dans l'est des États-Unis) et que j'utilisais le système de stockage d'Amazon dans l'est des États-Unis.
Après avoir ajusté mon serveur à l’heure est des États-Unis, le problème avait disparu.
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.
Je viens de rencontrer ce problème moi-même. J'ai un fichier .tar.gz de 24 Go à mettre dans S3.
Le téléchargement de petits morceaux aidera.
Il existe également une limite de taille de fichier d'environ 5 Go. Je divise donc le fichier en plusieurs éléments, qui peuvent être ré-assemblés lors du téléchargement ultérieur.
split -b100m ../input-24GB-file.tar.gz input-24GB-file.tar.gz-
La dernière partie de cette ligne est un "préfixe". Split ajoutera "aa", "ab", "ac", etc. Le -b100m correspond à des morceaux de 100 Mo. Un fichier de 24 Go se composera d'environ 240 parties de 100 Mo, appelées 'input-24GB-file.tar.gz-aa' à 'input-24GB-file.tar.gz-jf'.
Pour les combiner plus tard, téléchargez-les tous dans un répertoire et:
cat input-24GB-file.tar.gz-* > input-24GB-file.tar.gz
Prendre ms5sums des fichiers originaux et scindés et les stocker dans le seau S3, ou mieux, si ce n’est pas si gros, utiliser un système comme parchive pour pouvoir vérifier, voire résoudre certains problèmes de téléchargement, pourrait également être utile.
J'ai essayé toutes les autres réponses mais aucune n'a fonctionné. Il semble que s3cmd soit assez sensible . Dans mon cas, le seau s3 était situé dans l'UE. Les petits fichiers seraient téléchargés, mais quand il atteignait environ 60k, il échouait toujours.
Quand j'ai changé ~/.s3cfg cela a fonctionné.
Voici les modifications que j'ai apportées:
Base_hôte = s3-eu-west-1.amazonaws.com
Host_bucket =% (compartiment) s.s3-eu-west-1.amazonaws.com
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 consistait à mettre à jour s3cmd avec les instructions de s3tools.org :
Debian et Ubuntu
Notre référentiel DEB a été soigneusement créé dans le format le plus compatible façon - cela devrait fonctionner pour Debian 5 (Lenny), Debian 6 (Squeeze), Ubuntu 10.04 LTS (Lucid Lynx) et pour toutes les versions les plus récentes et éventuellement certaines anciennes versions d'Ubuntu. Suivez ces étapes à partir de la ligne de commande:
Importer la clé de signature S3tools:
wget -O- -q http://s3tools.org/repo/deb-all/stable/s3tools.key | Sudo apt-key add -Ajoutez le repo à sources.list:
Sudo wget -O/etc/apt/sources.list.d/s3tools.list http://s3tools.org/repo/deb-all/stable/s3tools.listActualisez le cache du paquet et installez le dernier fichier s3cmd:
Sudo apt-get update && Sudo apt-get install s3cmd
Cette erreur se produit lorsque Amazon renvoie une erreur: ils semblent alors déconnecter le socket pour vous empêcher de télécharger des giga-octets de demande afin de récupérer "non, cela a échoué" en réponse. C'est pourquoi certaines personnes l'obtiennent en raison d'un décalage d'horloge, d'autres en raison d'erreurs de stratégie, tandis que d'autres se heurtent à des limitations de taille nécessitant l'utilisation de l'API de chargement en plusieurs parties. Ce n'est pas que tout le monde se trompe, ni ne se penche sur des problèmes différents: ce sont tous des symptômes différents du même comportement sous-jacent dans s3cmd.
Comme la plupart des conditions d'erreur vont être déterministes, le comportement de s3cmd consistant à jeter le message d'erreur et à réessayer plus lentement est un peu fou malheureux :(. Itthen Pour obtenir le message d'erreur réel, vous pouvez aller dans/usr/share/s3cmd/S3/S3.py (n'oubliez pas de supprimer le .pyc correspondant pour que les modifications soient utilisées) et ajoutez un print e dans le bloc except Exception, e: de la fonction send_file.
Dans mon cas, j'essayais de définir le type de contenu du fichier téléchargé sur "application/x-debian-package". Apparemment, l'entrée S3.object_put de s3cmd 1) n'honore pas un type de contenu transmis via --add-header et pourtant 2) ne parvient pas à écraser le type de contenu ajouté via --add-header car il stocke les en-têtes dans un dictionnaire avec case- touches sensibles. Le résultat est qu’il effectue un calcul de signature en utilisant sa valeur "content-type" puis se termine (au moins avec de nombreuses requêtes; cela peut être basé sur une sorte de hachage ordonnant quelque part) envoyant "Content-Type" à Amazon, conduisant à l'erreur de signature.
Dans mon cas particulier aujourd'hui, il semble que -M obligerait s3cmd à deviner le bon type de contenu, mais cela semble se faire uniquement en fonction du nom de fichier ... J'aurais espéré qu'il utiliserait la base de données mimemagic en fonction du contenu. du fichier. Honnêtement, cependant: s3cmd ne parvient même pas à renvoyer un état de sortie du shell ayant échoué lorsqu'il ne télécharge pas le fichier. Il est donc probablement préférable d'écrire votre propre outil unique pour effectuer celui-ci. Ce dont vous avez besoin ... il est presque certain qu’au bout du compte, cela vous fera gagner du temps lorsque vous vous ferez piquer par un coin de cet outil :(.
s3cmd 1.0.0 ne prend pas encore en charge plusieurs parties. J'ai essayé 1.1.0-beta et cela fonctionne très bien. Vous pouvez lire sur les nouvelles fonctionnalités ici: http://s3tools.org/s3cmd-110b2-released
J'ai rencontré le même problème, il s'est avéré que c'était une mauvaise valeur bucket_location dans ~/.s3cfg.
Ce blog m'a amené à la réponse.
Si le compartiment dans lequel vous téléchargez n’existe pas (ou si vous ne l’avez pas déjà tapé), il échouera avec cette erreur. Merci message d'erreur générique. - Plus d’informations sur: http://jeremyshapiro.com/blog/2011/02/errno-32-broken-pipe-in-s3cmd/#sthash.ZbGwj5Ex.dpuf
Après avoir inspecté mon ~/.s3cfg on voit qu'il avait:
bucket_location = Sydney
Plutôt que:
bucket_location = ap-southeast-2
Corriger cette valeur pour utiliser le nom proper résolvait le problème.
Pour moi, ce qui suit a fonctionné:
Dans .s3cfg, j'ai changé le Host_bucket
Host_bucket = %(bucket)s.s3-external-3.amazonaws.com
s3cmd version 1.1.0-beta3 ou supérieure utilisera automatiquement uploads multipart pour autoriser l'envoi de fichiers volumineux ( source ). Vous pouvez également contrôler la taille du bloc utilisé. par exemple.
s3cmd --multipart-chunk-size-mb=1000 put hugefile.tar.gz s3://mybucket/dir/
Cela fera le téléchargement en morceaux de 1 Go.
J'ai rencontré une erreur similaire qui s'est finalement avérée être causée par une dérive temporelle sur la machine. Le réglage correct de l'heure a réglé le problème pour moi.
J'ai rencontré la même erreur de canal interrompu car la stratégie de groupe de sécurité était mal définie. Je blâme la documentation S3.
J'ai écrit à propos de comment définir correctement la politique dans mon blog, qui est:
{
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:ListBucket",
"s3:GetBucketLocation",
"s3:ListBucketMultipartUploads"
],
"Resource": "arn:aws:s3:::example_bucket",
"Condition": {}
},
{
"Effect": "Allow",
"Action": [
"s3:AbortMultipartUpload",
"s3:DeleteObject",
"s3:DeleteObjectVersion",
"s3:GetObject",
"s3:GetObjectAcl",
"s3:GetObjectVersion",
"s3:GetObjectVersionAcl",
"s3:PutObject",
"s3:PutObjectAcl",
"s3:PutObjectAclVersion"
],
"Resource": "arn:aws:s3:::example_bucket/*",
"Condition": {}
}
]
}
Recherchez le fichier .s3cfg, généralement dans votre dossier personnel.
Si vous en avez, vous avez le méchant. Changer les deux paramètres suivants devrait vous aider.
socket_timeout = 1000
multipart_chunk_size_mb = 15
Sur mon cas, j'ai corrigé ceci en ajoutant simplement les autorisations adéquates.
Bucket > Properties > Permissions
"Authenticated Users"
- List
- Upload/Delete
- Edit Permissions