s3cmdが何度も失敗しました
私は以前は幸せなs3cmdユーザーでした。ただし、最近、大きなZipファイル（〜7Gig）をAmazon S3に転送しようとすると、次のエラーが表示されます。
$> 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.
私は最新の buntuのs3cmd を使用しています。
なぜそうですか？どうすれば解決できますか？解決できない場合、どのような代替ツールを使用できますか？
私の場合、失敗の理由は、サーバーの時間がS3時間よりも進んでいることでした。サーバー（米国東部にある）でGMT + 4を使用し、Amazonの米国東部のストレージ施設を使用していたため。
サーバーを米国東部時間に合わせた後、問題はなくなりました。
そして今、2014年、aws cliにはs3cmdの代わりに大きなファイルをアップロードする機能があります。
http://docs.aws.Amazon.com/cli/latest/userguide/cli-chap-getting-set-up.html にインストール/設定の手順があるか、または多くの場合：
$ 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
に続く
$ aws s3 cp local_file.tgz s3://thereoncewasans3bucket
満足のいく結果が得られます。
私は自分でこの問題に出くわしました。 S3に入れる24GBの.tar.gzファイルがあります。
小さいピースをアップロードすると役立ちます。
また、ファイルサイズには最大5GBの制限があります。そのため、ファイルを分割して、後でダウンロードするときに再構築できます。
split -b100m ../input-24GB-file.tar.gz input-24GB-file.tar.gz-
その行の最後の部分は「プレフィックス」です。 Splitは、「aa」、「ab」、「ac」などを追加します。 -b100mは100MBのチャンクを意味します。 24GBファイルは、「input-24GB-file.tar.gz-aa」から「input-24GB-file.tar.gz-jf」と呼ばれる約240個の100mbパーツになります。
後で結合するには、それらをすべてディレクトリにダウンロードし、次のようにします。
cat input-24GB-file.tar.gz-* > input-24GB-file.tar.gz
元のファイルと分割ファイルのmd5sumを取得し、それをS3バケットに保存します。それほど大きくない場合は、 parchive のようなシステムを使用して確認し、ダウンロードの問題を修正することもできます。貴重である。
私は他のすべての答えを試しましたが、どれもうまくいきませんでした。 s3cmdはかなり敏感なようです。私の場合、s3バケットはEUにありました。小さなファイルはアップロードされますが、60kに達すると常に失敗しました。
〜/ .s3cfgを変更すると機能しました。
変更点は次のとおりです。
Host_base = s3-eu-west-1.amazonaws.com
Host_bucket =％（bucket）s.s3-eu-west-1.amazonaws.com
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...
解決策は、s3cmdを s3tools.orgからの指示 で更新することでした。
DebianおよびUbuntu
私たちのDEBリポジトリは、最も互換性のある方法で慎重に作成されています。Debian5（Lenny）、Debian 6（Squeeze）、Ubuntu 10.04 LTS（Lucid Lynx）、およびすべての新しいUbuntuで動作するはずです。コマンドラインから次の手順を実行します。
S3tools署名キーをインポートします。
wget -O- -q http://s3tools.org/repo/deb-all/stable/s3tools.key | Sudo apt-key add -Sources.listにリポジトリを追加します。
Sudo wget -O/etc/apt/sources.list.d/s3tools.list http://s3tools.org/repo/deb-all/stable/s3tools.listパッケージキャッシュを更新し、最新のs3cmdをインストールします。
Sudo apt-get update && Sudo apt-get install s3cmd
このエラーは、Amazonがエラーを返したときに発生します。応答を「いいえ、失敗しました」を取得するために、ギガバイトのリクエストをアップロードできないようにソケットを切断するようです。これが、クロックスキューが原因で取得している人、ポリシーエラーが原因で取得している人、マルチパートアップロードAPIの使用を必要とするサイズ制限に直面している人がいる理由です。誰もが間違っているわけではなく、別の問題を見ているわけでもありません。これらはすべて、s3cmdの同じ基本的な動作の異なる症状です。
ほとんどのエラー条件は確定的であるため、s3cmdがエラーメッセージを破棄して再試行を遅くするという動作は、非常に残念です:(。それから実際のエラーメッセージを取得するには、/ usr/share/s3cmd/S3/S3.py（対応する.pycを削除して変更を使用することを忘れないでください）を追加し、print e send_file関数のexcept Exception, e:ブロック。
私の場合、アップロードしたファイルのContent-Typeを「application/x-debian-package」に設定しようとしました。どうやら、s3cmdのS3.object_put 1）--add-headerを介して渡されたContent-Typeを尊重せず、2）--add-headerを介して追加されたContent-Typeを辞書にヘッダーを保存するときに上書きできません機密キー。その結果、「content-type」の値を使用して署名の計算が行われ、（少なくとも多くのリクエストで、これはどこかで何らかのハッシュ順序に基づいている可能性があります）Amazonに「Content-Type」を送信します。署名エラーにつながります。
今日の私の特定のケースでは、-Mがs3cmdに正しいContent-Typeを推測させるように見えますが、ファイル名だけに基づいてそれを行うようです...コンテンツに基づいてmimemagicデータベースを使用することを望んでいたでしょうファイルの。正直なところ、ファイルのアップロードに失敗すると、s3cmdは失敗したシェル終了ステータスを返すことさえできないため、これらの他のすべての問題と組み合わせて、独自の1回限りのツールを作成することをお勧めしますあなたが必要とすること...それは、このツールのいくつかのコーナーケースに噛まれたときに最終的にそれがあなたの時間を節約することはほぼ確実です:(。
s3cmd 1.0.0はマルチパートをまだサポートしていません。 1.1.0-betaを試してみましたが、うまく動作します。新しい機能については、こちらをご覧ください： http://s3tools.org/s3cmd-110b2-released
私は同じ問題を経験しましたが、それは悪いbucket_locationの値~/.s3cfg。
このブログ投稿は私を答えに導きました。
アップロードするバケットが存在しない場合（または入力し忘れた場合）、そのエラーで失敗します。一般的なエラーメッセージをありがとうございます。 -詳細は http://jeremyshapiro.com/blog/2011/02/errno-32-broken-pipe-in-s3cmd/#sthash.ZbGwj5Ex.dpuf
私の~/.s3cfgは次のように表示されます。
bucket_location = Sydney
のではなく：
bucket_location = ap-southeast-2
proper name（s）を使用するようにこの値を修正して、問題を解決しました。
私にとっては、以下がうまくいきました：
.s3cfgで、Host_bucketを変更しました
Host_bucket = %(bucket)s.s3-external-3.amazonaws.com
s3cmdバージョン1.1.0-beta3以降では、自動的に multipart uploads を使用して、任意の大きなファイルを送信できるようにします（ source ）。使用するチャンクサイズも制御できます。例えば.
s3cmd --multipart-chunk-size-mb=1000 put hugefile.tar.gz s3://mybucket/dir/
これにより、1 GBのチャンクでアップロードが行われます。
同様のエラーが発生しましたが、最終的にはマシンの時間ドリフトが原因であることが判明しました。時間を正しく設定することで問題が解決しました。
セキュリティグループポリシーが誤って設定されたのと同じ破損パイプエラーが発生しました。S3のドキュメントを非難しました。
私のブログで ポリシーを正しく設定する方法 について書いた：
{
"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": {}
}
]
}
検索する .s3cfgファイル。通常はホームフォルダーにあります。
あなたがそれを持っている場合、あなたは悪役を得た。次の2つのパラメーターを変更すると役立ちます。
socket_timeout = 1000
multipart_chunk_size_mb = 15
私の場合、正しい権限を追加するだけでこれを修正しました。
Bucket > Properties > Permissions
"Authenticated Users"
- List
- Upload/Delete
- Edit Permissions