OSC 3008 是什麼：systemd 終端上下文信令和亂碼排障

OSC 3008，全名是 Hierarchical Context Signalling，是 UAPI Group 規範中的 UAPI.15。它定義了一組新的終端控制序列，讓程式可以把目前終端裡的「上下文層級」告訴終端模擬器。

簡單說，它想解決的是一個現代 Linux 終端裡越來越常見的問題：你到底在哪一層？

比如你可能從本機 SSH 到伺服器，再進入容器，隨後用 run0 或類似工具提權執行命令。對使用者來說，這是一個連續的終端視窗；但對終端模擬器來說，如果沒有額外信號，它很難準確知道目前輸出來自本機、遠端、容器，還是提權後的命令。

OSC 3008 就是為這類場景設計的。UAPI 官方規範說明，它允許終端模擬器追蹤螢幕上目前內容的上下文層級。systemd 也已經提供了對應實作，腳本名通常是 80-systemd-osc-context.sh。

官方規範：

• UAPI.15 OSC 3008: Hierarchical Context Signalling：https://uapi-group.org/specifications/specs/osc_context/
• systemd 80-systemd-osc-context.sh：https://github.com/systemd/systemd/blob/main/profile.d/80-systemd-osc-context.sh

為什麼需要 OSC 3008

傳統終端只負責顯示程式輸出，最多透過標題、顏色、提示字元來輔助區分環境。問題是，現代終端會話經常是多層嵌套的：

1

本機 shell -> SSH 遠端伺服器 -> Docker/Podman/systemd-nspawn 容器 -> run0 提權命令

如果只靠 PS1 提示字元，很容易遇到幾個問題：

1. 提示字元只能表示目前 shell，很難完整表達嵌套層級。
2. 不同 shell、不同發行版、不同使用者配置會互相覆蓋。
3. 終端模擬器無法可靠知道哪些輸出屬於哪個上下文。
4. 某些控制序列在不相容終端裡會直接變成亂碼。

OSC 3008 提供了一種更結構化的方式：由實際進入上下文的程式送出 start 序列，由退出上下文的程式送出 end 序列。終端模擬器解析後，就能知道目前輸出屬於哪個上下文節點。

它傳遞哪些資訊

OSC 3008 本質上是一組 OSC 轉義序列。規範裡定義了兩類核心命令：

1
2

OSC "3008;start=..." ST
OSC "3008;end=..." ST

start 表示一個上下文開始、更新或重新成為目前上下文；end 表示一個上下文結束。

每個上下文可以帶一些元資料欄位。常見欄位包括：

1. type=：上下文類型，例如 shell、command、remote、container、vm、elevate。
2. user=：送出序列的 UNIX 使用者名稱。
3. hostname=：主機名稱。
4. machineid=：來自 /etc/machine-id 的機器 ID。
5. bootid=：來自 /proc/sys/kernel/random/boot_id 的啟動 ID。
6. pid=：送出序列的程序 PID。
7. comm=：程序名稱。
8. cwd=：目前工作目錄，主要用於 shell 或 command。
9. cmdline=：被互動式呼叫的命令列。
10. container=、vm=：容器或虛擬機名稱。
11. targetuser=、targethost=：目標使用者或遠端目標主機。

這些欄位不是為了給使用者直接看，而是給終端模擬器解析。支援得好的終端會「吃掉」這些控制序列，並用它們改善介面體驗。

能帶來什麼好處

如果終端模擬器支援 OSC 3008，它可以做不少更聰明的事情。

第一，標記不同上下文的輸出。比如容器內輸出、提權命令輸出、遠端 SSH 輸出，可以有不同的背景、邊框或提示。

第二，顯示層級麵包屑。終端可以知道目前大致處於：

1

本機 -> 遠端主機 -> 容器 -> root 命令

這比單靠視窗標題或 PS1 更穩定。

第三，輔助視窗標題、標籤頁和右鍵選單。終端可以根據目前上下文更新標籤頁標題，也可以在某段輸出上提供「在同一目錄打開 shell」之類操作。

第四，減少誤操作。比如目前已經進入生產環境容器並切到 root，終端可以做更醒目的提示，降低在錯誤環境執行危險命令的機率。

systemd 是怎麼接入的

systemd 的實作主要在 80-systemd-osc-context.sh 裡。這個腳本會透過 profile 機制載入，並在 Bash 互動環境裡設定相關函數和提示字元鉤子。

常見路徑可能是：

1
2

/etc/profile.d/80-systemd-osc-context.sh
/usr/lib/systemd/profile.d/80-systemd-osc-context.sh

不同發行版的實際位置可能不同。systemd 原始碼中的註解說明，這個檔案會透過 systemd-tmpfiles 啟用，把它連結到 /etc/profile.d/。

在 Bash 裡，它會使用類似這些函數名：

1
2
3

__systemd_osc_context_escape
__systemd_osc_context_common
__systemd_osc_context_precmdline

同時還會影響 PROMPT_COMMAND 和 PS0。其中 PS0 會在 Bash 讀取命令後、執行命令前展開，這也是為什麼有些不相容終端會在每次執行命令前看到一串很長的 3008;start=... 文字。

