在 Linux 上調查虛擬工作階段建立失敗 - Amazon DCV

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

在 Linux 上調查虛擬工作階段建立失敗

虛擬工作階段是在 Linux 上建立，並使用 命令：

$ dcv create-session session

只有在工作階段的建立失敗時，此命令才會傳回錯誤。不過，可能會發生工作階段最初已成功建立，但會在使用者連線之前終止。您可能會注意到這一點，因為當您檢查現有工作階段時，例如使用 命令dcv list-sessions或 dcv describe-session session，您可能不會得到列出的工作階段。

在大多數情況下，這是因為已建立桌面工作階段，但之後會立即失敗，例如，如果初始化指令碼啟動的應用程式之一當機或失敗，或者如果缺少其中一個必要的工具，就會發生這種情況。

如果工作階段建立失敗，請檢查下列項目：

  • 檢查包含與建立新工作階段程序的 dcv 元件相關日誌/var/log/dcv/sessionlauncher.log的檔案。

  • 檢查包含與 dcv init 指令碼相關日誌/var/log/dcv/dcv-session.user.session.log的檔案。

  • 檢查主目錄中對應至工作階段擁有者$HOME/.xsession-errors的檔案。此檔案包含系統 X 工作階段初始化指令碼產生的日誌，通常包含桌面工作階段管理員或指令碼呼叫的其他應用程式產生的日誌。

  • 檢查系統日誌，以取得有關失敗系統和元件的詳細資訊。首先，請檢查 的輸出 dmesg（例如，在程序失敗的情況下） 和 journalctl -xe。

  • 使用 failsafe 工作階段進行測試，以確認問題是否不依賴使用中的工作階段管理員。

如果故障只發生在特定使用者 ，您也可以嘗試下列操作：

  • 檢查使用者組態，特別是刪除或重新命名使用者組態時會發生的情況。

    視桌面環境和版本而定，組態目錄可能是使用者目錄中.config的 .gnome .kde或 。

  • 檢查影響使用者PATH或環境的特定使用者組態。通常，特定使用者的工作階段啟動失敗是由於架構，例如anaconda覆寫一些標準原生命令，可能會導致工作階段初始化中的dbus連線失敗。

  • 檢查許可問題。在本機~/.dbus或 ~/.Xauthority（例如，它們可能由 擁有root而非使用者） 上設定的許可錯誤，可能會導致桌面工作階段立即終止。