關於 /proc/sys/kernel/ 的文件

版權所有 (c) 1998, 1999, Rik van Riel <riel@nl.linux.org>

版權所有 (c) 2009, Shen Feng<shen@cn.fujitsu.com>

有關常規資訊和法律宣告，請參閱 關於 /proc/sys 的文件。

此檔案包含 /proc/sys/kernel/ 中 sysctl 檔案的文件。

此目錄中的檔案可用於調整和監視 Linux 核心操作中的雜項和常規事項。由於某些檔案可能用於破壞您的系統，因此建議在實際進行調整之前閱讀文件和原始碼。

目前，這些檔案可能（取決於您的配置）顯示在 /proc/sys/kernel 中

acct

highwater lowwater frequency

如果啟用了 BSD 樣式的程序記帳，這些值將控制其行為。如果日誌所在的檔案系統上的可用空間低於 lowwater%，則記帳暫停。如果可用空間高於 highwater%，則記帳恢復。frequency 確定我們檢查可用空間量的頻率（值以秒為單位）。預設值

4 2 30

也就是說，如果可用空間降至 2% 以下，則暫停記帳；如果增加到至少 4%，則恢復記帳；將關於可用空間量的資訊視為有效 30 秒。

acpi_video_flags

請參閱 S3 恢復中的影片問題。這允許設定影片恢復模式，方式與 acpi_sleep 核心引數類似，透過組合以下值

1

s3_bios

2

s3_mode

4

s3_beep

arch

機器硬體名稱，與 uname -m 的輸出相同（例如 x86_64 或 aarch64）。

auto_msgmni

此變數無效，可能會在未來的核心版本中刪除。讀取它總是返回 0。直到 Linux 3.17，它才啟用/停用 msgmni 在新增/刪除記憶體或建立/刪除 IPC 名稱空間時的自動重新計算。將“1”回顯到此檔案中啟用 msgmni 自動重新計算。將“0”回顯到此檔案中停用它。預設值為 1。

bootloader_type (僅 x86)

這給出了引導載入程式型別編號，如引導載入程式所示，左移 4 位，並與引導載入程式版本的低四位相或。這樣編碼的原因是，這過去與核心標頭中的 type_of_loader 欄位匹配；保留編碼是為了向後相容。也就是說，如果完整的引導載入程式型別編號為 0x15，並且完整的版本號為 0x234，則此檔案將包含值 340 = 0x154。

有關其他資訊，請參閱 Linux/x86 引導協議 中的 type_of_loader 和 ext_loader_type 欄位。

bootloader_version (僅 x86)

完整的引導載入程式版本號。在上面的示例中，此檔案將包含值 564 = 0x234。

有關其他資訊，請參閱 Linux/x86 引導協議 中的 type_of_loader 和 ext_loader_ver 欄位。

bpf_stats_enabled

控制核心是否應收集有關 BPF 程式的統計資訊（執行總時間、執行次數...）。啟用統計資訊會導致每個程式執行時的效能略有下降。可以使用 bpftool 檢視統計資訊。

0

不收集統計資訊（預設）。

1

收集統計資訊。

cad_pid

這是在重新啟動時將發出訊號的 pid（特別是透過 Ctrl-Alt-Delete）。將不對應於正在執行的程序的值寫入此檔案將導致 -ESRCH。

另請參閱 ctrl-alt-del。

cap_last_cap

正在執行的核心的最高有效能力。從核心匯出 CAP_LAST_CAP。

core_pattern

core_pattern 用於指定核心轉儲模式名稱。

  • 最大長度為 127 個字元；預設值為 “core”

  • core_pattern 用作輸出檔名的模式模板；某些字串模式（以“%”開頭）將替換為其真實值。

  • 與 core_uses_pid 向後相容

    如果 core_pattern 不包含 “%p”（預設不包含）並且設定了 core_uses_pid，則 .PID 將附加到檔名。

  • corename 格式說明符

    %<NUL>

    “%” 被刪除

    %%

    輸出一個 “%”

    %p

    pid

    %P

    全域性 pid（初始化 PID 名稱空間）

    %i

    tid

    %I

    全域性 tid（初始化 PID 名稱空間）

    %u

    uid（在初始使用者名稱空間中）

    %g

    gid（在初始使用者名稱空間中）

    %d

    轉儲模式，匹配 PR_SET_DUMPABLE 和 /proc/sys/fs/suid_dumpable

    %s

    訊號編號

    %t

    轉儲的 UNIX 時間

    %h

    主機名

    %e

    可執行檔名（可能被縮短，可能被 prctl 等更改）

    %f

    可執行檔名

    %E

    可執行路徑

    %c

    核心檔案的最大大小，由資源限制 RLIMIT_CORE 決定

    %C

    任務在其上執行的 CPU

    %<OTHER>

    兩者都被刪除

  • 如果模式的第一個字元是“|”，則核心會將模式的其餘部分視為要執行的命令。核心轉儲將寫入該程式的標準輸入，而不是寫入檔案。

core_pipe_limit

此 sysctl 僅適用於 core_pattern 配置為將核心檔案透過管道傳遞到使用者空間助手時（當 core_pattern 的第一個字元為“|”時，請參見上文）。透過管道將核心收集到應用程式時，有時收集應用程式從其 /proc/pid 目錄收集有關崩潰程序的資料很有用。為了安全地執行此操作，核心必須等待收集程序退出，以免過早地刪除崩潰程序的 proc 檔案。反過來，這會產生行為不當的使用者空間收集程序可能僅透過永不退出來阻止崩潰程序的回收的可能性。此 sysctl 可以防止這種情況。它定義了可以並行透過管道傳遞到使用者空間應用程式的併發崩潰程序的數量。如果超過此值，則透過核心日誌記錄超過該值的崩潰程序，並且跳過其核心。0 是一個特殊值，表示可以並行捕獲無限數量的程序，但不會進行等待（即，不保證收集程序可以訪問 /proc/<crashing pid>/）。此值預設為 0。

core_sort_vma

預設情況下，核心轉儲按地址順序寫入 VMA。透過將 core_sort_vma 設定為 1，VMA 將從最小尺寸寫入到最大尺寸。已知這至少會破壞 elfutils，但在處理包含更多有用除錯細節的較小 VMA 的非常大（且被截斷）的核心轉儲時，這可能很有用。

