当前位置: 首页>>技术教程>>正文


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.

我正在使用最新的s3cmd on Ubuntu

为什么会这样呢?以及我该如何解决?如果无法解决,我可以使用哪些替代工具?

最佳方案

而现在是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

会给您满意的结果。

次佳方案

我自己遇到了这个问题。我有一个24GB的.tar.gz文件放入S3。

上传较小的片段会有所帮助。

文件大小也有大约5GB的限制,因此我将文件拆分为多个文件,稍后再下载文件时可以为re-assembled。

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

该行的最后一部分是’prefix’。拆分将在其上附加’aa’,’ab’,’ac’等。 -b100m表示100MB块。一个24GB的文件最终将包含约240 100mb的部分,称为’input-24GB-file.tar.gz-aa’至’input-24GB-file.tar.gz-jf’。

要在以后合并它们,请将它们全部下载到目录中,然后:

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

取原始文件和拆分文件的md5sums并将其存储在S3存储桶中,或者如果不那么大,则使用parchive这样的系统进行检查甚至修复某些下载问题也可能很有价值。

第三种方案

我尝试了所有其他答案,但没有一个起作用。看起来s3cmd非常敏感。就我而言,s3存储桶位于欧盟。小文件可以上传,但是当上传到约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...

解决方法是使用instructions from s3tools.org更新s3cmd:

Debian & Ubuntu

Our DEB repository has been carefully created in the most compatible way – it should work for Debian 5 (Lenny), Debian 6 (Squeeze), Ubuntu 10.04 LTS (Lucid Lynx) and for all newer and possibly for some older Ubuntu releases. Follow these steps from the command line:

  • Import S3tools signing key:

    wget -O- -q http://s3tools.org/repo/deb-all/stable/s3tools.key | sudo apt-key add -

  • Add the repo to sources.list:

    sudo wget -O/etc/apt/sources.list.d/s3tools.list http://s3tools.org/repo/deb-all/stable/s3tools.list

  • Refresh package cache and install the newest s3cmd:

    sudo apt-get update && sudo apt-get install s3cmd

第五种方案

当Amazon返回错误时,会发生此错误:他们似乎然后断开了套接字的连接,以阻止您上传千兆字节的请求以获取“不,失败”的响应。这就是为什么某些人由于时钟偏斜而得到它,有些人由于策略错误而得到它,而另一些人由于需要使用multi-part上传API而受到大小限制的原因。并不是每个人都错了,甚至不是在看不同的问题:这些都是s3cmd中相同基础行为的所有不同症状。

由于大多数错误情况都是确定性的,因此s3cmd丢弃错误消息并较慢地重试的行为有点疯狂,不幸的是:(。然后,要获取实际的错误消息,可以进入/usr /share /s3cmd /S3 /S3.py(记住删除相应的.pyc,以便使用更改),并在send_file函数的except Exception, e:块中添加print e

就我而言,我试图将上传文件的Content-Type设置为”application/x-debian-package”。显然,s3cmd的S3.object_put 1)不支持通过–add-header传递的Content-Type,但是2)无法覆盖通过–add-header添加的Content-Type,因为它将标头存储在具有大小写敏感键的字典中。结果是它使用”content-type”的值进行签名计算,然后结束(至少有许多请求;这可能是基于某种哈希排序),将”Content-Type”发送到Amazon,从而导致签名错误。

在今天的特定情况下,-M似乎会使s3cmd猜测正确的Content-Type,但似乎仅根据文件名即可完成此操作…我希望它会根据该内容使用mimemagic数据库文件。不过,坦白地说,当s3cmd无法上传文件时,s3cmd甚至无法返回失败的shell退出状态,因此结合所有其他问题,最好编写自己的one-off工具来做一件事需要…几乎可以肯定的是,最终当您被该工具的corner-case咬伤时,它将节省您的时间:(。

第六种方案

s3cmd 1.0.0目前还不支持multi-part。我尝试了1.1.0-beta,它正常工作。您可以在此处阅读有关新功能的信息:http://s3tools.org/s3cmd-110b2-released

第七种方案

在我的情况下,失败的原因是服务器的时间早于S3时间。由于我在服务器(位于美国东部)中使用了GMT + 4,因此我正在使用Amazon的美国东部存储设施。

在将服务器调整为美国东部时间后,问题就消失了。

第八种方案

我遇到了同样的问题,结果发现~/.s3cfg中的bucket_location值不正确。

这篇博客文章引导我找到答案。

If the bucket you’re uploading to doesn’t exist (or you miss typed it ) it’ll fail with that error. Thank you generic error message. – See more at: 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名称解决了该问题。

参考资料

本文由Ubuntu问答整理, 博文地址: https://ubuntuqa.com/article/9982.html,未经允许,请勿转载。