當我使用 Session Manager 連線到 Amazon EC2 執行個體時,為什麼會收到「Plugin with name Standard_Stream not found」錯誤?
我嘗試使用 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 序列主控台擴充根檔案系統
請完成以下步驟:
-
使用 SSH 或 EC2 序列主控台連線到您的執行個體。
**注意:**若要使用 EC2 序列主控台,您必須設定 EC2 序列主控台的存取權。如需需求的詳細資訊,請參閱 EC2 序列主控台的先決條件。 -
若要檢查根分區上的可用空間,請執行以下命令:
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 -
若要檢視區塊型儲存設備和根分區的名稱與檔案系統類型等詳細資訊,請執行以下 lsblk 命令:
lsblk -f範例輸出:
$ lsblk -f NAME FSTYPE LABEL UUID MOUNTPOINT nvme0n1 ├─nvme0n1p1 xfs / abcd123-abcd-1234-abcd-abcdef1234 / └─nvme0n1p128 -
若要擴充分區,請執行以下命令:
sudo growpart /dev/nvme0n1 1**注意:**請將 nvme0n1 替換為分區名稱。
-
若要確認您已擴充分區,請重新執行 lsblk 命令。在輸出中,請確認分區大小與磁碟區大小相同。
-
若要擴展檔案系統,請根據您的檔案系統類型執行以下其中一個命令。
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 記錄。
在您停止並啟動執行個體之前,請採取以下動作:
- 如果您的執行個體使用執行個體儲存體,請將執行個體儲存體上的磁碟區資料儲存到永續性儲存體。例如,您可以將資料儲存到 Amazon EBS 磁碟區 或 Amazon Simple Storage Service (Amazon S3) 儲存貯體。
**重要:**當您停止執行個體時,Amazon EC2 會刪除執行個體儲存體資料。 - 建立 Amazon EBS 磁碟區的快照。如果您遇到問題,可以使用快照來還原您的執行個體。
- 暫時將執行個體從其 Amazon EC2 Auto Scaling 群組中移除,以免在停止執行個體時誤將其終止。
**注意:**EC2 Auto Scaling 可能會根據您的縮減保護設定終止 Auto Scaling 群組中已停止的執行個體。您使用 Amazon EMR、AWS CloudFormation 或 AWS Elastic Beanstalk 啟動的執行個體,可能位於 Auto Scaling 群組中。 - 將 Set the instance shutdown behavior (設定執行個體關機行為) 設定為 Stop (停止),以確保執行個體在停止時不會終止。
增加您的 inotify 配額
如果重新開機或重新啟動後您仍然遇到問題,請完成以下步驟以增加執行個體上的 inotify 配額:
- 執行以下命令以檢查 inotify 配額:
**注意:**預設情況下,max_user_watches 為 8192,且 max_user_instances 為 128。cat /proc/sys/fs/inotify/max_user_watches cat /proc/sys/fs/inotify/max_user_instances - 若要暫時提高配額上限值,請執行以下命令:
**注意:**請將 newwatchesquota 替換為 max_user_watches 的新配額,並將 newinstancesquota 替換為 max_user_instances 的新配額。前述命令會更新配額,直到您下次重新啟動執行個體為止。最佳實務是先透過暫時性變更測試更新後的值。sudo sysctl fs.inotify.max_user_watches=newwatchesquota sudo sysctl fs.inotify.max_user_instances=newinstancesquota - 若要讓配額更新永久生效,請將以下參數新增至 /etc/sysctl.conf 檔案:
**注意:**請將 newwatchesquota 替換為 max_user_watches 的新配額,並將 newinstancesquota 替換為 max_user_instances 的新配額。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 - 重新啟動執行個體以套用變更。
**注意:**修改執行個體後,最佳實務是監控系統效能,以驗證更新後的配額符合您的系統需求。
相關資訊
相關內容
AWS 官方已更新 5 個月前