core_uses_pid

預設的核心轉儲檔名是“core”。透過將 core_uses_pid 設定為 1，核心轉儲檔名變為 core.PID。如果 core_pattern 不包含 “%p”（預設不包含）並且設定了 core_uses_pid，則 .PID 將附加到檔名。

ctrl-alt-del

當此檔案中的值為 0 時，ctrl-alt-del 被捕獲併發送到 init(1) 程式以處理正常重啟。但是，當該值 > 0 時，Linux 對 Vulcan Nerve Pinch (tm) 的反應將是立即重啟，甚至不會同步其髒緩衝區。

注意

當程式（如 dosemu）的鍵盤處於“原始”模式時，ctrl-alt-del 會被程式攔截，然後才到達核心 tty 層，並且由程式決定如何處理它。

dmesg_restrict

此切換指示是否阻止非特權使用者使用 dmesg(8) 檢視來自核心日誌緩衝區的訊息。當 dmesg_restrict 設定為 0 時，沒有限制。當 dmesg_restrict 設定為 1 時，使用者必須具有 CAP_SYSLOG 才能使用 dmesg(8)。

核心配置選項 CONFIG_SECURITY_DMESG_RESTRICT 設定 dmesg_restrict 的預設值。

domainname & hostname

這些檔案可用於設定 NIS/YP 域名和您的計算機的主機名，方式與命令 domainname 和 hostname 完全相同，即：

# echo "darkstar" > /proc/sys/kernel/hostname
# echo "mydomain" > /proc/sys/kernel/domainname

與以下命令具有相同的效果

# hostname "darkstar"
# domainname "mydomain"

但是請注意，經典的 darkstar.frop.org 具有主機名 “darkstar” 和 DNS（Internet 域名伺服器）域名 “frop.org”，不要與 NIS（網路資訊服務）或 YP（黃頁）域名混淆。這兩個域名通常是不同的。有關詳細討論，請參見 hostname(1) 手冊頁。

firmware_config

請參閱 回退機制。

此目錄中的條目允許控制韌體載入程式助手回退

  • force_sysfs_fallback，設定為 1 時，強制使用回退；

  • ignore_sysfs_fallback，設定為 1 時，忽略任何回退。

ftrace_dump_on_oops

確定是否應在 oops（或核心崩潰）上呼叫 ftrace_dump()。這會將 ftrace 緩衝區的內容輸出到控制檯。這對於捕獲導致崩潰的跟蹤並將它們輸出到序列控制檯非常有用。

0

已停用（預設）。

1

轉儲所有 CPU 的緩衝區。

2(orig_cpu)

轉儲觸發 oops 的 CPU 的緩衝區。

<instance>

轉儲所有 CPU 上的特定例項緩衝區。

<instance>=2(orig_cpu)

轉儲觸發 oops 的 CPU 上的特定例項緩衝區。

還支援多個例項轉儲，例項之間用逗號分隔。如果還需要轉儲全域性緩衝區，請首先為全域性緩衝區指定轉儲模式（1/2/orig_cpu）。

因此，例如，要在所有 CPU 上轉儲 “foo” 和 “bar” 例項緩衝區，使用者可以

echo "foo,bar" > /proc/sys/kernel/ftrace_dump_on_oops

要在所有 CPU 上轉儲全域性緩衝區和 “foo” 例項緩衝區，以及在觸發 oops 的 CPU 上轉儲 “bar” 例項緩衝區，使用者可以

echo "1,foo,bar=2" > /proc/sys/kernel/ftrace_dump_on_oops

ftrace_enabled, stack_tracer_enabled

請參閱 ftrace - 函式跟蹤器。

hardlockup_all_cpu_backtrace

此值控制硬鎖死檢測器在檢測到硬鎖死情況時是否收集更多除錯資訊的行為。如果啟用，將啟動特定於架構的所有 CPU 堆疊轉儲。

0

不執行任何操作。這是預設行為。

1

在檢測到後，捕獲更多除錯資訊。

hardlockup_panic

此引數可用於控制在檢測到硬鎖死時核心是否發生 panic。

0

在硬鎖死時不發生 panic。

1

在硬鎖死時發生 panic。

有關更多資訊，請參見 軟鎖死檢測器和硬鎖死檢測器（又名 nmi_watchdog）。也可以使用 nmi_watchdog 核心引數設定此項。

hotplug

熱插拔策略代理的路徑。預設值為 CONFIG_UEVENT_HELPER_PATH，該值又預設為空字串。

僅當啟用 CONFIG_UEVENT_HELPER 時，此檔案才存在。大多數現代系統僅依賴於基於 netlink 的 uevent 源，而不需要此項。

hung_task_all_cpu_backtrace

如果設定了此選項，則在檢測到掛起的任務時，核心將向所有 CPU 傳送 NMI 以轉儲其回溯。如果啟用了 CONFIG_DETECT_HUNG_TASK 和 CONFIG_SMP，則會顯示此檔案。

0：檢測到掛起的任務時，不會顯示所有 CPU 的回溯。這是預設行為。

1：檢測到掛起的任務時，將不可遮蔽地中斷所有 CPU 並轉儲其回溯。

hung_task_panic

控制在檢測到掛起的任務時核心的行為。如果啟用了 CONFIG_DETECT_HUNG_TASK，則會顯示此檔案。

0

繼續操作。這是預設行為。

1

立即發生 panic。

hung_task_check_count

要檢查的任務數的上限。如果啟用了 CONFIG_DETECT_HUNG_TASK，則會顯示此檔案。

hung_task_detect_count

指示自系統啟動以來已檢測為掛起的任務總數。

如果啟用了 CONFIG_DETECT_HUNG_TASK，則會顯示此檔案。

hung_task_timeout_secs

當處於 D 狀態的任務未被排程超過此值時，報告警告。如果啟用了 CONFIG_DETECT_HUNG_TASK，則會顯示此檔案。

0 表示無限超時，不進行檢查。

可以設定的值的範圍為 {0:LONG_MAX/HZ}。

hung_task_check_interval_secs

掛起任務檢查間隔。如果啟用了掛起任務檢查（請參見 hung_task_timeout_secs），則每 hung_task_check_interval_secs 秒執行一次檢查。如果啟用了 CONFIG_DETECT_HUNG_TASK，則會顯示此檔案。

