用了這么多年Linux/dev、/sys、/proc這三個目錄幾乎天天都在打交道但你有沒有真正想過它們到底是誰創(chuàng)建的、底層跑的是什么機制、為什么有的文件能直接cat出信息、有的文件寫進去一個數(shù)字系統(tǒng)行為就變了這篇文章不打算講教科書上那種照本宣科的科普而是從一個實際運維和開發(fā)者的視角把這三大虛擬文件系統(tǒng)的來龍去脈、核心設計、實操玩法以及我踩過的坑一次性講透。對于剛接觸Linux的朋友這三個目錄是繞不開的“詭異存在”——它們不占用磁盤空間文件大小經(jīng)常是0可偏偏是系統(tǒng)運行的核心樞紐。對于有經(jīng)驗的工程師理解這幾個目錄的內(nèi)部邏輯不只是為了面試更是排查硬件故障、調(diào)整內(nèi)核參數(shù)、做性能分析的基本功。我盡量用類比和現(xiàn)場實例把背后的原理講明白讀完你再去敲ls /dev、cat /proc/meminfo、find /sys/class感官會完全不一樣。1. 三個目錄的整體定位與設計思路1.1 它們不是普通目錄而是“虛擬文件系統(tǒng)”的掛載點第一次接觸Linux的人往往會問為什么/dev、/proc、/sys在df -h里看不到占用空間卻又能“存”東西答案很簡單它們根本不是磁盤上的目錄而是內(nèi)核在內(nèi)存中構(gòu)建出來的虛擬文件系統(tǒng)掛載到了對應路徑。你可以用mount命令確認一下常見的輸出類似這樣$ mount | grep -E /dev|/proc|/sys devtmpfs on /dev type devtmpfs (rw,nosuid,relatime,size65052k,nr_inodes65052,mode755) proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)注意它們的文件系統(tǒng)類型分別是devtmpfs、proc、sysfs都不是ext4或xfs這種真正的磁盤文件系統(tǒng)。換句話說你“看到”的文件、目錄、屬性都是內(nèi)核按需生成并呈現(xiàn)在你面前的背后沒有物理存儲介質(zhì)。這個設計思路很妙對用戶態(tài)程序訪問設備信息、進程狀態(tài)、內(nèi)核參數(shù)統(tǒng)一走“打開文件、讀寫文件”這套熟悉接口不用發(fā)明新API也不用手寫一堆ioctl調(diào)用。1.2 三個目錄的分工設備節(jié)點、進程信息、設備模型說白了一句話記法/dev是“設備的入口”/proc是“進程與內(nèi)核的臨時窗口”/sys是“設備與驅(qū)動的結(jié)構(gòu)化視圖”。三者緊密關聯(lián)但定位不同。/dev提供設備訪問節(jié)點。你想讀寫硬盤、串口、聲卡都是打開/dev/下面的某個文件。這里核心是“能操作”是向磁盤、硬件驅(qū)動發(fā)請求的通道。/proc提供進程級別和內(nèi)核級別的運行時信息。比如系統(tǒng)負載、內(nèi)存使用、每個進程的映射、命令行參數(shù)。核心是“看狀態(tài)、改參數(shù)”最早的動態(tài)內(nèi)核參數(shù)入口就在這里。/sys提供設備、驅(qū)動、總線之間關系的結(jié)構(gòu)化視圖。核心是“管設備”它把內(nèi)核設備模型暴露出來你能看到一塊SSD掛在哪個控制器下、某個驅(qū)動綁定哪個設備也能在運行時調(diào)整設備級參數(shù)比如風扇轉(zhuǎn)速、屏幕背光。如果還不直觀打個比方/dev像一個小區(qū)大門口的門禁設備你刷個卡就能進出具體單元/proc像是物業(yè)中心的公告欄上面實時貼著整個小區(qū)的運行數(shù)據(jù)有些欄位還允許你貼新通知來調(diào)規(guī)則/sys則是整個小區(qū)的規(guī)劃沙盤每一棟樓、每一條管道、每一個設備都按樹狀結(jié)構(gòu)擺得明明白白還能撥動沙盤上的旋鈕做實時調(diào)整。1.3 為什么內(nèi)核不把這些功能做成普通命令而要做成文件這個設計是UNIX哲學的一部分“一切皆文件”。做成文件的好處顯而易見shell、Python、Perl甚至grep、awk、dd都能直接處理不用專門寫復雜的用戶態(tài)工具。想獲取CPU信息直接cat /proc/cpuinfo想給指定PID發(fā)個狀態(tài)查詢cat /proc/1234/status。這在排查生產(chǎn)問題時有巨大優(yōu)勢——很多場景下系統(tǒng)已經(jīng)嚴重卡頓連常規(guī)工具都起不來但cat一個文件這種原子操作仍然可以執(zhí)行這些虛擬文件系統(tǒng)此時就是最后的救命通道。2. /dev目錄設備文件系統(tǒng)的入口與實操要點2.1 字符設備、塊設備與設備號/dev中絕大部分文件對應兩類設備字符設備和塊設備。字符設備以字節(jié)流方式讀寫比如鍵盤、串口、聲卡每次讀寫不經(jīng)過緩存層典型代表是/dev/null、/dev/tty。塊設備以固定大小的塊為單位讀寫數(shù)據(jù)可以走緩存、排隊、合并典型代表是磁盤/dev/sda、分區(qū)/dev/sda1。怎么快速區(qū)分ls -l第一列是c就是字符設備b就是塊設備。而設備文件最核心的標識其實是“設備號”也就是主設備號和次設備號$ ls -l /dev/sda /dev/tty /dev/null brw-rw---- 1 root disk 8, 0 1月 5 10:00 /dev/sda crw-rw-rw- 1 root tty 5, 0 1月 5 10:00 /dev/tty crw-rw-rw- 1 root root 1, 3 1月 5 10:00 /dev/null這里8, 0表示主設備號8、次設備號0。主設備號對應驅(qū)動類型內(nèi)核靠它找到正確的設備驅(qū)動次設備號用于區(qū)分同一驅(qū)動下的不同物理設備或邏輯單元。/dev/sda和/dev/sdb共享主設備號8都是同一套SATA/SCSI磁盤驅(qū)動只是次設備號不同。注意設備文件本身只是“門牌”不包含設備數(shù)據(jù)。真正干活的是內(nèi)核驅(qū)動。你可以把設備文件理解成一個指向驅(qū)動程序的門牌號應用程序open它時內(nèi)核根據(jù)門牌號找到驅(qū)動之后read/write就是驅(qū)動和硬件在交互。2.2 devtmpfs與udev設備節(jié)點的自動生成機制在老版本Linux里要在/dev下創(chuàng)建設備節(jié)點需要手寫mknod還得知道主次設備號維護成本極高。現(xiàn)代系統(tǒng)采用兩套機制配合內(nèi)核啟動早期掛載devtmpfs由內(nèi)核自身為已經(jīng)識別的設備自動創(chuàng)建設備節(jié)點保證基本可用隨后udev守護進程接管根據(jù)內(nèi)核發(fā)出的uevent事件和規(guī)則文件做符號鏈接、權(quán)限設置、命名調(diào)整。比如一塊USB盤插上內(nèi)核識別后自動在/dev下生成/dev/sdbudev再根據(jù)/dev/disk/by-uuid/之類的規(guī)則補建友好的穩(wěn)定鏈接。手動創(chuàng)建設備節(jié)點的能力仍然值得掌握某些容器環(huán)境、嵌入式裁剪系統(tǒng)或恢復場景下設備節(jié)點缺失很常見一條mknod命令能救命mknod /dev/testnull c 1 3這條命令創(chuàng)建一個字符設備主設備號1、次設備號3恰好對應null設備。創(chuàng)建完你可以echo hi /dev/testnull完全不會報錯。反過來如果忘記指定主次設備號或搞錯類型open設備會直接失敗。這也是排查“設備節(jié)點存在但無法訪問”問題時的關鍵步驟——節(jié)點只是入口入口對了驅(qū)動不對一樣出錯。2.3 常見設備節(jié)點及用途速查長期和Linux打交道的開發(fā)者至少要和下面這些設備節(jié)點熟起來設備節(jié)點類型常見用途/dev/sda、/dev/nvme0n1塊設備整塊磁盤訪問配合fdisk、parted分區(qū)/dev/sda1、/dev/nvme0n1p1塊設備磁盤分區(qū)/dev/ttyS0字符設備串口調(diào)試嵌入式設備、網(wǎng)絡設備/dev/tty字符設備當前終端echo test /dev/tty直接顯示在當前屏/dev/null字符設備丟棄一切寫入數(shù)據(jù)讀取返回EOF最常見的“黑洞”/dev/zero字符設備讀取永遠返回0字節(jié)用于清零或生成空數(shù)據(jù)/dev/random、/dev/urandom字符設備隨機數(shù)源urandom性能更好現(xiàn)代系統(tǒng)兩者基本等價/dev/loop0塊設備回環(huán)設備將鏡像文件模擬成塊設備掛載iso、ext4鏡像必備/dev/mapper/xxx塊設備設備映射器LVM、dm-crypt生成的邏輯設備實操中一個高頻用法是用/dev/zero配合dd生成指定大小的臨時文件dd if/dev/zero of./alldata.bin bs1M count1024 statusprogress這會在當前目錄生成一個1G的全零文件經(jīng)常用來做稀疏文件測試、磁盤性能測試或者制造占位文件。同理把if/dev/urandom加進去就能生成隨機內(nèi)容文件。這個“文件即設備、設備即文件”的思路在處理數(shù)據(jù)時真的非常順手。2.4 /dev的實操排查思路業(yè)務上遇到“無法識別磁盤”的問題我的排查順序基本固定。先lsblk看內(nèi)核是否能發(fā)現(xiàn)設備再ls -l /dev/看節(jié)點是否存在。如果內(nèi)核發(fā)現(xiàn)了但節(jié)點沒創(chuàng)建多半是udev規(guī)則問題查看udevadm monitor抓取uevent確認規(guī)則是否攔截了命名如果節(jié)點存在但dd讀寫報錯再dmesg看看底層驅(qū)動有沒有I/O錯誤、鏈路是否正常。這里要特別強調(diào)不要手動在正常系統(tǒng)里亂刪/dev下面的設備節(jié)點再靠mknod重建因為udev規(guī)則和selinux上下文可能對不上重啟或拔插后反而更亂正常環(huán)境請讓udev管好它自己。3. /proc目錄進程與內(nèi)核狀態(tài)的信息中樞3.1 procfs的設計理念沒有文件的文件系統(tǒng)/proc在早期Linux中是個很特別的存在它不存數(shù)據(jù)而是在你打開某一文件、讀取某一目錄時內(nèi)核動態(tài)調(diào)用相應函數(shù)生成內(nèi)容。/proc下沒有磁盤塊、沒有inode一切都是“現(xiàn)算現(xiàn)賣”。所以你看到很多文件大小是0但cat依然能輸出一堆內(nèi)容——這就是虛擬文件系統(tǒng)的特征。/proc最初是為了進程信息而創(chuàng)建后來內(nèi)核參數(shù)也塞了進來逐漸成了大雜燴。這也是后來/sys被設計出來的原因之一/proc什么都有但結(jié)構(gòu)混亂、分類不清晰、權(quán)限粒度粗糙。3.2 /proc三大類內(nèi)容進程目錄、系統(tǒng)信息、內(nèi)核參數(shù)最核心的內(nèi)容分三類。第一類是/proc/[PID]/目錄每個運行中的進程都有一個以其PID命名的目錄。進入任意一個進程目錄status看狀態(tài)、cmdline看完整命令行、environ看環(huán)境變量、fd/看打開的文件描述符、maps看內(nèi)存映射。第二類是系統(tǒng)級信息比如/proc/cpuinfoCPU型號與特性、/proc/meminfo內(nèi)存使用細節(jié)、/proc/loadavg系統(tǒng)負載、/proc/uptime開機時長與空閑時長、/proc/interrupts中斷統(tǒng)計。第三類是內(nèi)核可調(diào)參數(shù)目錄/proc/sys/它與sysctl命令對應幾乎是內(nèi)核運行時調(diào)優(yōu)的主戰(zhàn)場。舉一個實操例子線上排查CPU使用率異常時除了top我會直接看進程的/proc/[PID]/status和/proc/[PID]/schedstat判斷是不是發(fā)生了綁定異常或大量自愿上下文切換?？茨硞€進程打開了哪些文件則可直接ls -l /proc/[PID]/fd比lsof在某些受限環(huán)境里更原始可靠$ ls -l /proc/1234/fd | head total 0 lrwx------ 1 user user 64 1月 5 10:00 0 - /dev/null lrwx------ 1 user user 64 1月 5 10:00 1 - /var/log/app.log lr-x------ 1 user user 64 1月 5 10:00 2 - /etc/app.conf3.3 內(nèi)核參數(shù)調(diào)整/proc/sys與sysctl的關系/proc/sys下面的文件很多可以直接寫寫入即生效。但要注意兩點第一寫操作需要root權(quán)限第二這樣修改是臨時的重啟后丟失。持久化要通過/etc/sysctl.conf或/etc/sysctl.d/下的配置文件。sysctl命令本質(zhì)上就是在讀寫/proc/sys比如以下兩條命令是等價的echo 1 /proc/sys/net/ipv4/ip_forward sysctl -w net.ipv4.ip_forward1在修改內(nèi)核參數(shù)前我強烈建議先確認當前值和上下文。比如要啟用IP轉(zhuǎn)發(fā)先cat /proc/sys/net/ipv4/ip_forward再確認網(wǎng)絡架構(gòu)中是否存在多個網(wǎng)卡之間需要轉(zhuǎn)發(fā)流量否則開著轉(zhuǎn)發(fā)在安全敏感環(huán)境里可能有風險。更常規(guī)的做法是修改/etc/sysctl.conf后執(zhí)行sysctl -p這樣既能持久化也能檢查語法。另外/proc/sys下的參數(shù)命名規(guī)律很有用/proc/sys/net/ipv4/tcp_tw_reuse對應net.ipv4.tcp_tw_reuse就是把路徑中的/proc/sys/前綴和斜杠換成點。3.4 一個需要注意的特殊文件/proc/kcore 與 /proc/sysrq-trigger/proc/kcore是內(nèi)核核心內(nèi)存的映像大小跟你物理內(nèi)存差不多但別拿cat去讀也別隨手cp否則系統(tǒng)會卡死。要分析內(nèi)核內(nèi)存請用crash、gdb等專門機制或者直接繞過這個文件。另一個常被忽視的/proc/sysrq-trigger則是系統(tǒng)卡死時的終極逃生門允許你向內(nèi)核發(fā)送特殊序列命令。比如系統(tǒng)完全無響應但還能按下鍵時執(zhí)行echo s /proc/sysrq-trigger echo u /proc/sysrq-trigger echo b /proc/sysrq-triggerecho s同步磁盤echo u只讀方式重新掛載文件系統(tǒng)echo b立即重啟。整套組合拳在運維現(xiàn)場曾經(jīng)救過我一回。生產(chǎn)環(huán)境要提前確認內(nèi)核/proc/sys/kernel/sysrq的值不為0否則sysrq-trigger會被禁用。3.5 /proc容易踩坑的細節(jié)有一個我踩過不少次的坑解析/proc/meminfo時不同內(nèi)核版本字段名稱會有變動比如MemFree里可能包含被內(nèi)核回收的緩存如果直接拿它判斷“內(nèi)存還夠不夠”經(jīng)常會被誤導。我更習慣看MemAvailable這是內(nèi)核經(jīng)過算法預估的可分配內(nèi)存比MemFree更有參考意義。另一個坑是/proc/[PID]/status中的VmRSS只能代表物理內(nèi)存駐留量無法完全等價于程序真正占用的內(nèi)存如果程序有共享庫映射VmRSS會重復計算共享部分精確分析得綜合smaps里的細分項。4. /sys目錄設備模型與內(nèi)核對象的結(jié)構(gòu)化視圖4.1 sysfs的誕生對癥下藥解決/proc的混亂/sys對應的文件系統(tǒng)叫sysfs出現(xiàn)在Linux 2.6時代核心目的就是“收拾”/proc這個雜物間。它把內(nèi)核的設備和驅(qū)動模型以嚴格的層次結(jié)構(gòu)暴露給用戶空間。如果說/proc是按用途堆文件那么/sys就是按“設備拓撲”建目錄。你在/sys下看到的目錄名稱背后都對應著內(nèi)核中的kobject對象目錄的嵌套結(jié)構(gòu)對應kobject之間的父子關系。這也是理解/sys最關鍵的一點它不是隨便設計的目錄樹它是內(nèi)核設備模型在用戶態(tài)的真實映射。4.2 核心子目錄速覽/sys/devices、/sys/bus、/sys/class、/sys/block/sys/devices是最底層真實的設備樹包含系統(tǒng)總線PCIe、USB、平臺總線等上所有真實設備路徑冗長但最完整。/sys/bus按總線類型組織是查找設備和驅(qū)動綁定的近路比如/sys/bus/pci/devices/下列出所有PCI設備每個設備目錄下有driver符號鏈接指向當前綁定的驅(qū)動。/sys/class按設備功能分類比如net下是網(wǎng)卡、block下是塊設備、backlight下是屏幕背光、thermal下是溫度傳感器這種分類最貼近日常使用。/sys/block是塊設備專屬視圖軟鏈到真實設備路徑。查看某個nvme固態(tài)硬盤的信息可以這樣$ ls -l /sys/class/block/nvme0n1 lrwxrwxrwx 1 root root 0 1月 5 10:00 /sys/class/block/nvme0n1 - ../../devices/pci0000:00/0000:00:01.0/0000:01:00.0/nvme/nvme0/nvme0n1順著這條軟鏈能看到它掛在哪個PCI控制器下進而判斷是不是接了轉(zhuǎn)接卡、走的是不是直通CPU的PCIe通道。4.3 實用場景通過/sys讀取設備狀態(tài)與調(diào)節(jié)參數(shù)/sys里很多文件是只讀的但不乏可寫的高頻參數(shù)入口。比如查看CPU頻率策略直接讀/sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq單位是kHz。調(diào)整最大最小頻率則寫對應文件echo 2400000 /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq再比如查看硬盤溫度部分NVMe設備支持cat /sys/class/nvme/nvme0/device/hwmon/hwmon*/temp1_input輸出的是毫攝氏度除以1000就是正常攝氏度讀數(shù)。另一個高頻操作是背光亮度調(diào)節(jié)筆記本場景下/sys/class/backlight/intel_backlight/brightness可以直接寫數(shù)值比在桌面環(huán)境里拖滑塊更快多級腳本調(diào)光也常走這里。但切記這些寫入操作都是臨時的重啟后復位需要持久化請走systemd服務或?qū)挠布橄髮庸ぞ摺?.4 sysfs與uevent/udev的關系/sys不只是給人看的也是給用戶態(tài)事件機制用的。內(nèi)核檢測到設備插入或移除時sysfs會生成uevent事件udev通過netlink監(jiān)聽到這些事件后根據(jù)規(guī)則在/dev下創(chuàng)建設備節(jié)點、創(chuàng)建符號鏈接、設置權(quán)限。你可以在命令行手工觸發(fā)uevent重放讓udev重新處理某個設備這在調(diào)試設備規(guī)則時非常有用echo change /sys/class/net/eth0/uevent執(zhí)行后udev會重新處理eth0的change事件。調(diào)試網(wǎng)卡改名規(guī)則、權(quán)限規(guī)則時配合udevadm monitor看實時事件輸出整個鏈路清晰可見。所以/sys與/dev的關系可以理解為/sys是設備和驅(qū)動的“關系網(wǎng)”/dev是面向應用訪問的“操作門戶”而uevent是維護門戶的更新信號。4.5 使用/sys排查硬件問題的經(jīng)驗拿到一臺服務器懷疑網(wǎng)卡掉速或PCIe降速我會查/sys/bus/pci/devices/0000:xx:00.0/目錄下的link_speed、link_width對比設備原始能力和當前協(xié)商狀態(tài)。同樣命令cat /sys/class/net/eth0/carrier顯示1表示物理鏈路正常0表示沒插線或?qū)Ψ皆O備未啟動cat /sys/class/net/eth0/operstate則直接顯示up、down、unknown等狀態(tài)。遇到NVMe設備掉盤/sys/class/nvme/nvme0/device/下經(jīng)常能看到健康信息nvme smart-log也是讀同一套數(shù)據(jù)只是通過字符設備另外暴露兩者可以交叉驗證。5. 三個目錄的差異對比與整體協(xié)作5.1 一張表看懂三者核心區(qū)別對比項/dev/proc/sys文件系統(tǒng)類型devtmpfs、udev管理procsysfs核心內(nèi)容設備文件節(jié)點進程信息、內(nèi)核信息與參數(shù)設備、驅(qū)動、總線拓撲是否真實占磁盤否否否典型操作open、read、write設備cat查看、echo修改內(nèi)核參數(shù)cat查看、echo修改設備參數(shù)主要設計目的提供設備訪問入口進程與內(nèi)核運行時狀態(tài)結(jié)構(gòu)化設備模型與運行期配置內(nèi)容是否可寫多數(shù)不可寫/proc/sys下可寫部分屬性文件可寫持久性動態(tài)重建改動重啟丟失改動重啟丟失常用命令lsblk、fdisk、dd、mknodps、lsof、sysctl、catudevadm、cat、echo、find這張表基本可以覆蓋日常工作的認知。重點提示三者都不是永久存儲不要指望在里面保存數(shù)據(jù)。曾有同事把配置寫到/proc下面的臨時文件里重啟機器什么都沒了這種用法天然就是錯的。真正的配置要么寫到/etc要么通過systemd單元重啟后自動重建。5.2 三者在一次磁盤故障排查中的聯(lián)合用法我用一個非常典型的磁盤故障場景把三個目錄串起來。某次線上機器告警某塊數(shù)據(jù)盤讀寫超時。我先執(zhí)行l(wèi)sblk確認盤符為/dev/sdc接著cat /sys/class/block/sdc/device/state查看設備狀態(tài)發(fā)現(xiàn)狀態(tài)異常。隨后dmesg確認I/O錯誤再看cat /proc/diskstats統(tǒng)計該磁盤的IO錯誤計數(shù)最后smartctl -a /dev/sdc獲取SMART健康信息綜合判斷是物理磁盤即將損壞及時更換。整個過程涉及/dev、/proc、/sys互補/dev給出訪問入口/proc給出全局IO統(tǒng)計/sys給出設備與驅(qū)動狀態(tài)。少任何一個目錄排查效率和信息完整性都會大打折扣。5.3 容器環(huán)境下的新變化近年容器化普及后這三個目錄的行為出現(xiàn)了新差異。容器內(nèi)部的/proc和/sys通常并非宿主機全局視圖而是掛載了帶有命名空間隔離或只讀約束的副本。在容器里cat /proc/meminfo會看到宿主機的物理內(nèi)存但/proc/[PID]/下的很多進程在容器外的父進程視角完全不同早期版本的Docker默認以只讀方式掛載/sys部分子目錄導致在容器內(nèi)調(diào)節(jié)某些設備參數(shù)直接報Read-only file system。排查這類問題時要先mount | grep sysfs確認掛載參數(shù)不要想當然認為容器內(nèi)能改宿主機的設備參數(shù)。安全上這是合理限制也是Linux內(nèi)核持續(xù)演進的方向之一。6. 常見問題與避坑經(jīng)驗實錄6.1 誤刪/dev節(jié)點如何恢復偶爾會有人誤刪/dev/null、/dev/sda。正常系統(tǒng)下最快恢復方式是借助mknod重建前提是你知道正確的主次設備號和類型。比如恢復null設備rm -f /dev/null mknod /dev/null c 1 3 chmod 666 /dev/null執(zhí)行前用ls -l /dev/null查詢原屬性最為穩(wěn)妥。如果是磁盤類設備節(jié)點損壞優(yōu)先考慮重啟或觸發(fā)udev重放而不是手動mknod重建否則分區(qū)符號鏈接、磁盤組、設備映射器的依賴容易對不上。嵌入式和容器里沒有udev才需手動mknod這時明確自己系統(tǒng)里設備的主次設備號就是基本功了可以在同型號正常機器上查好了備用。6.2 為什么cat /proc/xxx發(fā)現(xiàn)文件大小是0這完全正常。虛擬文件系統(tǒng)沒有真實數(shù)據(jù)塊文件大小通常表示不了什么。讀取時動態(tài)生成內(nèi)容才是它的工作方式。所以不要因為ls -l /proc/meminfo顯示0就把它當成空文件直接用cat看內(nèi)容。相關地du -h /proc也毫無意義它會顯示0反而可能讓你誤判。6.3 修改/sys或/proc參數(shù)后重啟失效這不是bug而是設計。/proc/sys和/sys的可調(diào)參數(shù)屬于運行時設置以內(nèi)核內(nèi)存為存儲介質(zhì)重啟必然恢復默認。要實現(xiàn)持久化/proc/sys走/etc/sysctl.conf或/etc/sysctl.d/*.conf/sys設備參數(shù)沒有統(tǒng)一持久化入口一般通過systemd服務、rc.local或者udev規(guī)則在開機時重新寫入。我自己寫過一個專門調(diào)背光和CPU頻率閾值的systemd unitExecStart里逐行echo生產(chǎn)環(huán)境中穩(wěn)定復現(xiàn)比依賴具體桌面環(huán)境可靠得多。6.4 修改/sys或/proc提示Permission denied兩種常見情況非root用戶權(quán)限不足文件本身被內(nèi)核標記為只讀。對于root用戶仍報拒絕的多數(shù)是掛在只讀屬性上echo前先cat /sys/.../文件確認當前內(nèi)容再判斷內(nèi)核是否允許寫。有些參數(shù)受其他子系統(tǒng)約束比如CPU頻率受熱保護策略干預即使寫入了也會被內(nèi)核自動糾正反復改不生效時先看dmesg和thermal相關文件。6.5 /dev/random和/dev/urandom到底用哪個現(xiàn)代Linux內(nèi)核里/dev/random和/dev/urandom的差異已經(jīng)大幅縮小。早期隨機數(shù)池估計不足時random讀多了會阻塞urandom不會今天兩者底層共享相同的CRNG密碼學隨機數(shù)生成器僅在啟動初期存在理論差異。絕大多數(shù)業(yè)務場景直接用/dev/urandom即可需要高安全性且能容忍阻塞的場景才考慮讀/dev/random。生成密鑰或會話令牌時優(yōu)先建議直接用內(nèi)核提供的getrandom()系統(tǒng)調(diào)用而不是手動打開設備文件更簡潔也更規(guī)范。6.6 在/sys或/proc里誤寫危險參數(shù)導致系統(tǒng)異常/proc/sys/kernel/panic被設為0以上時內(nèi)核panic后會自動重啟/proc/sys/vm/drop_caches寫入1、2、3會丟棄頁緩存、目錄項或inode緩存對啟動時內(nèi)存吃緊的系統(tǒng)可能造成短暫卡頓/sys下某些電源管理文件寫錯可能導致設備直接掉電。因此任何寫操作特別是生產(chǎn)環(huán)境一是提前備份原值二是先確認文件語義三是寫好回滾方案。如果只是臨時測試建議在測試機或容器環(huán)境內(nèi)驗證再推廣到生產(chǎn)。7. 一點實操心得這三個目錄用熟了你對Linux的認知會有實質(zhì)提升。我最深的體會是它們不是三個獨立零散的文件夾而是內(nèi)核向用戶態(tài)開的三扇窗/dev提供出入口/proc反映運行時狀態(tài)/sys描述設備關系。排查思路的起點就是先想清楚當前問題該看哪扇窗而不是盲目地在所有目錄里翻找。最后再分享一個提高效率的小技巧善用find在兩個虛擬目錄組合搜索。比如你想找出所有可調(diào)亮的背光設備一條命令find /sys/class -maxdepth 2 -name brightness -type f直接定位想確認哪些進程還打開著某個已經(jīng)被刪除的文件find /proc/*/fd -lname *deleted*能快速掃出來。這些操作沒有復雜的工具依賴純shell就能完成在救援模式下尤為好用。多讀、多試、多對比/dev、/proc、/sys會成為你最順手的Linux排查利器。