9/20/2016:随着file_stating_uses_destdir默认为true,所以这应该不再是一个问题(远程文件,但它流到/ tmp可能仍然存在)的厨师12.0。
首先是一个真实的简单陈述:如果你在/ tmp中有一个4GB的文件,而你在/ tmp中只剩下2GB,那么显然复制4GB将会失败,没有任何东西可以帮到你。我假设你在/ tmp中至少有4GB,而在/ var中只剩下2GB,这是唯一有效的解决方案。
从11.6.0(至少11.10.2)开始,chef-client将使用ruby的Tempfile.new
创建一个临时文件,并将内容复制到该临时文件,然后将其转换到位。临时文件的位置将由ENV['TMPDIR']
确定,并且根据您的操作系统发行版而不同(例如,在Mac上,它将类似于/var/folders/rs/wqwmj_1n59135dhhbvfdrlqh0001yj/T/
,而不仅仅是/tmp
或甚至/var/tmp
),因此在创建中间临时文件的位置可能不明显。你可能会遇到这个问题。您应该能够从chef-client -l debug
输出中看到主厨正在使用的临时文件位置,如果您的目录为df -k
,则您可能会看到它为100%。
另外,看看df -i
,看看你是否用尽了inode,也会抛出no space left on device
错误。
您可以通过添加此全局设置厨师客户端使用的目标目录作为TMPDIR创建文件client.rb:
file_staging_uses_destdir true
那么如果你的目的地dir是“/ tmp目录”的临时文件将在那里创建,然后在目录中进行简单重命名以部署它。这确保了如果目标设备上有足够的空间来保存结果,那么资源应该始终成功写入临时文件。它还避免了/tmp
和destdir位于不同文件系统上的问题,即要重命名和部署该文件的mv将被转换为可能以多种不同方式失败的copy-and-unlink-src操作。
@cassianoleal的回答在说明厨师客户始终使用/var/cache
作为临时位置时不正确。更改file_cache_path
也不会产生影响。这就将远程文件下载到chef file_cache_path目录的常见模式混淆了remote_file在内部的工作原理 - 这些都不是一回事。问题中没有file_cache_path,因此答案中不应该有任何file_cache_path。
remote_file与file:// URLs的行为有点圆润,但这是因为它们对于所有其他URL(正如@cassianoleal正确提到的)是必需的。 file_staging_uses_destdir
的行为可能是正确的,但是,因为您确实想要考虑到空间不足,截断文件或服务器在复制操作过程中崩溃的边缘条件,填充文件留下。通过写入临时文件并关闭它,然后重新命名很多这些边缘条件是可以避免的。
我认为我们需要更好的解释你想要做什么。 –