0（預設）表示使用 hung_task_timeout_secs 作為檢查間隔。

可以設定的值的範圍為 {0:LONG_MAX/HZ}。

hung_task_warnings

要報告的最大警告數。在檢查間隔期間，如果檢測到掛起的任務，則此值減 1。當此值達到 0 時，將不再報告警告。如果啟用了 CONFIG_DETECT_HUNG_TASK，則會顯示此檔案。

-1：報告無限數量的警告。

hyperv_record_panic_msg

控制是否應將 panic kmsg 資料報告給 Hyper-V。

0

不報告 panic kmsg 資料。

1

報告 panic kmsg 資料。這是預設行為。

ignore-unaligned-usertrap

在未對齊的訪問導致陷阱的體系結構上，並且在支援此功能的體系結構上（CONFIG_SYSCTL_ARCH_UNALIGN_NO_WARN；目前為 arc、parisc 和 loongarch），控制是否記錄所有未對齊的陷阱。

0

記錄所有未對齊的訪問。

1

僅在程序首次陷入陷阱時發出警告。這是預設設定。

另請參見 unaligned-trap。

io_uring_disabled

阻止所有程序建立新的 io_uring 例項。啟用此功能可縮小核心的攻擊面。

0

所有程序都可以像往常一樣建立 io_uring 例項。這是預設設定。

1

對於不在 io_uring_group 組中的非特權程序，停用 io_uring 建立 (io_uring_setup() 將失敗並顯示 -EPERM)。仍然可以使用現有的 io_uring 例項。有關更多資訊，請參見 io_uring_group 的文件。

2

停用所有程序的 io_uring 建立。io_uring_setup() 始終失敗並顯示 -EPERM。仍然可以使用現有的 io_uring 例項。

io_uring_group

當 io_uring_disabled 設定為 1 時，程序必須具有特權 (CAP_SYS_ADMIN) 或屬於 io_uring_group 組才能建立 io_uring 例項。如果 io_uring_group 設定為 -1（預設值），則只有具有 CAP_SYS_ADMIN 功能的程序才能建立 io_uring 例項。

kexec_load_disabled

一個切換值，指示 syscalls kexec_load 和 kexec_file_load 是否已被停用。此值預設為 0（false：啟用 kexec_*load），但可以設定為 1（true：停用 kexec_*load）。一旦為 true，kexec 將不再可用，並且無法將切換設定回 false。這允許在停用 syscall 之前載入 kexec 映像，從而允許系統設定（並在以後使用）一個映像而不被更改。通常與 modules_disabled sysctl 一起使用。

kexec_load_limit_panic

此引數指定使用崩潰映像呼叫 syscalls kexec_load 和 kexec_file_load 的次數限制。只能將其設定為比當前值更嚴格的值。

-1

對 kexec 的呼叫次數不受限制。這是預設設定。

N

剩餘的呼叫次數。

kexec_load_limit_reboot

與 kexec_load_limit_panic 類似的功能，但用於普通映像。

kptr_restrict

此切換指示是否透過 /proc 和其他介面限制公開核心地址。

當 kptr_restrict 設定為 0（預設值）時，地址在列印之前被雜湊。（這等效於 %p。）

當 kptr_restrict 設定為 1 時，除非使用者具有 CAP_SYSLOG 並且有效使用者 ID 和組 ID 等於實際 ID，否則使用 %pK 格式說明符列印的核心指標將被替換為 0。這是因為 %pK 檢查是在 read() 時而不是 open() 時完成的，因此如果在 open() 和 read() 之間提升了許可權（例如，透過 setuid 二進位制檔案），則 %pK 不會將核心指標洩露給非特權使用者。請注意，這只是一個臨時解決方案。正確的長期解決方案是在 open() 時進行許可權檢查。如果將核心指標值洩露給非特權使用者是一個問題，請考慮從使用 %pK 的檔案中刪除世界讀取許可權，並使用 dmesg_restrict 來防止在 dmesg(8) 中使用 %pK。

當 kptr_restrict 設定為 2 時，無論許可權如何，使用 %pK 列印的核心指標都將被替換為 0。

modprobe

用於自動載入核心模組的 usermode 助手的完整路徑，預設情況下為 CONFIG_MODPROBE_PATH，該路徑又預設為“/sbin/modprobe”。當核心請求模組時，將執行此二進位制檔案。例如，如果使用者空間將未知的 檔案系統型別傳遞給 mount()，則核心將透過執行此 usermode 助手自動請求相應的 檔案系統模組。此 usermode 助手應將所需的模組插入核心中。

此 sysctl 僅影響模組自動載入。它對顯式插入模組的能力沒有影響。

此 sysctl 可用於除錯模組載入請求

echo '#! /bin/sh' > /tmp/modprobe
echo 'echo "$@" >> /tmp/modprobe.log' >> /tmp/modprobe
echo 'exec /sbin/modprobe "$@"' >> /tmp/modprobe
chmod a+x /tmp/modprobe
echo /tmp/modprobe > /proc/sys/kernel/modprobe

或者，如果此 sysctl 設定為空字串，則完全停用模組自動載入。核心根本不會嘗試執行 usermode 助手，也不會呼叫 kernel_module_request LSM 鉤子。

如果在核心配置中設定了 CONFIG_STATIC_USERMODEHELPER=y，則配置的靜態 usermode 助手將覆蓋此 sysctl，但如上所述，空字串仍然被接受以完全停用模組自動載入。

modules_disabled

一個切換值，指示是否允許在其他模組化核心中載入模組。此切換預設為關閉 (0)，但可以設定為 true (1)。一旦為 true，模組既不能載入也不能解除安裝，並且切換無法設定回 false。通常與 kexec_load_disabled 切換一起使用。

msgmax, msgmnb, and msgmni

msgmax 是 IPC 訊息的最大大小（以位元組為單位）。預設為 8192 (MSGMAX)。

msgmnb 是 IPC 佇列的最大大小（以位元組為單位）。預設為 16384 (MSGMNB)。

msgmni 是 IPC 佇列的最大數量。預設為 32000 (MSGMNI)。

所有這些引數都是按 ipc 名稱空間設定的。POSIX 訊息佇列中的最大位元組數受 RLIMIT_MSGQUEUE 限制。此限制在每個使用者名稱空間中按層次結構進行遵守。

msg_next_id, sem_next_id, and shm_next_id (System V IPC)

