Ubuntu 使用者常遇到「偵測到系統程式問題」彈窗，雖不影響系統運行，但頻繁干擾體驗。本文深入剖析 Apport 錯誤回報機制，提供從「清理歷史報告」到「徹底停用」的分級解決方案。

一、錯誤彈窗來源：Apport 機制

• Apport：Ubuntu 內建崩潰報告收集器，偵測到程式崩潰（Segmentation fault、未處理例外等）時自動觸發
• 報告儲存於 /var/crash/ 目錄，副檔名 .crash
• 彈窗目的：引導使用者上傳至 Launchpad 協助開發者修復 Bug

二、分級解決方案

方案一：一次性清理歷史報告（推薦首試）

sudo rm /var/crash/*
# 或僅清理特定使用者
sudo rm /var/crash/*$(whoami)*

• 優點：保留 Apport 功能，未來新崩潰仍會提醒
• 缺點：新崩潰會再次產生彈窗

方案二：停用 Apport 服務（徹底根治）

# 臨時停用
sudo systemctl stop apport
sudo systemctl disable apport

# 永久停用（修改設定檔）
sudo sed -i 's/enabled=1/enabled=0/' /etc/default/apport
# 或手動編輯
# sudo vim /etc/default/apport
# enabled=0

修改後需重啟服務或重開機生效。

方案三：僅隱藏 GUI 彈窗，保留後端收集

# 修改 apport-gtk 設定
mkdir -p ~/.config/apport
echo "[main]" > ~/.config/apport/settings
echo "show_dialog=false" >> ~/.config/apport/settings

三、進階：分析崩潰報告找出真兇

若願意協助開發者或自行排查，可檢視 /var/crash/ 內容：

# 查看報告摘要
ls -la /var/crash/

# 解析特定報告
cat /var/crash/_usr_bin_gnome-shell.1000.crash | head -50

# 關鍵欄位：
# ExecutablePath: /usr/bin/gnome-shell
# Signal: 11 (SIGSEGV)
# Stacktrace: ...  # 呼叫堆疊，可對照原始碼定位

四、常見誤區與建議

誤區	事實
點「報告錯誤」後就不會再彈	錯誤，若同程式持續崩潰仍會重複彈窗
這是嚴重系統錯誤	多為非致命的 GUI 程式崩潰，系統核心服務通常正常
必須上傳才能修復	開發者多已知悉常見崩潰，上傳主要補充環境資訊
停用 Apport 會降低系統穩定	錯誤，Apport 純屬事後收集，不影響程式運行邏輯

五、建議策略

1. 一般使用者：執行方案二永久停用，專注於系統更新（sudo apt update && sudo apt upgrade）修復已知 Bug
2. 開發者/高級用戶：保留 Apport，定期檢視 /var/crash/，針對關鍵服務崩潰提交詳細報告
3. 伺服器/無頭系統：預設無 GUI，Apport 僅寫入 /var/crash/，可配合 logrotate 定期清理

Ubuntu 的錯誤回報機制初衷良善，但對非開發者而言更多是干擾。理解其運作原理後，依需求選擇「清理歷史」或「徹底停用」，即可獲得純淨的桌面體驗。