使用JournalCtl，特定於應(yīng)用程序的日誌文件和桌面環(huán)境日誌檢查系統(tǒng)和應(yīng)用程序日誌以識別錯(cuò)誤消息； 2。使用DMESG來檢測內(nèi)核級問題，例如OOM殺手級動(dòng)作或分割故障； 3.將應(yīng)用程序從終端運(yùn)行以捕獲實(shí)時(shí)錯(cuò)誤輸出，例如丟失的庫或權(quán)限問題； 4。用LDD驗(yàn)證依賴性並解決丟失或衝突的共享庫； 5。通過創(chuàng)建新用戶或重命名配置目錄以排除損壞的設(shè)置來測試乾淨(jìng)的用戶環(huán)境； 6。使用GDB進(jìn)行崩潰回溯和strace來監(jiān)視系統(tǒng)呼叫失??； 7。檢查資源限制，包括內(nèi)存，文件描述符和GPU驅(qū)動(dòng)程序問題，並在需要時(shí)嘗試軟件渲染； 8。對於沙盒應(yīng)用程序（Flatpak，Snap，Appimage），驗(yàn)證權(quán)限和執(zhí)行要求；始終使用錯(cuò)誤消息更新系統(tǒng)並蒐索已知的錯(cuò)誤，因?yàn)榇蠖鄶?shù)崩潰源於缺失的依賴關(guān)係，配置問題，資源約束或應(yīng)用程序錯(cuò)誤，並且系統(tǒng)地使用這些步驟將有助於有效地識別和解決根本原因。

Linux上的應(yīng)用程序崩潰可能會令人沮喪，尤其是當(dāng)它們間歇性發(fā)生或沒有明確錯(cuò)誤消息時(shí)。但是，Linux提供了強(qiáng)大的工具和日誌，以幫助診斷和解決這些問題。這是對應(yīng)用程序進(jìn)行故障排除有效崩潰的實(shí)用指南。

1。檢查系統(tǒng)和應(yīng)用程序日誌

第一步是在系統(tǒng)和應(yīng)用程序日誌中尋找錯(cuò)誤消息。這些通常包含有關(guān)出了什麼問題的線索。

• 通過journalctl （用於基於系統(tǒng)的系統(tǒng)）的系統(tǒng)日誌：

  

   journalctl -xe

  或通過特定服務(wù)或時(shí)間過濾：

   journalctl -u your-service-name.service
  Journalctl-“ 2小時(shí)前”

• 特定於應(yīng)用程序的日誌：
  一些應(yīng)用程序?qū)⑷照I寫入/var/log/或他們自己的目錄（例如~/.appname/logs/ ）。檢查應(yīng)用程序的文檔中是否有日誌位置。

  

• Xorg/Wayland和桌面環(huán)境日誌：
  GUI應(yīng)用程序崩潰可能與顯示服務(wù)器有關(guān)。查看：

  • ~/.xsession-errors （較舊的x11會議）
  • journalctl -b用於桌面相關(guān)的錯(cuò)誤
  • Wayland Compositor Logs（例如，通過journalctl gnome-shell ）

2。使用dmesg捕獲內(nèi)核級別的崩潰

當(dāng)應(yīng)用程序因細(xì)分故障或違反內(nèi)存而崩潰時(shí)，內(nèi)核會記錄它。使用dmesg查看該過程是由OOM殺手終止還是用信號崩潰。

 DMESG | GREP-我“殺死過程”
DMESG | grep -i segfault

示例輸出：

 [12345.67890]不記憶：殺死過程1234（Firefox）得分500 ...
[12346.12345]陷阱：app_name [5678]通用保護(hù)故障...

這會告訴您該應(yīng)用是由於記憶壓力而被殺死的還是低級的撞車事故。

3。從終端運(yùn)行應(yīng)用程序

始終嘗試從終端模擬器啟動(dòng)該應(yīng)用程序。即使GUI應(yīng)用程序也經(jīng)常在從命令行運(yùn)行時(shí)輸出有用的調(diào)試信息。

您的應(yīng)用名稱