這三個切換允許為下一個分配的 IPC 物件指定所需的 ID：分別是訊息、訊號量或共享記憶體。

預設情況下，它們等於 -1，這意味著通用分配邏輯。可以設定的值的範圍為 {0:INT_MAX}。

注意

  1. 核心不保證新物件將具有所需的 ID。因此，如何處理具有“錯誤”ID 的物件取決於使用者空間。

  2. 成功分配 IPC 物件後，具有非預設值的切換將被核心設定回 -1。如果 IPC 物件分配 syscall 失敗，則該值是否保持未修改或重置為 -1 是未定義的。

ngroups_max

補充組的最大數量，_i.e._ setgroups 將接受的最大大小。從核心匯出 NGROUPS_MAX。

nmi_watchdog

此引數可用於控制 x86 系統上的 NMI 監視程式（即硬鎖死檢測器）。

0

停用硬鎖死檢測器。

1

啟用硬鎖死檢測器。

硬鎖死檢測器監視每個 CPU 是否能夠響應定時器中斷。該機制利用 CPU 效能計數器暫存器，這些暫存器被程式設計為在 CPU 繁忙時定期生成非遮蔽中斷 (NMI)。因此，替代名稱為“NMI 監視程式”。

如果核心作為 KVM 虛擬機器中的訪客執行，則預設情況下停用 NMI 監視程式。可以透過新增以下內容來覆蓋此預設值

nmi_watchdog=1

到訪客核心命令列（請參見 核心的命令列引數）。

nmi_wd_lpm_factor (PPC only)

應用於 NMI 監視程式超時的因子（僅當 nmi_watchdog 設定為 1 時）。此因子表示在 LPM 期間計算 NMI 監視程式超時時新增到 watchdog_thresh 的百分比。軟鎖死超時不受影響。

值為 0 表示沒有變化。預設值為 200，表示 NMI 監視程式設定為 30 秒（基於等於 10 的 watchdog_thresh）。

numa_balancing

啟用/停用並配置基於自動頁面錯誤的 NUMA 記憶體平衡。記憶體會自動移動到經常訪問它的節點。要設定的值可以是 ORing 以下各項的結果

0

NUMA_BALANCING_DISABLED

1

NUMA_BALANCING_NORMAL

2

NUMA_BALANCING_MEMORY_TIERING

或 NUMA_BALANCING_NORMAL 以最佳化不同 NUMA 節點之間的頁面放置，以減少遠端訪問。在 NUMA 計算機上，如果 CPU 訪問遠端記憶體，則會產生效能損失。啟用此功能後，核心會透過定期取消對映頁面並在以後陷入頁面錯誤來取樣任務執行緒正在訪問的記憶體。在發生頁面錯誤時，將確定是否應將正在訪問的資料遷移到本地記憶體節點。

頁面的取消對映和陷入錯誤會產生額外的開銷，理想情況下可以透過改進的記憶體區域性性來抵消，但沒有通用的保證。如果目標工作負載已繫結到 NUMA 節點，則應停用此功能。

或 NUMA_BALANCING_MEMORY_TIERING 以最佳化不同型別記憶體（表示為不同的 NUMA 節點）之間的頁面放置，以便將熱頁面放置在快速記憶體中。這也是基於取消對映和頁面錯誤實現的。

numa_balancing_promote_rate_limit_MBps

不同記憶體型別之間過高的提升/降級吞吐量可能會損害應用程式延遲。這可用於限制提升吞吐量。每個節點的最大提升吞吐量（以 MB/秒為單位）將被限制為不超過設定的值。

一個經驗法則是將其設定為小於 PMEM 節點寫入頻寬的 1/10。

oops_all_cpu_backtrace

如果設定了此選項，則當發生 oops 事件時，核心將向所有 CPU 傳送 NMI 以轉儲其回溯。如果無法觸發 panic（例如，為了保護正在執行的 VM）或者無法收集 kdump，則應將其用作最後的手段。如果啟用了 CONFIG_SMP，則會顯示此檔案。

0：檢測到 oops 時，不會顯示所有 CPU 的回溯。這是預設行為。

1：檢測到 oops 事件時，將不可遮蔽地中斷所有 CPU 並轉儲其回溯。

oops_limit

在未設定 panic_on_oops 時，核心在發生多少次核心 oops 後應發生 panic。將其設定為 0 會停用檢查計數。將其設定為 1 的效果與設定 panic_on_oops=1 相同。預設值為 10000。

osrelease, ostype & version

# cat osrelease
2.1.88
# cat ostype
Linux
# cat version
#5 Wed Feb 25 21:49:24 MET 1998

檔案 osrelease 和 ostype 應該足夠清楚。version 需要更多的說明。 “#5”表示這是從該原始碼庫構建的第五個核心，其後面的日期表示核心構建的時間。調整這些值的唯一方法是重建核心 :-)

overflowgid & overflowuid

如果您的體系結構並非始終支援 32 位 UID（即 arm、i386、m68k、sh 和 sparc32），則如果實際 UID 或 GID 將超過 65535，則將向使用舊 16 位 UID/GID 系統呼叫的應用程式返回固定的 UID 和 GID。

這些 sysctl 允許您更改固定 UID 和 GID 的值。預設值為 65534。

panic

此檔案中的值確定了核心在發生 panic 時的行為

  • 如果為零，核心將永遠迴圈；

  • 如果為負數，核心將立即重新啟動；

  • 如果為正數，核心將在相應秒數後重新啟動。

當您使用軟體監視程式時，建議的設定為 60。

panic_on_io_nmi

控制 CPU 收到由 IO 錯誤引起的 NMI 時核心的行為。

0

嘗試繼續操作（預設）。

1

立即發生 panic。IO 錯誤觸發了 NMI。這表明存在嚴重的系統狀況，可能會導致 IO 資料損壞。與其繼續，panic 可能是更好的選擇。某些伺服器在按下轉儲按鈕時會發出這種 NMI，您可以使用此選項來獲取崩潰轉儲。

panic_on_oops

控制在遇到 oops 或 BUG 時核心的行為。

0

嘗試繼續操作。

1

立即發生 panic。如果 panic sysctl 也為非零，則機器將重新啟動。

panic_on_stackoverflow

