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
的行爲可能是正確的,但是,因爲您確實想要考慮到空間不足,截斷文件或服務器在複製操作過程中崩潰的邊緣條件,填充文件留下。通過寫入臨時文件並關閉它,然後重新命名很多這些邊緣條件是可以避免的。
我認爲我們需要更好的解釋你想要做什麼。 –