2016 年 9 月 20 日:Chef 12.0 附带的 file_stating_uses_destdir 默认为 true,因此这不再是问题(remote_file,但它流向 /tmp 的位置可能仍然存在)。
首先是真正简单的陈述:如果 /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
错误。
您可以将 chef-client 全局设置为使用目标目录作为 tmpdir,通过将其添加到 client.rb 来创建文件:
file_staging_uses_destdir true
然后,如果您的目标目录是“/tmp”,则临时文件将在那里创建,然后将在目录中重命名以部署它。这确保了如果目标设备上有足够的空间来保存结果,那么资源应该始终成功写入临时文件。如果 destdir 和 destdir 位于不同的文件系统上,它也避免了这个问题/tmp
,即重命名和部署文件的 mv 将被转换为 copy-and-unlink-src 操作,该操作可能会以几种不同的方式失败。
@cassianoleal 的回答是不正确地说明厨师客户始终/var/cache
用作临时位置。更改file_cache_path
也不会产生影响。这混淆了将 remote_files 下载到 Chef file_cache_path 目录的常见模式,以了解 remote_file 如何在内部工作——它们不是一回事。问题中没有 file_cache_path,因此答案中不应该有任何 file_cache_path。
带有 file:// URL 的 remote_file 的行为有点绕圈子,但那是因为它们对于所有其他 URL 都是必需的(正如 @cassianoleal 正确提到的那样)。但是,这种行为file_staging_uses_destdir
可能是正确的,因为您确实希望考虑到空间不足并截断文件或服务器在复制操作过程中崩溃的边缘条件,并且您不希望有一半的人剩下的文件。通过写入临时文件并关闭它,然后重命名许多这些边缘条件可以避免。