跳至內容

當我使用 Session Manager 連線到 Amazon EC2 執行個體時,為什麼會收到「Plugin with name Standard_Stream not found」錯誤?

3 分的閱讀內容
0

我嘗試使用 Session Manager (AWS Systems Manager 的一項功能) 連線到我的 Amazon Elastic Compute Cloud (Amazon EC2) 執行個體。但是,我收到「Plugin with name Standard_Stream not found」錯誤訊息。

簡短說明

如果 AWS Systems Manager Agent (SSM Agent) 無法建立所需的檔案來建立工作階段,則您會收到以下錯誤訊息:

「Your session has been terminated for the following reasons: Plugin with name Standard_Stream not found.Step name: Standard_Stream」

如果您的執行個體儲存空間不足,或同時開啟過多檔案,通常就會發生此問題。

若要識別問題原因,請檢查您的系統日誌以取得特定的錯誤訊息。然後,根據您找到的錯誤採取以下疑難排解動作。

解決方法

疑難排解「No space left on device」錯誤

您必須在根分區上擁有足夠的空間,以便 SSM Agent 建立啟動工作階段所需的暫存資料。如果您收到「No space left on device」錯誤訊息,則必須增加根檔案系統上的可用空間。首先,移除根分區中未使用的檔案。如果空間仍然不足,則使用 Elastic Volumes 增加您的 Amazon Elastic Block Store (Amazon EBS) 磁碟區。或者,使用以下其中一種方法,在作業系統 (OS) 層級擴充根檔案系統。

使用 SSH 或 EC2 序列主控台擴充根檔案系統

請完成以下步驟:

  1. 使用 SSHEC2 序列主控台連線到您的執行個體。
    **注意:**若要使用 EC2 序列主控台,您必須設定 EC2 序列主控台的存取權。如需需求的詳細資訊,請參閱 EC2 序列主控台的先決條件

  2. 若要檢查根分區上的可用空間,請執行以下命令:

    df -Th

    範例輸出:

    $ df -Th
    
    Filesystem Type Size Used Avail Use% Mounted on
    
    devtmpfs devtmpfs 4.0M 0 4.0M 0% /dev
    
    tmpfs tmpfs 3.9G 0 3.9G 0% /dev/shm
    
    tmpfs tmpfs 1.6G 440K 1.6G 1% /run
    
    /dev/nvme0n1p1 xfs 8.0G 2.0G 6.0G 25% /
    
    tmpfs tmpfs 3.9G 0 3.9G 0% /tmp
    
    /dev/nvme0n1p128 vfat 10M 1.3M 8.7M 13% /boot/efi
    
    tmpfs tmpfs 782M 0 782M 0% /run/user/1000
  3. 若要檢視區塊型儲存設備和根分區的名稱與檔案系統類型等詳細資訊,請執行以下 lsblk 命令:

    lsblk -f

    範例輸出:

    $ lsblk -f
    NAME          FSTYPE LABEL           UUID                                 MOUNTPOINT
    nvme0n1
    ├─nvme0n1p1   xfs    /               abcd123-abcd-1234-abcd-abcdef1234 /
    └─nvme0n1p128
  4. 若要擴充分區,請執行以下命令:

    sudo growpart /dev/nvme0n1 1

    **注意:**請將 nvme0n1 替換為分區名稱。

  5. 若要確認您已擴充分區,請重新執行 lsblk 命令。在輸出中,請確認分區大小與磁碟區大小相同。

  6. 若要擴展檔案系統,請根據您的檔案系統類型執行以下其中一個命令。
    ext4 磁碟區:

    sudo resize2fs /dev/nvme0n1p1

    **注意:**請將 nvme0n1p1 替換為分區名稱。
    XFS 磁碟區:

    sudo xfs_growfs -d /

使用救援執行個體擴充根檔案系統

如果您無法使用 SSH 連線到無法連線的執行個體,請在與無法連線執行個體相同的可用區域中建立救援執行個體。如需說明,請參閱我該如何對因資源過度使用而導致狀態檢查失敗的 EC2 Linux 執行個體進行疑難排解?中的對「No space left on device」錯誤進行疑難排解將根磁碟區掛載到救援執行個體後,請擴充檔案系統

疑難排解「Too many open files」錯誤

如果您超過 inotify 資源上限,則 SSM Agent 無法建立建立工作階段所需的新檔案描述元。如果您同時開啟過多檔案或檔案描述元,或核心的 inotify 子系統超過其執行個體或監看配額上限,就會發生此問題。如需更多資訊,請參閱 man7 網站上的 inotify

若要疑難排解此問題,請採取以下動作。

重新開機或重新啟動您的執行個體

若要重新啟動所有程序並釋放使用中的 inotify 資源,請重新開機停止並啟動該執行個體。

**注意:**當您停止並啟動執行個體時,執行個體的公共 IP 位址會變更。最佳實務是使用彈性 IP 位址,而不是公共 IP 位址,將外部流量路由至您的執行個體。如果您使用 Amazon Route 53,則在公共 IP 位址變更時,您可能需要更新 Route 53 DNS 記錄

在您停止並啟動執行個體之前,請採取以下動作:

增加您的 inotify 配額

如果重新開機或重新啟動後您仍然遇到問題,請完成以下步驟以增加執行個體上的 inotify 配額:

  1. 執行以下命令以檢查 inotify 配額:
    cat /proc/sys/fs/inotify/max_user_watches
    cat /proc/sys/fs/inotify/max_user_instances
    **注意:**預設情況下,max_user_watches8192,且 max_user_instances128
  2. 若要暫時提高配額上限值,請執行以下命令:
    sudo sysctl fs.inotify.max_user_watches=newwatchesquota
    sudo sysctl fs.inotify.max_user_instances=newinstancesquota
    **注意:**請將 newwatchesquota 替換為 max_user_watches 的新配額,並將 newinstancesquota 替換為 max_user_instances 的新配額。前述命令會更新配額,直到您下次重新啟動執行個體為止。最佳實務是先透過暫時性變更測試更新後的值。
  3. 若要讓配額更新永久生效,請將以下參數新增至 /etc/sysctl.conf 檔案:
    echo "fs.inotify.max_user_watches = newwatchesquota" >> /etc/sysctl.d/20-fs-inotify.conf
    echo "fs.inotify.max_user_instances = newinstancesquota" >> /etc/sysctl.d/20-fs-inotify.conf
    **注意:**請將 newwatchesquota 替換為 max_user_watches 的新配額,並將 newinstancesquota 替換為 max_user_instances 的新配額。
  4. 重新啟動執行個體以套用變更。

**注意:**修改執行個體後,最佳實務是監控系統效能,以驗證更新後的配額符合您的系統需求。

相關資訊

為什麼我無法使用 Session Manager 連線到 Amazon EC2 執行個體?

增加 Amazon ECBS 磁碟區後,如何在 Amazon EC2 執行個體上擴充 Linux 檔案系統?

AWS 官方已更新 5 個月前