控制在檢測到核心、IRQ 和異常堆疊（使用者堆疊除外）溢位時核心的行為。如果啟用了 CONFIG_DEBUG_STACKOVERFLOW，則會顯示此檔案。

0

嘗試繼續操作。

1

立即發生 panic。

panic_on_unrecovered_nmi

在記憶體或未知 NMI 上，預設的 Linux 行為是繼續操作。對於許多環境（例如科學計算），最好將該框取出並處理錯誤，而不是傳播未更正的奇偶校驗/ECC 錯誤。

少數系統確實會由於奇怪的隨機原因（例如電源管理）而生成 NMI，因此預設值為關閉。該 sysctl 的工作方式與該目錄中已有的現有 panic 控制類似。

panic_on_warn

當設定為 1 時，在 WARN() 路徑中呼叫 panic()。這有助於避免在嘗試在 WARN() 的位置進行 kdump 時重建核心。

0

僅 WARN()，預設行為。

1

列印 WARN() 位置後，呼叫 panic()。

panic_print

在發生 panic 時列印系統資訊的位掩碼。使用者可以選擇以下位的組合

位 0

列印所有任務資訊

位 1

列印系統記憶體資訊

位 2

列印計時器資訊

位 3

如果啟用了 CONFIG_LOCKDEP，則列印鎖資訊

位 4

列印 ftrace 緩衝區

位 5

列印緩衝區中的所有 printk 訊息

位 6

列印所有 CPU 回溯（如果架構中可用）

位 7

僅列印處於不可中斷（阻塞）狀態的任務

因此，例如，要在發生 panic 時列印任務和記憶體資訊，使用者可以

echo 3 > /proc/sys/kernel/panic_print

panic_on_rcu_stall

當設定為 1 時，在 RCU 停頓檢測訊息之後呼叫 panic()。這對於使用 vmcore 定義 RCU 停頓的根本原因很有用。

0

當發生 RCU 停頓時，不要 panic()，這是預設行為。

1

在列印 RCU 停頓訊息後 panic()。

max_rcu_stall_to_panic

當 panic_on_rcu_stall 設定為 1 時，此值確定 RCU 在呼叫 panic() 之前可以停頓的次數。

當 panic_on_rcu_stall 設定為 0 時，此值無效。

perf_cpu_time_max_percent

向核心提示允許使用多少 CPU 時間來處理 perf 取樣事件。如果 perf 子系統被告知其樣本超過此限制，它將降低其取樣頻率以嘗試減少其 CPU 使用率。

一些 perf 取樣發生在 NMI 中。如果這些樣本出乎意料地花費太長時間執行，則 NMI 可能會彼此堆疊，以至於不允許執行任何其他操作。

0

停用該機制。無論佔用多少 CPU 時間，都不要監視或更正 perf 的取樣率。

1-100

嘗試將 perf 的取樣率限制為此 CPU 百分比。注意：核心計算每個取樣事件的“預期”長度。這裡的 100 表示預期長度的 100%。即使將其設定為 100，如果超過此長度，您仍然可能會看到取樣限制。如果您真的不在乎消耗多少 CPU，請設定為 0。

perf_event_paranoid

控制非特權使用者（沒有 CAP_PERFMON）對效能事件系統的使用。預設值為 2。

出於向後相容的原因，對系統性能監控和可觀察性的訪問仍然對 CAP_SYS_ADMIN 特權程序開放，但不鼓勵將 CAP_SYS_ADMIN 用於安全系統效能監控和可觀察性操作，而應使用 CAP_PERFMON 用例。

-1

允許所有使用者使用（幾乎）所有事件。

在 perf_event_mlock_kb 之後忽略 mlock 限制，無需 CAP_IPC_LOCK。

>=0

禁止沒有 CAP_PERFMON 的使用者使用 ftrace 函式跟蹤點。

禁止沒有 CAP_PERFMON 的使用者訪問原始跟蹤點。

>=1

禁止沒有 CAP_PERFMON 的使用者訪問 CPU 事件。

>=2

禁止沒有 CAP_PERFMON 的使用者進行核心分析。

perf_event_max_stack

控制為（attr.sample_type & PERF_SAMPLE_CALLCHAIN）配置的事件複製的最大堆疊幀數，例如，當使用 'perf record -g' 或 'perf trace --call-graph fp'。

只有在沒有啟用呼叫鏈的事件在使用時才能執行此操作，否則寫入此檔案將返回 -EBUSY。

預設值為 127。

perf_event_mlock_kb

控制每個 CPU 環形緩衝區的大小，該緩衝區不計入 mlock 限制。

預設值為 512 + 1 頁

perf_event_max_contexts_per_stack

控制為（attr.sample_type & PERF_SAMPLE_CALLCHAIN）配置的事件的最大堆疊幀上下文條目數，例如，當使用 'perf record -g' 或 'perf trace --call-graph fp'。

只有在沒有啟用呼叫鏈的事件在使用時才能執行此操作，否則寫入此檔案將返回 -EBUSY。

預設值為 8。

perf_user_access (僅限 arm64 和 riscv)

控制使用者空間訪問以讀取 perf 事件計數器。

arm64

預設值為 0（停用訪問）。

設定為 1 時，使用者空間可以直接讀取效能監視器計數器暫存器。

有關更多資訊，請參見 Perf。

riscv

設定為 0 時，停用使用者空間訪問。

預設值為 1，使用者空間可以透過 perf 讀取效能監視器計數器暫存器，任何沒有 perf 干預的直接訪問都將觸發非法指令。

設定為 2 時，啟用傳統模式（使用者空間只能直接訪問 cycle 和 insret CSR）。請注意，此傳統值已棄用，一旦所有使用者空間應用程式都修復後將被刪除。

請注意，時間 CSR 始終可以直接訪問所有模式。

pid_max

PID 分配環繞值。當核心的下一個 PID 值達到此值時，它會環繞回最小 PID 值。不分配值大於或等於 pid_max 的 PID。

ns_last_pid

在當前（使用此 sysctl 的任務所在的）pid 名稱空間中分配的最後一個 pid。在為 fork 上的下一個任務選擇 pid 時，核心嘗試從該數字開始分配。

powersave-nap (僅限 PPC)

如果設定，Linux-PPC 將使用省電的“nap”模式，否則將使用“doze”模式。

printk

printk 中的四個值表示：console_loglevel、default_message_loglevel、minimum_console_loglevel 和 default_console_loglevel。