尋找：

• Python追溯
• 缺少庫（ error while loading shared libraries ）
• 許可拒絕錯(cuò)誤
• GTK/QT警告暗示了配置問題

例子：

 $ gimp
gimp：加載共享庫時(shí)的錯(cuò)誤：libgegl-0.4.so.0：無法打開共享對象文件：沒有這樣的文件或目錄

→這意味著庫缺失；通過您的軟件包管理器安裝它。

4。檢查依賴項(xiàng)和庫

使用ldd驗(yàn)證是否存在所有必需的共享庫：

 ldd/usr/bin/your-app

尋找任何行為“找不到”的行。如果是這樣，請使用發(fā)行版的軟件包管理器安裝相應(yīng)的軟件包。

另外，請注意來自不同來源的庫（例如，混合Flatpak，Appimage和Native軟件包），這可能會導(dǎo)致衝突。

5。用乾淨(jìng)的用戶環(huán)境進(jìn)行測試

有時(shí)，配置文件（在~/.config/ ， ~/.local/ ，或~/.appname/ ）被損壞。

測試：

• 創(chuàng)建新用戶：

   sudo adduser testuser
  su -testuser
  您的應(yīng)用名稱

• 或暫時(shí)重命名配置目錄：

   mv?/.config/appName?/.config/appName.bak

如果應(yīng)用程序有效，則該問題可能在您的用戶配置中。

6。使用調(diào)試工具： gdb和strace

進(jìn)行更深入的分析：

• gdb （GNU調(diào)試器） ：實(shí)時(shí)捕獲崩潰。

   gdb your-app
  （GDB）運(yùn)行

  崩潰時(shí)：

   （GDB）BT＃顯示回溯
  （GDB）信息寄存器

• strace ：跟蹤系統(tǒng)調(diào)用以查看應(yīng)用程序在崩潰之前在做什麼。

   strace -f your -app 2>＆1 | Tee Trace.Log

  尋找重複的故障（例如open() = -1 ENOENT或kill信號。

7.檢查資源限制和衝突

• 內(nèi)存：使用free -h和htop檢查系統(tǒng)是否用完RAM。
• 文件描述符：某些應(yīng)用程序點(diǎn)擊限制。檢查以下檢查：

   Ulimit -n

• GPU驅(qū)動(dòng)程序：在圖形繁重的應(yīng)用程序中崩潰（遊戲，瀏覽器，IDE）可能源於GPU驅(qū)動(dòng)程序。嘗試：
  • 更新MESA或?qū)Ｓ序?qū)動(dòng)程序（NVIDIA/AMD）
  • 使用軟件渲染運(yùn)行：

     libgl_always_software = 1 Your-App

8。考慮沙盒環(huán)境（Flatpak，snap，appimage）

沙箱應(yīng)用程序由於許可問題而可能失敗。

• Flatpak ：檢查權(quán)限：

   Flatpak列表 - 應(yīng)用
  Flatpak許可列表

  如果需要，請重置：

   Flatpak許可 -  com.example.app

• 適應(yīng)性：確保其已執(zhí)行許可並需要保險(xiǎn)絲支持。

最終提示

• 保持系統(tǒng)更新： sudo apt upgrade ， sudo dnf upgrade等。
• 使用確切的錯(cuò)誤消息在線搜索 - 其他人可能遇到相同的問題。
• 如果是已知的錯(cuò)誤，請檢查應(yīng)用程序的github/gitlab頁面或發(fā)行版的錯(cuò)誤跟蹤器。

基本上，大多數(shù)崩潰都?xì)w結(jié)為應(yīng)用程序本身中缺少DEP，配置問題，內(nèi)存問題或錯(cuò)誤。使用日誌和命令行工具使根本原因更容易發(fā)現(xiàn)。不要跳過簡單的東西 - 有時(shí)只是一個(gè)缺失的庫。

以上是故障排除應(yīng)用程序在Linux上崩潰的詳細(xì)內(nèi)容。更多資訊請關(guān)注PHP中文網(wǎng)其他相關(guān)文章！