先說(shuō)點(diǎn)實(shí)在話。臨時(shí)文件這東西幾乎每個(gè)用電腦的人都會(huì)碰到但真正把它當(dāng)回事的人不多。我曾經(jīng)在一臺(tái)測(cè)試服務(wù)器上見(jiàn)過(guò) /tmp 目錄里堆了接近 30GB 的垃圾里面全是各種安裝包殘留、編譯中間產(chǎn)物和半年前的日志切片。更麻煩的是這臺(tái)機(jī)器磁盤(pán)已經(jīng)告警了可沒(méi)人敢手動(dòng)刪——因?yàn)檎l(shuí)都不確定里面有沒(méi)有哪個(gè)文件正在被某個(gè)服務(wù)使用。這種場(chǎng)景相信不少運(yùn)維和開(kāi)發(fā)朋友都遇到過(guò)。臨時(shí)文件自動(dòng)化方案說(shuō)白了就是用一套確定的規(guī)則和工具代替“人工不定期清理”這個(gè)不靠譜的習(xí)慣。它解決的是三個(gè)層面的問(wèn)題磁盤(pán)空間被不知不覺(jué)吃光、臨時(shí)文件混亂導(dǎo)致排障困難、以及手動(dòng)刪除時(shí)誤刪正在使用的文件造成事故。這篇文章適合運(yùn)維工程師、開(kāi)發(fā)者、以及想把自己電腦整理干凈但不想天天操心的朋友。我會(huì)從方案選型、腳本設(shè)計(jì)、定時(shí)任務(wù)配置、誤刪防護(hù)一直講到 CI/CD 和容器環(huán)境里的進(jìn)階玩法全程給可復(fù)現(xiàn)的命令和配置。1. 臨時(shí)文件為什么需要一套自動(dòng)化清理方案1.1 臨時(shí)文件是怎么悄悄長(zhǎng)大的臨時(shí)文件不是只有一個(gè) /tmp 目錄那么簡(jiǎn)單。按照來(lái)源大致能分成幾類(lèi)操作系統(tǒng)運(yùn)行時(shí)會(huì)產(chǎn)生的套接字文件、PID 文件、軟件安裝包殘骸包管理器緩存比如 apt、pip、npm、yarn 留下的緩存開(kāi)發(fā)工具的編譯產(chǎn)物像 dist、build、target 目錄以及 node_modules/.cache還有日志切割后的歷史文件。每一類(lèi)單獨(dú)看都不大但架不住積少成多。我見(jiàn)過(guò)一個(gè)很典型的例子一個(gè) Java 項(xiàng)目的編譯構(gòu)建每次會(huì)在 /tmp 里留下幾百 MB 的中間文件。開(kāi)發(fā)環(huán)境跑了幾周/tmp 就被撐到了 20GB。還有個(gè)前端項(xiàng)目node_modules/.cache 里緩存了幾百 MB 的 webpack 持久化緩存磁盤(pán)空間莫名其妙就少了。這種問(wèn)題最大的迷惑性在于你根本不知道是誰(shuí)寫(xiě)的也不知道什么時(shí)候?qū)懙呐挪槠饋?lái)特別費(fèi)勁。如果是在 Linux 服務(wù)器上inode 耗盡比磁盤(pán)滿更隱蔽。一個(gè)目錄里塞了上百萬(wàn)個(gè)小文件df -h 看著還有空間但 df -i 已經(jīng) 100% 了這時(shí)候任何新文件都創(chuàng)建不了系統(tǒng)行為變得非常詭異。這類(lèi)問(wèn)題一旦發(fā)生手動(dòng)清理難度極大沒(méi)有自動(dòng)化方案幾乎只能靠重建文件系統(tǒng)來(lái)恢復(fù)。1.2 手動(dòng)清理的三個(gè)硬傷手動(dòng)清理臨時(shí)文件看起來(lái)簡(jiǎn)單實(shí)際做起來(lái)有三個(gè)繞不過(guò)去的硬傷。第一個(gè)是頻率問(wèn)題。人一定會(huì)忘記。磁盤(pán)告警才想起來(lái)去清理往往已經(jīng)是火燒眉毛的時(shí)刻。我見(jiàn)過(guò)很多人平時(shí)不關(guān)心等到發(fā)現(xiàn)磁盤(pán)滿了才臨時(shí)抱佛腳地刪文件刪完過(guò)兩個(gè)星期又滿了陷入無(wú)限循環(huán)。第二個(gè)是判斷問(wèn)題。哪些臨時(shí)文件可以刪、哪些不能刪需要根據(jù)文件的修改時(shí)間、訪問(wèn)時(shí)間、當(dāng)前是否被進(jìn)程占用來(lái)判斷。手動(dòng)操作時(shí)沒(méi)人愿意逐項(xiàng)分析結(jié)果要么一刀切亂刪要么干脆一個(gè)都不敢動(dòng)。第三個(gè)是路徑問(wèn)題。臨時(shí)文件分布在系統(tǒng)的各個(gè)角落從 /tmp、/var/tmp 到用戶目錄下的 .cache、項(xiàng)目目錄里的構(gòu)建產(chǎn)物甚至容器運(yùn)行時(shí)的 overlay 層。手動(dòng)清理很難覆蓋全而且每次執(zhí)行的操作命令可能都不一樣最終效果完全不可控。1.3 自動(dòng)化方案解決的核心問(wèn)題自動(dòng)化清理最大的價(jià)值不是“替你點(diǎn)了刪除按鈕”而是把清理這回事從“隨機(jī)事件”變成“確定性行為”。確定性的含義包括定期執(zhí)行、規(guī)則明確、操作可審計(jì)、結(jié)果可追蹤。規(guī)則明確指的是你可以精確指定哪些目錄、按什么條件、刪除多老的文件。比如“刪除 /tmp 下超過(guò) 7 天沒(méi)修改過(guò)的文件”這是一條可執(zhí)行、可驗(yàn)證的規(guī)則。操作可審計(jì)指的是每次執(zhí)行都留下日志刪了多少文件、釋放了多少空間都記錄在案出問(wèn)題能回溯。結(jié)果可追蹤則意味著你能通過(guò)日志和告警知道清理動(dòng)作是否成功、是否有異常。一旦這套東西搭建起來(lái)它就能自己運(yùn)轉(zhuǎn)不再依賴(lài)人工的臨場(chǎng)判斷。我自己的習(xí)慣是“先盤(pán)家底、再定規(guī)則、后上自動(dòng)化”下面幾個(gè)章節(jié)就是圍繞這個(gè)思路展開(kāi)的。2. 方案選型從“能用”到“好用”2.1 系統(tǒng)自帶方案不用白不用如果只看 Linux 系統(tǒng)本身其實(shí)已經(jīng)內(nèi)置了幾套基礎(chǔ)的臨時(shí)文件管理機(jī)制其中最值得了解的是 systemd-tmpfiles 和 tmpreaper。systemd-tmpfiles 通過(guò)配置文件來(lái)聲明哪些目錄要清理、按什么規(guī)則清理。配置文件放在 /etc/tmpfiles.d/ 下語(yǔ)法很直白。舉個(gè)例子# /etc/tmpfiles.d/clean-tmp.conf d /tmp 1777 root root 7d D /var/tmp 1777 root root 30d第一行表示 /tmp 目錄保留 7 天超過(guò)這個(gè)期限的文件會(huì)被 systemd-tmpfiles --clean 處理。第二行的 D 表示目錄本身和里面的內(nèi)容一起清理保留周期 30 天。這個(gè)方案的好處是零額外依賴(lài)、聲明式管理適合規(guī)則不復(fù)雜的場(chǎng)景。tmpreaper 則是傳統(tǒng) tmpwatch 的增強(qiáng)版用起來(lái)更靈活。比如這條命令tmpreaper 7d /tmp含義是刪除 /tmp 下 7 天未訪問(wèn)的文件。tmpreaper 的優(yōu)勢(shì)在于它考慮了很多邊界情況比如不會(huì)去動(dòng)正在被進(jìn)程使用的文件、知道怎么處理符號(hào)鏈接、還支持排除規(guī)則。不過(guò)在不少現(xiàn)代 Linux 發(fā)行版里systemd 已經(jīng)成為默認(rèn) init 系統(tǒng)systemd-tmpfiles 明顯是更“原汁原味”的選擇。還有一個(gè)很實(shí)用的系統(tǒng)機(jī)制是 logrotate。它管理的是日志文件不是普通臨時(shí)文件但日志和臨時(shí)文件經(jīng)常混在一起。給日志配置好按大小或日期切割再配合 rotate 份數(shù)限制能從源頭上避免日志文件無(wú)限增長(zhǎng)。很多生產(chǎn)事故其實(shí)就是日志把磁盤(pán)寫(xiě)滿了。這兩類(lèi)系統(tǒng)方案的共同問(wèn)題是“夠用但不夠細(xì)”。如果只有幾條靜態(tài)規(guī)則那直接用 systemd-tmpfiles 就夠了如果你需要按目錄、按條件、按項(xiàng)目自定義復(fù)雜的清理邏輯就得用腳本。2.2 腳本方案最靈活也最危險(xiǎn)腳本方案的核心就是兩個(gè)工具find 負(fù)責(zé)查找cron 或 systemd timer 負(fù)責(zé)定時(shí)執(zhí)行。它靈活在哪里你可以自由組合路徑、時(shí)間條件、文件類(lèi)型、大小條件還可以在刪除前做任何你想做的預(yù)處理。但是腳本方案也是最危險(xiǎn)的。原因在于find 命令是一個(gè)純粹的“執(zhí)行者”它不會(huì)理解文件是否重要。一條命令寫(xiě)錯(cuò)可能把不該刪的全刪了。比如很多人剛接觸時(shí)會(huì)寫(xiě) find / -name *.log -exec rm {} ;這行命令會(huì)去系統(tǒng)里找所有 .log 文件然后刪掉包括某些應(yīng)用正在寫(xiě)入的日志后果不堪設(shè)想。因此腳本方案的準(zhǔn)入門(mén)檻是你必須嚴(yán)格遵守“先 dry-run、再真實(shí)執(zhí)行”的原則。dry-run 就是只打印會(huì)刪除哪些文件不真正執(zhí)行刪除。這一步能幫你提前發(fā)現(xiàn)規(guī)則寫(xiě)錯(cuò)的問(wèn)題。下面這行命令就是 dry-run 的典型寫(xiě)法find /tmp -type f -mtime 7 -print先看輸出確認(rèn)列出來(lái)的文件全是該清的再把 -print 換成 -delete或者接上 -exec rm 來(lái)真正執(zhí)行。2.3 工具鏈方案處理特定生態(tài)的殘留系統(tǒng)方案和腳本方案解決的是通用臨時(shí)文件。但在真實(shí)場(chǎng)景里最有價(jià)值的是針對(duì)特定生態(tài)做清理。我舉例說(shuō)明幾類(lèi)項(xiàng)目構(gòu)建產(chǎn)物。node 項(xiàng)目里的 node_modules/.cache、dist、buildJava 項(xiàng)目里的 targetPython 項(xiàng)目里的pycache。這些目錄量大、增長(zhǎng)快而且重建成本低。清理它們通常不用猶豫?？梢詫?xiě)一個(gè)項(xiàng)目級(jí)清理腳本當(dāng)項(xiàng)目不再活躍時(shí)自動(dòng)清掉這些構(gòu)建緩存。包管理器緩存。pip 的 ~/.cache/pipnpm 的 ~/.npmapt 的 /var/cache/apt。這些緩存刪掉之后下次安裝包會(huì)重新下載但在磁盤(pán)緊張的時(shí)候它們是最好的“出血點(diǎn)”。我通常在 CI 鏡像構(gòu)建的最后階段清掉這些緩存能顯著減小鏡像體積。Docker 相關(guān)的殘留。docker system prune -f 能清理懸空鏡像和停止的容器/var/lib/docker/overlay2 里堆積的層文件是磁盤(pán)大戶。配合日志輪轉(zhuǎn)和鏡像保留策略能避免 Docker 占據(jù)大量磁盤(pán)。每種生態(tài)都有自己的一套清理規(guī)則腳本的靈活性在這里體現(xiàn)得淋漓盡致。但要注意工具鏈方案往往涉及特定業(yè)務(wù)邏輯最好能結(jié)合項(xiàng)目實(shí)際情況做保留策略而不是一刀切全刪。2.4 選型建議與對(duì)比我直接給一個(gè)決策表格方便你對(duì)號(hào)入座方案優(yōu)勢(shì)劣勢(shì)適用場(chǎng)景systemd-tmpfiles零依賴(lài)、聲明式、系統(tǒng)原生規(guī)則表達(dá)能力有限常規(guī) /tmp 和 /var/tmp 清理tmpreaper安全邊界處理較好、主動(dòng)檢查占用部分發(fā)行版需額外安裝傳統(tǒng)服務(wù)器、復(fù)雜排除規(guī)則自寫(xiě)腳本 cron/timer完全可控、可定制業(yè)務(wù)邏輯風(fēng)險(xiǎn)高依賴(lài)編寫(xiě)者水平多目錄、混合規(guī)則的項(xiàng)目環(huán)境docker system prune專(zhuān)攻容器殘留、集成度高只處理 Docker 生態(tài)CI 跑機(jī)、容器化部署環(huán)境商業(yè)/平臺(tái)級(jí)工具集中管理、告警完善引入成本高多機(jī)、多團(tuán)隊(duì)的大規(guī)模治理選型的核心原則是盤(pán)子里有多少菜決定你用多大鍋。單機(jī)服務(wù)器上幾條規(guī)則別一上來(lái)就上重量級(jí)平臺(tái)方案而真正的大規(guī)模集群環(huán)境光靠幾個(gè) cron 腳本也撐不住這時(shí)候才需要集中管理和統(tǒng)一的度量體系。3. 實(shí)操搭一套最小可用的自動(dòng)清理系統(tǒng)這一節(jié)我會(huì)完整走一遍實(shí)際搭建流程從盤(pán)家底、寫(xiě)規(guī)則到掛定時(shí)任務(wù)全部是可復(fù)現(xiàn)的命令和配置。我先說(shuō)明一下我的環(huán)境假設(shè)一臺(tái) Ubuntu 22.04 服務(wù)器Docker 和 Node 環(huán)境都有目標(biāo)是每天自動(dòng)清理各類(lèi)臨時(shí)文件。3.1 第一步盤(pán)點(diǎn)目錄和設(shè)計(jì)保留策略在動(dòng)任何命令之前先花半小時(shí)做一次“家底盤(pán)點(diǎn)”。你需要明確知道這臺(tái)機(jī)器上哪些目錄是真正需要清理的以及每個(gè)目錄的合理保留周期。我推薦的盤(pán)點(diǎn)方法是先全盤(pán)掃一遍目錄占用定位最大的幾個(gè)目錄du -h --max-depth1 /tmp 2/dev/null | sort -hr | head -20 du -h --max-depth1 /var/tmp 2/dev/null | sort -hr | head -20 du -h --max-depth2 ~/.cache 2/dev/null | sort -hr | head -20然后根據(jù)目錄實(shí)際內(nèi)容和業(yè)務(wù)要求給每個(gè)目錄設(shè)定保留周期。我給一套通用的初始策略你可以直接抄目錄保留周期說(shuō)明/tmp1~3 天系統(tǒng)臨時(shí)文件生命周期極短/var/tmp7~30 天相對(duì)持久但也不應(yīng)長(zhǎng)期堆積~/.cache/pip、~/.npm30 天重新下載成本低但沒(méi)必要天天刪項(xiàng)目 target、dist、node_modules/.cache7 天構(gòu)建產(chǎn)物可重建日志切割后的舊文件7~14 天由 logrotate 管理更佳Docker 懸空鏡像立即清理docker system prune 處理注意保留周期的設(shè)定不是拍腦袋。太短可能導(dǎo)致正在使用的文件被刪太長(zhǎng)則清理沒(méi)意義。我的經(jīng)驗(yàn)是“寧保守勿激進(jìn)”初次設(shè)定可以給到雙倍周期運(yùn)行一兩周觀察后再逐步縮短。3.2 第二步寫(xiě)核心清理腳本腳本是整套系統(tǒng)的核心。我給出一個(gè)我實(shí)際在用的版本做了精簡(jiǎn)但核心邏輯完整。它支持日志輸出、支持排除規(guī)則、也支持 dry-run 模式。#!/usr/bin/env bash # 臨時(shí)文件自動(dòng)清理腳本 # 用法: # ./clean-tmp.sh --dry-run # 只打印將刪除的文件不實(shí)際刪除 # ./clean-tmp.sh # 真實(shí)執(zhí)行清理 set -euo pipefail DRY_RUNfalse if [[ ${1:-} --dry-run ]]; then DRY_RUNtrue fi LOG_FILE/var/log/clean-tmp.log # 需要清理的目錄列表空格分隔 CLEAN_DIRS(/tmp /var/tmp /root/.cache/pip /root/.npm) # 各目錄保留天數(shù), 默認(rèn)7天 declare -A KEEP_DAYS KEEP_DAYS[/tmp]3 KEEP_DAYS[/var/tmp]14 # 排除規(guī)則的正則表達(dá)式 EXCLUDE_PATTERN(\.dockerenv|\.X11-unix|\.ICE-unix|systemd-private.*-(systemd.*)/) log() { echo $(date %Y-%m-%d %H:%M:%S) $* $LOG_FILE } clean_dir() { local dir$1 local keep_days${KEEP_DAYS[$dir]:-7} local threshold${keep_days} if [[ ! -d $dir ]]; then log SKIP: $dir not exists return 0 fi log START: $dir keep_days$keep_days if [[ $DRY_RUN true ]]; then # dry-run: 只打印 find $dir -type f -mtime $threshold \ -regextype posix-extended ! -regex $EXCLUDE_PATTERN \ -printf %p %s bytes\n else # 真實(shí)刪除刪除前統(tǒng)計(jì)空間 local before0 local after0 before$(du -sb $dir 2/dev/null | awk {print $1}) find $dir -type f -mtime $threshold \ -regextype posix-extended ! -regex $EXCLUDE_PATTERN \ -delete after$(du -sb $dir 2/dev/null | awk {print $1}) log DONE: $dir released $((before - after)) bytes fi } for d in ${CLEAN_DIRS[]}; do clean_dir $d done log ALL DONE這個(gè)腳本有幾個(gè)關(guān)鍵設(shè)計(jì)我說(shuō)一下理由。set -euo pipefail 是必須的。set -e 讓腳本在遇到錯(cuò)誤時(shí)立即退出set -u 直接爆出未定義變量pipefail 保證管道中任一環(huán)節(jié)失敗都會(huì)讓整個(gè)命令失敗。這三個(gè)組合起來(lái)能讓你第一時(shí)間發(fā)現(xiàn)腳本本身的問(wèn)題而不是讓它帶病運(yùn)行。find 命令中 -type f 避免了誤刪目錄。如果直接 -delete目錄也會(huì)被遞歸刪除風(fēng)險(xiǎn)極大。保留目錄結(jié)構(gòu)只刪除文件是更穩(wěn)妥的路徑。-delete 相比于 -exec rm {} 更安全因?yàn)?find 內(nèi)置的 -delete 會(huì)在內(nèi)部處理一些邊界情況比如先檢查目錄是否為空避免刪非空目錄時(shí)出錯(cuò)。排除規(guī)則用的是 -regextype posix-extended 和 -regex它的作用是保護(hù)特殊路徑。比如 systemd-private 動(dòng)態(tài)生成的私有目錄里面可能存有運(yùn)行時(shí) socket不能亂刪。腳本里的 du 統(tǒng)計(jì)可以幫你直觀看到每次釋放了多少空間日志對(duì)排查很有幫助。3.3 第三步配置定時(shí)任務(wù)腳本寫(xiě)好后剩下的就是讓它按時(shí)跑起來(lái)。Linux 下有兩種主流方式cron 和 systemd timer。cron 是最傳統(tǒng)的方式配置很簡(jiǎn)單。編輯 /etc/crontab 或使用 crontab -e加入一行0 2 * * * root /opt/scripts/clean-tmp.sh /var/log/clean-tmp.log 21這表示每天凌晨 2 點(diǎn)執(zhí)行一次清理腳本。為什么選這個(gè)時(shí)間因?yàn)榕R時(shí)文件清理的最佳窗口是業(yè)務(wù)低峰期大多數(shù)服務(wù)在凌晨的負(fù)載最低。如果服務(wù)器上跑著夜間批處理任務(wù)就需要避開(kāi)那段時(shí)間。systemd timer 是更現(xiàn)代的選擇。我需要先創(chuàng)建一個(gè) service 單元和一個(gè) timer 單元# /etc/systemd/system/clean-tmp.service [Unit] DescriptionClean temporary files Afternetwork.target [Service] Typeoneshot ExecStart/opt/scripts/clean-tmp.sh# /etc/systemd/system/clean-tmp.timer [Unit] DescriptionRun clean-tmp daily at 02:00 [Timer] OnCalendar*-*-* 02:00:00 Persistenttrue [Install] WantedBytimers.target然后執(zhí)行systemctl daemon-reload systemctl enable --now clean-tmp.timersystemd timer 相比 cron 有幾個(gè)優(yōu)勢(shì)可以設(shè)置 Persistenttrue即使機(jī)器當(dāng)時(shí)關(guān)機(jī)下次開(kāi)機(jī)后也會(huì)補(bǔ)跑錯(cuò)過(guò)的任務(wù)可以用 systemctl status 查看任務(wù)最近執(zhí)行情況日志集中管理方便排查。我個(gè)人的建議是新環(huán)境優(yōu)先用 systemd timer老環(huán)境沿用 cron 也沒(méi)問(wèn)題。如果你用的是 Windows 服務(wù)器最常用的方式是“任務(wù)計(jì)劃程序”配合 PowerShell 腳本。PowerShell 里頭找臨時(shí)文件同樣簡(jiǎn)單$threshold (Get-Date).AddDays(-7) Get-ChildItem -Path C:\Windows\Temp -Recurse -File | Where-Object { $_.LastWriteTime -lt $threshold } | Remove-Item -Force -ErrorAction SilentlyContinue在任務(wù)計(jì)劃程序里設(shè)置每天執(zhí)行一次即可。注意 C:\Windows\Temp 有很多文件被系統(tǒng)占用刪除時(shí)要帶上 -ErrorAction SilentlyContinue 忽略失敗否則任務(wù)會(huì)報(bào)錯(cuò)。3.4 第四步先演練再上崗腳本和定時(shí)任務(wù)都配置好了但我不建議直接讓它以真實(shí)刪除模式運(yùn)行。正確做法是先 dry-run 跑幾天。第一輪演練手動(dòng)執(zhí)行 --dry-run仔細(xì)觀察輸出內(nèi)容。重點(diǎn)看兩個(gè)問(wèn)題是否有不該刪的文件被列出來(lái)了是否有應(yīng)該清理的目錄被排除規(guī)則擋掉了。發(fā)現(xiàn)異常就調(diào)整腳本改完再跑。第二輪演練真實(shí)刪除但選擇業(yè)務(wù)最低峰期手動(dòng)執(zhí)行一次。執(zhí)行前確保已經(jīng)備份哪怕只是備份腳本并且開(kāi)啟了日志。等腳本連續(xù)跑了一周沒(méi)有異常再把它交給 cron 或 systemd timer 去自動(dòng)執(zhí)行。這時(shí)候才算真正上崗。我特別想強(qiáng)調(diào)一點(diǎn)自動(dòng)清理系統(tǒng)的“上線”不是一錘子買(mǎi)賣(mài)。它應(yīng)該像監(jiān)控系統(tǒng)一樣需要持續(xù)迭代。磁盤(pán)增長(zhǎng)趨勢(shì)變化了、業(yè)務(wù)新增了臨時(shí)文件目錄、某個(gè)服務(wù)生命周期變短了這些都要反映到清理規(guī)則里。我基本上每季度會(huì)重盤(pán)一遍目錄占用同步更新一次腳本。4. 誤刪與安全清理工具的底線工程自動(dòng)化清理的恐怖之處在于它不會(huì)疲倦也不會(huì)猶豫它是按照你的規(guī)則去執(zhí)行每一個(gè)刪除動(dòng)作。如果規(guī)則有誤它會(huì)毫不猶豫地把所有命中的文件殺掉。所以守住安全底線是這套系統(tǒng)的生死線。4.1 正在被使用的臨時(shí)文件會(huì)怎樣這個(gè)現(xiàn)象值得單獨(dú)講。很多人在 Linux 上發(fā)現(xiàn)一個(gè)詭異的事情某個(gè)文件明明被刪除了但磁盤(pán)空間并沒(méi)有釋放。這是因?yàn)橛幸粋€(gè)進(jìn)程仍然持有該文件的打開(kāi)句柄。在 Linux 的文件系統(tǒng)語(yǔ)義里文件刪除只是把目錄項(xiàng)移除但如果文件還被進(jìn)程打開(kāi)著它的 inode 和磁盤(pán)塊并不會(huì)立刻釋放要等所有句柄關(guān)閉之后才真正回收。這意味著什么如果服務(wù)在運(yùn)行時(shí)寫(xiě)了一個(gè)日志文件你把它刪了服務(wù)并不會(huì)立刻崩潰日志會(huì)繼續(xù)寫(xiě)入這個(gè)已經(jīng)“不存在”的文件里但你再也找不到這個(gè)文件了。直到服務(wù)重啟文件才被真正刪除期間磁盤(pán)空間一直占用著。排障的時(shí)候這種情況非常隱蔽。你 df -h 看磁盤(pán)空間沒(méi)少但目錄里文件又不見(jiàn)了很容易懷疑是被病毒入侵或者有日志清理任務(wù)出了問(wèn)題。其實(shí)根因可能就是有人在 /tmp 里刪了某個(gè)正在使用的文件。避免這種問(wèn)題最直接的辦法是用 lsof 檢查文件是否被占用。生產(chǎn)環(huán)境的清理腳本里我建議加一段# 檢查目錄中是否有被進(jìn)程打開(kāi)的文件 find /var/tmp -type f -mtime 7 -print0 2/dev/null | xargs -0 -r lsof 2/dev/null如果 lsof 輸出有結(jié)果說(shuō)明有文件正在使用中應(yīng)該調(diào)整保留策略或者將這些文件排除掉。4.2 權(quán)限、符號(hào)鏈接和變量空值三個(gè)經(jīng)典大坑清理腳本里最容易翻車(chē)的三個(gè)點(diǎn)權(quán)限、符號(hào)鏈接和變量空值。權(quán)限問(wèn)題很好理解很多臨時(shí)目錄屬于 root普通用戶清理不了這需要用 root 或 sudo 執(zhí)行清理腳本。但問(wèn)題在于一旦用 root 執(zhí)行腳本里哪怕有一個(gè)地方邏輯混亂后果會(huì)被無(wú)限放大。我的建議是腳本執(zhí)行的用戶權(quán)限要有明確邊界比如用獨(dú)立用戶跑清理任務(wù)不給不必要的 root 權(quán)限。符號(hào)鏈接坑是最隱蔽的。想象一下 /tmp/link 是一個(gè)指向 /etc 的符號(hào)鏈接。如果你執(zhí)行 find /tmp -type d -name link -delete危險(xiǎn)不大但如果你在腳本里寫(xiě)了 rm -rf /tmp/*在某個(gè)特殊情況下rm 會(huì)對(duì)符號(hào)鏈接指向的目標(biāo)進(jìn)行操作尤其是配合 --no-preserve-root 之類(lèi)參數(shù)時(shí)可能把系統(tǒng)關(guān)鍵目錄刪掉。我見(jiàn)過(guò)一次事故有人把 find 的 -exec rm -rf {} ; 誤應(yīng)用于一個(gè)包含符號(hào)鏈接的目錄結(jié)果把鏈接指向的應(yīng)用目錄整個(gè)刪了。所以腳本里涉及目錄刪除時(shí)務(wù)必加上 -type d 的限制并且顯式排除符號(hào)鏈接find ... ! -type l。變量空值是最容易被新手忽視的經(jīng)典坑。在 bash 腳本中如果某個(gè)變量沒(méi)有賦值默認(rèn)就是空字符串。假設(shè)你寫(xiě)了 rm -rf $DIR/而 $DIR 因?yàn)槟撤N原因是空的那么命令行就變成 rm -rf /結(jié)果是災(zāi)難性的。防范手段很簡(jiǎn)單腳本開(kāi)頭用 set -u 讓未定義變量直接報(bào)錯(cuò)或者在刪除前斷言變量非空[[ -n $DIR ]] || exit 1。順便說(shuō)一個(gè)和空格相關(guān)的坑。文件名里帶空格是合法的但很多腳本在拼接路徑時(shí)沒(méi)有加引號(hào)find 的輸出在管道傳給 xargs 時(shí)會(huì)被錯(cuò)誤分隔。處理辦法是使用 -print0 和 xargs -0或者直接用 -delete。我在 3.2 的腳本里使用 -delete就是考慮到這個(gè)。4.3 從“刪”到“移”更穩(wěn)妥的回收站模式對(duì)很多場(chǎng)景來(lái)說(shuō)直接物理刪除是不必要的冒險(xiǎn)。更穩(wěn)妥的方式是“移動(dòng)”也就是先設(shè)置一個(gè)回收桶目錄把該清理的文件移動(dòng)進(jìn)去觀察一段時(shí)間沒(méi)有異常再真正刪除。這在生產(chǎn)環(huán)境里非常實(shí)用。比如我可以把臨時(shí)文件先移到 /var/tmp/trash保留 14 天后再自動(dòng)徹底刪除。這樣即使有誤判你還有回旋余地可以手工恢復(fù)到原位置。實(shí)現(xiàn)起來(lái)也不復(fù)雜在之前的清理腳本基礎(chǔ)上把 -delete 替換成 -exec mv {} /var/tmp/trash/ 即可。我實(shí)際用下來(lái)這個(gè)模式既滿足了清理需求又大幅降低了誤刪造成的不可逆風(fēng)險(xiǎn)。唯一要注意的是回收桶目錄自身的清理別讓它變成另一個(gè)堆積點(diǎn)。給回收桶設(shè)置一個(gè)更長(zhǎng)的保留周期比如 30 天然后定期清一遍。4.4 日志、告警與問(wèn)題速查自動(dòng)化清理必須留痕。日志是事后排查的唯一依據(jù)。我在腳本里已經(jīng)把每次清理的路徑和釋放空間寫(xiě)入 /var/log/clean-tmp.log。如果你有集中日志平臺(tái)建議把這份日志同步上去如果沒(méi)有至少確保日志會(huì)按天切割避免單個(gè)文件無(wú)限增大。告警也很重要。單純把任務(wù)掛到 cron 里有效期是“靜默失敗”如果腳本出錯(cuò)了可能只會(huì)默默寫(xiě)個(gè)日志就完事。我的做法是在腳本末尾加上簡(jiǎn)單的健康檢查如果本次釋放空間為 0或者腳本執(zhí)行異常就通過(guò) webhook 發(fā)送告警到值班群。這不需要復(fù)雜的監(jiān)控平臺(tái)curl 一條 webhook 就能搞定。梳理一下常見(jiàn)問(wèn)題方便你快速定位癥狀可能原因排查方法磁盤(pán)空間沒(méi)減小文件被進(jìn)程占用未釋放lsof 檢查句柄、重啟服務(wù)后觀察日志顯示刪除了但目錄還在find 匹配的是文件目錄未被刪除檢查排除規(guī)則、目錄層級(jí)某些目錄從未被清理名稱(chēng)包含空格/特殊字符路徑拼接失敗用 -print0 驗(yàn)證開(kāi)啟 set -u清理任務(wù)不執(zhí)行cron 環(huán)境變量或 systemd timer 狀態(tài)異常systemctl status clean-tmp.timer誤刪了業(yè)務(wù)文件排除規(guī)則不完整、保留周期過(guò)短立即停止任務(wù)檢查回收桶恢復(fù)這些坑我基本上都踩過(guò)一遍。最有價(jià)值的教訓(xùn)是永遠(yuǎn)先 dry-run永遠(yuǎn)先移動(dòng)后刪除永遠(yuǎn)要留日志。記住這三條自動(dòng)清理就不會(huì)成為災(zāi)難制造機(jī)。5. 進(jìn)階多機(jī)、CI 與容器環(huán)境里的臨時(shí)文件治理5.1 給 CI 跑機(jī)做磁盤(pán)減負(fù)CI 系統(tǒng)是臨時(shí)文件堆積的重災(zāi)區(qū)。尤其是自建 GitLab Runner 或 Jenkins 節(jié)點(diǎn)每跑一次構(gòu)建都會(huì)在 workspace 和 /tmp 里留下大量中間產(chǎn)物。如果構(gòu)建頻率高磁盤(pán)空間兩三天就能告警。我處理過(guò)一臺(tái) GitHub Actions 自建 runner每天跑幾十次構(gòu)建每次構(gòu)建產(chǎn)生的臨時(shí)文件從幾十 MB 到數(shù) GB 不等。最初磁盤(pán) 100GB半個(gè)月就滿了。后來(lái)加了雙重機(jī)制解決第一重是定時(shí)清理用上面說(shuō)的腳本每天早上 4 點(diǎn)清一次第二重是構(gòu)建結(jié)束鉤子在每一個(gè) job 收尾時(shí)主動(dòng)清理該構(gòu)建產(chǎn)生的臨時(shí)目錄。構(gòu)建結(jié)束鉤子其實(shí)就是 CI 配置文件里的一段代碼比如 GitHub Actions 的 post 步驟- name: Cleanup workspace if: always() run: | docker system prune -f sudo rm -rf /tmp/* /var/tmp/* || true sudo rm -rf /home/runner/work/*/node_modules /home/runner/work/*/*/dist || true注意這里用的是 if: always()保證即使構(gòu)建失敗清理也會(huì)執(zhí)行。CI 跑機(jī)的治理思路是定時(shí)清理兜底構(gòu)建鉤子主動(dòng)清理雙保險(xiǎn)。另外 CI 鏡像構(gòu)建階段清掉包管理器緩存能顯著減小鏡像體積、縮短推送時(shí)間。5.2 多機(jī)統(tǒng)一治理從“單機(jī)腳本”到“批量執(zhí)行”當(dāng)服務(wù)器數(shù)量多到一定程度逐臺(tái)配置 cron 是不可維護(hù)的。這時(shí)候需要把清理規(guī)則集中管理。我常用的方案有兩種。一種是用 Ansible 之類(lèi)的配置管理工具。把清理腳本和 timer 單元作為基礎(chǔ)設(shè)施代碼推送到所有目標(biāo)機(jī)器。好處是配置變更可以快速批量生效而且可以統(tǒng)一版本管理。另一種是搭建一個(gè)簡(jiǎn)單的中心化日志和告警管道每臺(tái)機(jī)器跑完清理后把結(jié)果匯總到同一處比如收集日志到 Elasticsearch 或用簡(jiǎn)單的 Webhook 上報(bào)。批量執(zhí)行時(shí)有一個(gè)重要細(xì)節(jié)不要在同一時(shí)間讓所有機(jī)器同時(shí)清理否則可能會(huì)同時(shí)觸發(fā)集中監(jiān)控平臺(tái)的告警風(fēng)暴也可能造成集中的 I/O 沖擊。給每臺(tái)機(jī)器的清理時(shí)間加上隨機(jī)偏移量比如 2 點(diǎn)到 3 點(diǎn)之間隨機(jī)執(zhí)行是一個(gè)成熟的做法。在 Kubernetes 集群里情況稍有不同。節(jié)點(diǎn)的臨時(shí)目錄和容器的 emptyDir 卷由 kubelet 管理kubelet 會(huì)根據(jù) eviction 閾值自動(dòng)驅(qū)逐容器釋放臨時(shí)存儲(chǔ)。但這是“兜底式”的治理主要目的是避免整個(gè)節(jié)點(diǎn)磁盤(pán)寫(xiě)滿。業(yè)務(wù)層面仍然需要自己管理鏡像殘留和構(gòu)建緩存。docker system prune 在容器節(jié)點(diǎn)上仍然很有用配合定期執(zhí)行能顯著減少磁盤(pán)占用。5.3 容器場(chǎng)景的特殊考量容器里的 /tmp 和宿主機(jī)上的 /tmp 有本質(zhì)不同。容器內(nèi)每個(gè)文件系統(tǒng)層都是臨時(shí)的容器刪除后層也隨之消失。但也因此產(chǎn)生了一個(gè)問(wèn)題如果你在容器里堆積了大量臨時(shí)文件而容器長(zhǎng)期不重建這些文件會(huì)一直占著內(nèi)存或磁盤(pán)。兩個(gè)實(shí)踐建議第一容器內(nèi)盡量避免使用 /tmp 做持久化存儲(chǔ)應(yīng)該使用掛載卷或者 emptyDir第二對(duì)跑長(zhǎng)時(shí)間任務(wù)的有狀態(tài)容器定期重建是比清理內(nèi)部臨時(shí)文件更徹底的辦法。docker system prune 這個(gè)命令我在前面提到了展開(kāi)說(shuō)幾個(gè)參數(shù)docker system prune -f --volumes --filter until72h-f 表示不交互確認(rèn)--volumes 表示同時(shí)清理未使用的卷--filter until72h 只清理 72 小時(shí)前創(chuàng)建的懸空資源。這個(gè)命令特別適合 CI 跑機(jī)清理效果立竿見(jiàn)影。但注意默認(rèn)情況下 docker system prune 不會(huì)清理還在使用的鏡像和容器這一點(diǎn)安全性還可以不過(guò)加上 --volumes 之后要確認(rèn)沒(méi)有重要的持久卷被誤傷。還有一類(lèi)常見(jiàn)容器殘留是構(gòu)建緩存。BuildKit 的緩存目錄可能非常龐大。對(duì)應(yīng)清理命令是 docker builder prune -f建議在 CI 構(gòu)建完成后定期執(zhí)行?？偨Y(jié)一下容器的清理哲學(xué)優(yōu)先重建其次治理鏡像最后才是容器內(nèi)部清理。5.4 建立長(zhǎng)效機(jī)制從“清理”到“預(yù)防”臨時(shí)文件治理的終極目標(biāo)不是“清得多”而是“產(chǎn)生得少”。當(dāng)自動(dòng)化方案穩(wěn)定運(yùn)行之后我會(huì)建議你花更多時(shí)間從源頭減少臨時(shí)文件的產(chǎn)生。具體可以做的事情很多規(guī)范日志切割配置 logrotate 的 maxsize 和 rotate統(tǒng)一包管理器緩存目錄并設(shè)置定期清理在 CI 流水線里對(duì)構(gòu)建產(chǎn)物做歸檔并自動(dòng)刪除舊版本使用 tmpfs 掛載 /tmp讓系統(tǒng)重啟時(shí)臨時(shí)空間自動(dòng)清空對(duì)需要的臨時(shí)數(shù)據(jù)直接寫(xiě)入內(nèi)存文件系統(tǒng)而不是寫(xiě)盤(pán)再刪。以 tmpfs 為例把 /tmp 掛載到內(nèi)存中讀寫(xiě)速度快是一個(gè)好處更關(guān)鍵的是重啟后內(nèi)容自動(dòng)清空完全不需要人為干預(yù)。但有個(gè)前提內(nèi)存要夠大否則 /tmp 占滿內(nèi)存反而影響系統(tǒng)穩(wěn)定性。在內(nèi)存資源充足的服務(wù)器上這是一個(gè)很優(yōu)雅的方案。預(yù)防思維的本質(zhì)是把“清理臨時(shí)文件”這件苦差事從“事后補(bǔ)救”變成“設(shè)計(jì)時(shí)考慮”。你可以在系統(tǒng)設(shè)計(jì)階段就把臨時(shí)文件的存儲(chǔ)路徑、保留時(shí)長(zhǎng)、清理責(zé)任劃分清楚。能做到這一步之后維護(hù)的負(fù)擔(dān)會(huì)直線下降?；氐轿易约旱捏w會(huì)臨時(shí)文件自動(dòng)化治理最被低估的價(jià)值其實(shí)不是省了多少 GB 磁盤(pán)而是讓系統(tǒng)行為變得可預(yù)期。定時(shí)任務(wù)每天都在跑日志每天都在記磁盤(pán)占用曲線慢慢變得平緩。那種“不知道哪一天磁盤(pán)會(huì)滿”的焦慮感消失之后你才有余力去做更有價(jià)值的事。這套方案本身不復(fù)雜但它需要你一點(diǎn)點(diǎn)打磨從單機(jī)腳本到多機(jī)批量從被動(dòng)清理到主動(dòng)預(yù)防每一步都是在為系統(tǒng)的長(zhǎng)期穩(wěn)定夯實(shí)基礎(chǔ)。最后再分享一條個(gè)人經(jīng)驗(yàn)每次清理腳本變更后至少保留一周的 dry-run 日志不要急著刪除。這些日志是你在排查“是不是清理腳本誤刪了文件”時(shí)最有力的證據(jù)。臨時(shí)文件清理這種操作寧可慢一點(diǎn)、啰嗦一點(diǎn)也千萬(wàn)別拿生產(chǎn)環(huán)境做賭注。