這些值在列印或記錄錯誤訊息時會影響 printk() 的行為。有關不同日誌級別的更多資訊，請參見 'man 2 syslog'。

console_loglevel

優先順序高於此值的訊息將被列印到控制檯

default_message_loglevel

沒有明確優先順序的訊息將以該優先順序列印

minimum_console_loglevel

可以設定 console_loglevel 的最小值（最高值）

default_console_loglevel

console_loglevel 的預設值

printk_delay

以 printk_delay 毫秒為單位延遲每個 printk 訊息

允許的值為 0 - 10000。

printk_ratelimit

一些警告訊息受到速率限制。printk_ratelimit 指定這些訊息之間的最短時間（以秒為單位）。預設值為 5 秒。

值為 0 將停用速率限制。

printk_ratelimit_burst

雖然從長遠來看，我們強制每 printk_ratelimit 秒一條訊息，但我們允許一批訊息透過。printk_ratelimit_burst 指定在速率限制啟動之前我們可以傳送的訊息數。

預設值為 10 條訊息。

printk_devkmsg

控制從使用者空間到 /dev/kmsg 的日誌記錄

ratelimit

預設，速率限制

on

從使用者空間到 /dev/kmsg 的無限日誌記錄

off

停用到 /dev/kmsg 的日誌記錄

核心命令列引數 printk.devkmsg= 覆蓋此設定，並且是一次性設定，直到下次重新啟動：一旦設定，就無法再透過此 sysctl 介面更改它。

pty

參見 Devpts 檔案系統。

random

這是一個目錄，包含以下條目

  • boot_id：首次檢索時生成的 UUID，此後保持不變；

  • uuid：每次檢索時生成的 UUID（因此可用於隨意生成 UUID）；

  • entropy_avail：池的熵計數，以位為單位；

  • poolsize：熵池大小，以位為單位；

  • urandom_min_reseed_secs：已過時（用於確定 urandom 池重新播種之間的最小秒數）。此檔案是可寫的，出於相容性目的，但寫入它對任何 RNG 行為都沒有影響；

  • write_wakeup_threshold：當熵計數降至此值以下時（以位數計），等待寫入 /dev/random 的程序將被喚醒。此檔案是可寫的，出於相容性目的，但寫入它對任何 RNG 行為都沒有影響。

randomize_va_space

此選項可用於選擇系統中使用的程序地址空間隨機化的型別，適用於支援此功能的體系結構。

0

關閉程序地址空間隨機化。對於無論如何都不支援此功能的體系結構以及使用“norandmaps”引數引導的核心，這是預設設定。

1

使 mmap 基址、堆疊和 VDSO 頁面的地址隨機化。除其他事項外，這意味著共享庫將被載入到隨機地址。此外，對於 PIE 連結的二進位制檔案，程式碼開始的位置是隨機的。如果啟用了 CONFIG_COMPAT_BRK 選項，這是預設設定。

2

此外，啟用堆隨機化。如果停用了 CONFIG_COMPAT_BRK，這是預設設定。

有一些舊的應用程式（例如 1996 年的一些舊版本的 libc.so.5）假定 brk 區域緊接在 code+bss 之後開始。當 brk 區域的開始是隨機的時，這些應用程式會中斷。但是，沒有已知的非舊應用程式會以這種方式中斷，因此對於大多數系統，選擇完全隨機化是安全的。

具有舊的和/或損壞的二進位制檔案的系統應配置為啟用 CONFIG_COMPAT_BRK，這會將堆排除在程序地址空間隨機化之外。

real-root-dev

參見 使用初始 RAM 磁碟 (initrd)。

reboot-cmd (僅限 SPARC)

??? 這似乎是一種向 Sparc ROM/Flash 引導載入程式提供引數的方法。也許是告訴它重新啟動後該怎麼做。 ???

sched_energy_aware

啟用/停用能量感知排程 (EAS)。EAS 在可以執行的平臺上自動啟動（即，具有不對稱 CPU 拓撲並具有可用能量模型的平臺）。如果您的平臺碰巧滿足 EAS 的要求，但您不想使用它，請將此值更改為 0。在非 EAS 平臺上，寫入操作失敗，讀取不返回任何內容。

task_delayacct

啟用/停用任務延遲記帳（參見 延遲記帳。啟用此功能會在排程程式中產生少量開銷，但對於除錯和效能調整很有用。某些工具（如 iotop）需要它。

sched_schedstats

啟用/停用排程程式統計資訊。啟用此功能會在排程程式中產生少量開銷，但對於除錯和效能調整很有用。

sched_util_clamp_min

允許的最大 *最小* 利用率。

預設值為 1024，這是最大可能值。

這意味著任何請求的 uclamp.min 值都不能大於 sched_util_clamp_min，即，它被限制在 [0:sched_util_clamp_min] 範圍內。

sched_util_clamp_max

允許的最大 *最大* 利用率。

預設值為 1024，這是最大可能值。

這意味著任何請求的 uclamp.max 值都不能大於 sched_util_clamp_max，即，它被限制在 [0:sched_util_clamp_max] 範圍內。

sched_util_clamp_min_rt_default

預設情況下，Linux 針對性能進行了調整。這意味著 RT 任務始終以最高頻率和最強大的（最高容量）CPU 執行（在異構系統中）。

Uclamp 透過預設將所有 RT 任務的請求 uclamp.min 設定為 1024 來實現這一點，這有效地提升了任務以最高頻率執行，並將它們偏向於在最大的 CPU 上執行。

此旋鈕允許管理員在使用 uclamp 時更改預設行為。特別是在電池供電裝置中，以最大容量和頻率執行會增加能耗並縮短電池壽命。

此旋鈕僅對使用者尚未透過 sched_setattr() 系統呼叫修改其請求的 uclamp.min 值的 RT 任務有效。

此旋鈕不會超出 sched_util_clamp_min 施加的範圍約束（如上所述）。

例如，如果

sched_util_clamp_min_rt_default = 800 sched_util_clamp_min = 600

那麼提升將被限制為 600，因為 800 超出了 [0:600] 的允許範圍。例如，如果省電模式將透過修改 sched_util_clamp_min 暫時限制所有提升，則可能會發生這種情況。一旦取消此限制，請求的 sched_util_clamp_min_rt_default 將生效。

seccomp