為什麼有些終端會顯示亂碼

正常情況下，終端模擬器應該把 OSC 3008 當作控制序列解析掉，不直接顯示。

但如果終端不認識 OSC 3008，或者中間層把控制字元過濾、轉義、打散了，就可能把原始內容顯示出來。常見場景包括：

1. 舊版終端模擬器。
2. 尚未適配 OSC 3008 的 SSH 客戶端。
3. Web 堡壘機或瀏覽器終端，例如某些 Apache Guacamole 環境。
4. Emacs term.el、串口終端、minicom 等對 OSC 支援有限的環境。
5. 多層轉發後控制序列被中間層破壞。

這時你可能會看到類似下面的內容：

1

]3008;start=...;type=command;cwd=...

或者看到包含 machineid=、bootid=、pid=、comm=、cwd= 的長字串。它們不是普通程式輸出，而是本來應該由終端處理的上下文信號。

怎麼判斷是不是 OSC 3008

可以先看三個線索。

第一，亂碼裡是否有 3008;start= 或 3008;end=。

第二，亂碼是否經常出現在命令執行前後，尤其是每次按 Enter 執行命令時都出現。

第三，目前系統是否載入了 systemd 的 OSC 函數：

1

declare -f __systemd_osc_context_precmdline

如果能看到函數定義，說明目前 shell 裡確實載入了相關邏輯。

還可以檢查 profile 檔案：

1

ls -l /etc/profile.d/80-systemd-osc-context.sh

如果這個路徑存在，並且你的終端正好不支援 OSC 3008，亂碼大機率就來自這裡。

臨時規避辦法

如果只是目前會話看著難受，可以先在 shell 裡把相關函數覆蓋掉，並清空 PS0：

1
2
3
4

__systemd_osc_context_precmdline() { :; }
__systemd_osc_context_common() { :; }
__systemd_osc_context_escape() { :; }
PS0=""

如果想只在 SSH 會話中自動處理，可以放到 ~/.bashrc：

1
2
3
4
5
6
7
8

if [[ -n "$SSH_CLIENT" || -n "$SSH_TTY" || -n "$SSH_CONNECTION" ]]; then
    if declare -f __systemd_osc_context_precmdline >/dev/null; then
        __systemd_osc_context_precmdline() { :; }
        __systemd_osc_context_common() { :; }
        __systemd_osc_context_escape() { :; }
        PS0=""
    fi
fi

這種方式影響範圍比較小，不會動系統級 profile 檔案，也方便隨時刪除。

系統級禁用方法

如果你確認這台機器的終端環境普遍不相容 OSC 3008，可以考慮系統級禁用。但這一步要謹慎，因為它會影響所有使用者和所有登入會話。

systemd 腳本註解裡給出的思路是：移除 /etc/profile.d/80-systemd-osc-context.sh 符號連結，並 mask 對應的 tmpfiles 片段，避免之後被重新建立。

可以參考這樣的命令：

1
2
3

test -h /etc/profile.d/80-systemd-osc-context.sh && \
rm -v /etc/profile.d/80-systemd-osc-context.sh && \
ln -s /dev/null /etc/tmpfiles.d/20-systemd-osc-context.conf

注意，這比只改 ~/.bashrc 更重。建議先用臨時方案確認問題確實由 OSC 3008 引起，再決定是否做系統級禁用。

如果只是個人 SSH 客戶端不相容，不建議直接改系統級配置。優先改自己的 ~/.bashrc，或者在 SSH 客戶端裡設定登入後執行清理命令。

應該升級終端還是禁用 OSC 3008

如果你使用的是現代終端，並且它已經支援 OSC 3008，最好保留這個能力。它未來可能會讓遠端 shell、容器、虛擬機和提權命令的上下文展示更清楚。

如果你的實際環境是堡壘機、串口、老舊終端或 Web SSH，而且短期內沒法升級客戶端，那麼遮蔽它更實際。畢竟對大多數維運場景來說，乾淨可讀的終端輸出比上下文增強更重要。

可以按這個順序處理：

1. 能升級終端模擬器，就先升級。
2. 不能升級，但只影響自己，就在 ~/.bashrc 或客戶端登入後命令裡遮蔽。
3. 全機器都受影響，再考慮移除 /etc/profile.d/80-systemd-osc-context.sh 連結並 mask tmpfiles 片段。

簡短結論

OSC 3008 不是病毒，也不是普通程式亂輸出。它是 UAPI.15 定義的終端上下文信令，目標是讓終端理解 shell、SSH、容器、虛擬機、提權命令之間的層級關係。

真正的問題通常出在相容性：支援它的終端會自動解析，不支援的終端就可能把控制序列當成亂碼顯示。

如果你看到 3008;start=、machineid=、bootid=、cwd= 之類內容，先判斷是否由 systemd 的 80-systemd-osc-context.sh 注入。確認後，再按影響範圍選擇臨時遮蔽、個人 .bashrc 遮蔽，或系統級禁用。