參見 Seccomp BPF（帶過濾器的安全計算）。

sg-big-buff

此檔案顯示通用 SCSI (sg) 緩衝區的大小。您還不能對其進行調整，但您可以透過編輯 include/scsi/sg.h 並更改 SG_BIG_BUFF 的值，在編譯時對其進行更改。

沒有任何理由更改此值。如果您可以提出一個理由，您可能無論如何都知道自己在做什麼：)

shmall

此引數設定可在 ipc 名稱空間內使用的共享記憶體頁面的總數。共享記憶體頁面的計數分別針對每個 ipc 名稱空間進行，並且不繼承。因此，shmall 應該始終至少為 ceil(shmmax/PAGE_SIZE)。

如果您不確定 Linux 系統上的預設 PAGE_SIZE 是多少，則可以執行以下命令

# getconf PAGE_SIZE

要減少或停用分配共享記憶體的能力，您必須建立一個新的 ipc 名稱空間，將此引數設定為所需的值，並禁止在當前使用者名稱空間或 cgroup 中建立新的 ipc 名稱空間。

shmmax

此值可用於查詢和設定可以建立的最大共享記憶體段大小的執行時限制。核心現在支援最大 1Gb 的共享記憶體段。此值的預設值為 SHMMAX。

shmmni

此值確定共享記憶體段的最大數量。預設為 4096 (SHMMNI)。

shm_rmid_forced

Linux 允許您設定資源限制，包括一個程序可以透過 setrlimit(2) 消耗多少記憶體。不幸的是，允許共享記憶體段存在而不與任何程序關聯，因此可能不會計入任何資源限制。如果啟用，共享記憶體段會在分離或程序終止後其附加計數變為零時自動銷燬。它還將銷燬已建立但從未附加到程序的段，並在程序退出時銷燬。 IPC_RMID 留下的唯一用途是立即銷燬一個未附加的段。當然，這會破壞事物的定義方式，因此某些應用程式可能會停止工作。請注意，除非您還配置了資源限制（特別是 RLIMIT_AS 和 RLIMIT_NPROC），否則此功能對您沒有任何好處。大多數系統不需要此功能。

請注意，如果您將此值從 0 更改為 1，則已經建立的沒有使用者且具有已終止的原始程序的段將被銷燬。

sysctl_writes_strict

控制檔案位置如何影響透過 /proc/sys 介面更新 sysctl 值的行為

-1

傳統的每次寫入 sysctl 值處理，沒有 printk 警告。每個寫入系統呼叫必須完全包含要寫入的 sysctl 值，並且對同一 sysctl 檔案描述符的多次寫入將重寫 sysctl 值，而與檔案位置無關。

0

與上述行為相同，但當檔案位置不是 0 時，會警告對 sysctl 檔案描述符執行寫入的程序。

1

（預設）在寫入 sysctl 字串時，尊重檔案位置。多次寫入將附加到 sysctl 值緩衝區。超過 sysctl 值緩衝區的最大長度的任何內容都將被忽略。對數字 sysctl 條目的寫入必須始終位於檔案位置 0，並且該值必須完全包含在寫入系統呼叫中傳送的緩衝區中。

softlockup_all_cpu_backtrace

此值控制軟體鎖死檢測器執行緒在檢測到軟體鎖死情況時是否收集更多除錯資訊的行為。如果啟用，則將向每個 cpu 發出 NMI，並指示其捕獲堆疊跟蹤。

此功能僅適用於支援 NMI 的體系結構。

0

不執行任何操作。這是預設行為。

1

在檢測到後，捕獲更多除錯資訊。

softlockup_panic

此引數可用於控制核心在檢測到軟體鎖死時是否 panic。

0

在軟體鎖死時不 panic。

1

在軟體鎖死時 panic。

也可以使用 softlockup_panic 核心引數設定此選項。

soft_watchdog

此引數可用於控制軟體鎖死檢測器。

0

停用軟體鎖死檢測器。

1

啟用軟體鎖死檢測器。

軟體鎖死檢測器監視 CPU，以查詢佔用 CPU 而不自願重新排程的執行緒，從而阻止“migration/N”執行緒執行，導致看門狗工作無法執行。該機制取決於 CPU 響應計時器中斷的能力，計時器中斷是看門狗計時器函式將看門狗工作排隊所必需的，否則 NMI 看門狗（如果啟用）可以檢測到硬體鎖死情況。

split_lock_mitigate (僅限 x86)

在 x86 上，每個“分割鎖”都會給整個系統帶來效能損失。在較大的系統中，來自非特權使用者的大量分割鎖可能會導致對行為良好且可能更重要的使用者的拒絕服務。

核心透過檢測分割鎖並施加懲罰來緩解這些不良使用者：強制他們等待，並且一次只允許一個核心執行分割鎖。

這些緩解措施可能會使那些糟糕的應用程式變得難以忍受的慢。設定 split_lock_mitigate=0 可能會恢復一些應用程式的效能，但也會增加系統受到來自 split lock 使用者的拒絕服務攻擊的風險。

0

停用緩解模式 - 僅在核心日誌中警告 split lock，並將系統暴露於來自 split lock 使用者的拒絕服務攻擊。

1

啟用緩解模式（這是預設設定） - 透過有意的效能下降來懲罰 split lock 使用者。

stack_erasing

此引數可用於控制在使用 CONFIG_GCC_PLUGIN_STACKLEAK 構建的核心中，系統呼叫結束時的核心棧擦除。

該擦除減少了核心棧洩漏錯誤可能洩露的資訊，並阻止了一些未初始化的棧變數攻擊。權衡之處在於效能影響：在單 CPU 系統上，核心編譯速度會減慢 1%，其他系統和工作負載可能會有所不同。

0

核心棧擦除已停用，STACKLEAK_METRICS 不會更新。

1

核心棧擦除已啟用（預設），它在系統呼叫結束時返回到使用者空間之前執行。

stop-a (僅限 SPARC)

控制 Stop-A

0

Stop-A 無效。

1

Stop-A 中斷到 PROM（預設）。

Stop-A 在 panic 時始終啟用，以便使用者可以返回到啟動 PROM。

sysrq

請參閱 Linux Magic System Request Key Hacks (Linux 魔術系統請求鍵技巧)。

tainted

如果核心已被汙染，則為非零值。數值可以進行 OR 運算。這些字母在 Oops 報告的“Tainted”行中可見。

1

(P)

載入了專有模組

2

(F)

模組被強制載入

4

(S)

核心在超出規格的系統上執行

8

(R)

模組被強制解除安裝

16

(M)

處理器報告了機器檢查異常 (MCE)

32

(B)

引用了錯誤的頁面或某些意外的頁面標誌

64

(U)

使用者空間應用程式請求的汙染

128

(D)

核心最近崩潰，即發生了 OOPS 或 BUG

256

(A)

ACPI 表被使用者覆蓋

512

(W)

核心發出警告

1024

(C)

載入了 staging 驅動程式

2048

(I)

應用了平臺韌體中的錯誤解決方法

4096

(O)

載入了外部構建的（“樹外”）模組

8192

(E)

載入了未簽名的模組

16384

(L)

發生了軟鎖死

32768

(K)

核心已被即時修補

65536

(X)

輔助汙染，由發行版定義和使用

131072

(T)

核心是使用 struct randomization 外掛構建的

有關更多資訊，請參閱 受汙染的核心。

注意

如果核心使用命令列選項 panic_on_taint=<bitmask>,nousertaint 啟動，並且寫入 tainted 的任何 OR 運算後的值與 panic_on_taint 上宣告的位掩碼匹配，則對此 sysctl 介面的寫入將失敗並顯示 EINVAL。 有關該特定核心命令列選項及其可選的 nousertaint 開關的更多詳細資訊，請參閱 核心的命令列引數。

threads-max

此值控制可以使用 fork() 建立的最大執行緒數。

在初始化期間，核心設定此值，即使建立了最大數量的執行緒，執行緒結構也僅佔用可用 RAM 頁面的 一部分 (1/8)。

可以寫入 threads-max 的最小值是 1。

可以寫入 threads-max 的最大值由常量 FUTEX_TID_MASK (0x3fffffff) 給出。

如果寫入 threads-max 的值超出此範圍，則會發生 EINVAL 錯誤。

timer_migration

當設定為非零值時，嘗試將計時器從空閒 CPU 遷移出去，以允許它們在低功耗狀態下停留更長時間。

預設設定為 (1)。

traceoff_on_warning

設定後，當命中 WARN() 時，停用跟蹤（請參閱 ftrace - 函式跟蹤器）。

tracepoint_printk

當跟蹤點被髮送到 printk()（由 tp_printk 引導引數啟用）時，此條目提供執行時控制

echo 0 > /proc/sys/kernel/tracepoint_printk

將停止將跟蹤點發送到 printk()，並且

echo 1 > /proc/sys/kernel/tracepoint_printk

將再次將它們傳送到 printk()。

這僅在核心以啟用 tp_printk 啟動時才有效。

請參閱 核心的命令列引數 和 啟動時跟蹤。

unaligned-trap

在未對齊訪問導致陷阱的架構上，並且支援此功能（CONFIG_SYSCTL_ARCH_UNALIGN_ALLOW；目前，arc、parisc 和 loongarch），控制是否捕獲並模擬未對齊陷阱（而不是失敗）。

0

不模擬未對齊的訪問。

1

模擬未對齊的訪問。 這是預設設定。

另請參閱 ignore-unaligned-usertrap。

unknown_nmi_panic

此檔案中的值會影響處理 NMI 的行為。 當該值為非零時，未知 NMI 會被捕獲，然後發生 panic。 此時，核心除錯資訊會顯示在控制檯上。

大多數 IA32 伺服器都有的 NMI 開關會觸發未知的 NMI。 如果系統掛起，請嘗試按下 NMI 開關。

unprivileged_bpf_disabled

將 1 寫入此條目將停用對 bpf() 的非特權呼叫； 停用後，在沒有 CAP_SYS_ADMIN 或 CAP_BPF 的情況下呼叫 bpf() 將返回 -EPERM。 一旦設定為 1，就無法再從正在執行的核心中清除它。

將 2 寫入此條目也會停用對 bpf() 的非特權呼叫，但是，如果需要，管理員仍然可以透過將 0 或 1 寫入此條目來稍後更改此設定。

如果核心配置中啟用了 BPF_UNPRIV_DEFAULT_OFF，則此條目將預設設定為 2 而不是 0。

0

已啟用對 bpf() 的非特權呼叫

1

已停用對 bpf() 的非特權呼叫，無法恢復

2

已停用對 bpf() 的非特權呼叫

warn_limit

當未設定 panic_on_warn 時，核心應在多少次核心警告後 panic。 將此值設定為 0 會停用檢查警告計數。 將此值設定為 1 與設定 panic_on_warn=1 具有相同的效果。 預設值為 0。

watchdog

此引數可用於同時停用或啟用軟鎖死檢測器和 NMI 監視程式（即硬鎖死檢測器）。

0

停用兩個鎖死檢測器。

1

啟用兩個鎖死檢測器。

也可以使用 soft_watchdog 和 nmi_watchdog 引數單獨停用或啟用軟鎖死檢測器和 NMI 監視程式。 如果讀取了 watchdog 引數，例如透過執行

cat /proc/sys/kernel/watchdog

此命令的輸出（0 或 1）顯示 soft_watchdog 和 nmi_watchdog 的邏輯 OR。

watchdog_cpumask

此值可用於控制監視程式可以在哪些 CPU 上執行。 預設 cpumask 是所有可能的核心，但是如果在核心配置中啟用了 NO_HZ_FULL，並且使用 nohz_full= 引導引數指定了核心，則預設情況下會排除這些核心。 離線核心可以包含在此掩碼中，如果該核心稍後上線，則將根據掩碼值啟動監視程式。

通常，只有在 nohz_full 情況下才會接觸此值，以重新啟用預設情況下未執行監視程式的核心，如果在這些核心上懷疑核心鎖死。

引數值是 cpumask 的標準 cpulist 格式，因此例如要在核心 0、2、3 和 4 上啟用監視程式，您可以說

echo 0,2-4 > /proc/sys/kernel/watchdog_cpumask

watchdog_thresh

此值可用於控制 hrtimer 和 NMI 事件的頻率以及軟鎖死和硬鎖死閾值。 預設閾值為 10 秒。

softlockup 閾值是 (2 * watchdog_thresh)。 將此可調引數設定為零將完全停用鎖死檢測。