AWS Cloud9トラブルシューティング
以下の情報を使用して、AWS Cloud9 の問題を特定および対処します。
該当する問題が以下に示されていない場合や、追加のヘルプが必要な場合は、AWS Cloud9 ディスカッションフォーラム
トピック
- 環境の作成エラー:「EC2 インスタンスを作成することができません ...」
- 環境作成エラー: 「sts:AssumeRole を実行する権限がありません」
- コンソールエラー: 「ユーザーにはリソースでアクションを実行する権限がありません」
- フェデレーティッドアイデンティティで環境を作成できない
- 環境を開くことができない
- AWS Cloud9 Installer がハングまたは失敗する
- SSH 環境エラー: 「pty.js をインストールするには Python バージョン 2.7 が必要です」
- アプリケーションプレビューまたはファイルプレビュー通知:「サードパーティーの Cookie が無効になっています」
- アプリケーションプレビュータブにエラーが表示される、または空白になる
- 実行中のアプリケーションを IDE の外部で表示できない
- 環境を再ロードした後、アプリケーションプレビューを最新の情報に更新する必要がある
- EC2 環境で一部のコマンドまたはスクリプトが実行できない
- AWS CLI / aws-shell エラー: 「リクエストに含まれているセキュリティトークンが無効です」 (EC2 環境)
- Amazon EC2 インスタンスが自動的に更新されない
- Lambda ローカル関数実行エラー: SAM Local をインストールできない
- IDE による警告:「この環境のメモリが不足しています」または「この環境の CPU ロードが高くなっています」
- ファイルをプレビューすると 499 エラーが返される
- 環境の削除エラー:「1 つ以上の環境を削除できませんでした」
- コンソールの警告:「最小限のコード補完エンジンに切り替えます...」
- 「Package Cloud9 IDE 1」を表示した後に AWS Cloud9 インストーラが終了しない
- EC2-Classic アカウントの VPC エラー:「環境にアクセスできません」
- AWS Cloud9 環境が開けません:「この環境には現在、共同作業者がアクセスできません。マネージド一時認証情報の削除が完了するまでお待ちください。または、この環境の所有者にお問い合わせしてください。」
- AWS CloudFormation を使って EC2 環境を作成するときに「インスタンスプロファイル AWSCloud9SSMinStanceProfile がアカウントに存在しません」と報告するエラーメッセージ
- AWS CloudFormation を使用してEC2環境を作成するときに「実行する権限がありません:ssm: StartSession on Resource」を報告するエラーメッセージ
- AWS CLI を使用して EC2 環境を作成するときに、「実行する権限がありません: iam:GetInstanceProfile on resource: instance profile AWSCloud9SSMInstanceProfile」を報告するエラーメッセージ
- VPC の IP アドレスが Docker によって使用されているため、EC2 環境に接続できません
- AWSツールキット実行時のエラー:「環境の inode が不足しています。'fs.inotify.max_user_watches' の制限を増やしてください。」
- 注意:コラボレーションサポートの依存関係をインストールできませんでした
- C++ プロジェクトのデバッグ時に、gdb を伴うエラー
- AWS Cloud9 環境に十分なディスク領域がないため、SAM アプリケーションをローカルのAWS ツールキットで実行中のエラー
- 古いバージョンの Microsoft Edge ブラウザを使用して IDE をロードできません
- デフォルトの暗号化が Amazon EBS ボリュームに適用されている場合に、環境の作成障害がでる
- サイトへの接続が安全でないため、IDE で ウェブコンテンツをプレビューできません
- AWS License Manager ライセンス設定が Amazon EC2 インスタンスに関連付けられていると、コンソールから AWS Cloud9 を起動できません
- tmux セッションエラーのため AWS Cloud9 でターミナルウィンドウと対話できない
環境の作成エラー:「EC2 インスタンスを作成することができません ...」
問題: AWS Cloud9 開発環境 の作成を試みると、「アカウントの検証とアクティベーション中に、アカウントで EC2 インスタンスを作成できません」というメッセージが表示される。
原因: 現在、AWS はお客様の AWS アカウントを検証およびアクティブ化中です。アクティベーションが完了するまで (最大 24 時間かかる場合があります)、この環境やその他の環境を作成することはできません。
解決策: 後で環境をもう一度作成してみてください。24 時間以上経過してもこのメッセージがまだ表示される場合は、aws-verification@amazon.com
(先頭に戻る)
環境作成エラー: 「sts:AssumeRole を実行する権限がありません」
問題: 新しい環境を作成しようとすると、エラー「sts:AssumeRole を実行する権限がありません」が表示され、環境が作成されません。
考えられる原因: AWS Cloud9 サービスにリンクされたロールが AWS アカウントに存在しません。
推奨される解決策: AWS Command Line Interface (AWS CLI) または aws-shell を使用して次のコマンドを実行し、AWS Cloud9 サービスにリンクされたロールを AWS アカウント内で作成します。
aws iam create-service-linked-role --aws-service-name cloud9.amazonaws.com # For the AWS CLI. iam create-service-linked-role --aws-service-name cloud9.amazonaws.com # For the aws-shell.
これを実行できない場合は、AWS アカウントの管理者に確認してください。
このコマンドを実行した後、もう一度環境の作成を試します。
(先頭に戻る)
コンソールエラー: 「ユーザーにはリソースでアクションを実行する権限がありません」
問題: AWS Cloud9 コンソールを使用して AWS Cloud9 開発環境を作成または管理する場合、「User arn:aws:iam::123456789012:user/MyUser is not authorized to perform cloud9:action on resource arn:aws:cloud9:us-east-2:123456789012:environment:12a34567b8cd9012345ef67abcd890e1,(user/MyUser にはリソース arn:aws:cloud9:us-east-2:123456789012:environment:12a34567b8cd9012345ef67abcd890e で cloud9: アクションを実行する権限がありません)」に類似するフレーズが含まれるエラーが表示されます。ここでは、以下が示されます。
-
arn:aws:iam::123456789012:user/MyUser
は、リクエストするユーザーの Amazon リソースネーム (ARN) です。 -
action
は、ユーザーがリクエストしたオペレーションの名前です。 -
arn:aws:cloud9:us-east-2:123456789012:environment:12a34567b8cd9012345ef67abcd890e1
は、ユーザーがオペレーションを実行するためにリクエストした環境の ARN です。
原因: AWS Cloud9 コンソールにサインインするときに使用したユーザーに、このアクションを実行するための正しい AWS アクセス権限がありません。
解決策: ユーザーが正しい AWS アクセス権限を持っていることを確認して、もう一度アクションの実行を試みます。詳細については、次のトピックの 1 つ以上を参照してください。
-
エンタープライズセットアップ の ステップ 6. 組織内のグループとユーザーによる AWS Cloud9 の使用を有効にする
-
共有環境を使用するの 環境メンバーのアクセスロールについて
(先頭に戻る)
フェデレーティッドアイデンティティで環境を作成できない
問題: AWS フェデレーテッドアイデンティティを使用して AWS Cloud9 開発環境 を作成しようとすると、アクセスエラーメッセージが表示され、環境は作成されません。
原因: AWS Cloud9 はサービスにリンクされたロールを使用します。サービスにリンクされたロールは、iam:CreateServiceLinkedRole
コールを使用してアカウントに初めて環境が作成されたときに作成されます。ただし、フェデレーティッドユーザーは IAM API を呼び出すことができません。詳細については、AWS Security Token Service API リファレンスの「GetBucketEncryptiontak」を参照してください。
解決策: AWS アカウント管理者に、IAM コンソール内にあるか、AWS Command Line Interface (AWS CLI) でこのコマンドを実行して、サービスにリンクされた AWS Cloud9 のロールを作成するように依頼してください。
aws iam create-service-linked-role --aws-service-name cloud9.amazonaws.com
あるいは、次の aws-shell でこのコマンドを実行します。
iam create-service-linked-role --aws-service-name cloud9.amazonaws.com
詳細については、「IAM ユーザーガイド」の「サービスにリンクされたロールの使用」を参照してください。
(先頭に戻る)
環境を開くことができない
問題:環境を開こうとすると、IDE が長時間 (5 分以上) 表示されません。
考えられる原因:
-
コンソールにサインインした AWS Cloud9 ユーザーに環境を開くために必要な AWS アクセス許可がない。
-
この環境が AWS クラウドコンピューティングインスタンス (Amazon EC2 インスタンスなど) に関連する場合:
-
インスタンスに関連付けられた VPC が、AWS Cloud9 用に正しく設定されていません。
-
AWS Cloud9 がインスタンスに接続しようとしたときにインスタンスが状態から状態への遷移中、または自動化されたステータスチェックに失敗した。
-
-
環境が SSH 環境の場合、関連付けられているクラウドコンピューティングインスタンスまたは独自のサーバーが AWS Cloud9 によるアクセスを許可するように正しくセットアップされていない。
推奨される解決策:
-
AWS Cloud9 コンソールにサインインしている ユーザーに、環境を開くために必要なAWS アクセス権限があることを確認して、再度環境を開きます。詳細については以下を参照するか、AWS アカウントの管理者に確認してください。
-
チームセットアップの ステップ 3: グループに AWS Cloud9 アクセス許可を追加する
-
認証とアクセスコントロールの AWS Cloud9 用 AWS マネージドポリシー
-
アドバンストチーム設定の AWS Cloud9 を使用したチームのカスタマーマネージドポリシーの例
-
認証とアクセスコントロールの お客様のマネージドポリシーの例
-
「IAM ユーザーガイド」の「IAM ユーザーのアクセス許可の変更」を参照してください。
-
「IAM ユーザーガイド」の「IAM ポリシーのトラブルシューティング」
サインインしている ユーザーがまだ環境を開くことができない場合は、いったんサインアウトしてから、アカウントで AWS アカウントルートユーザーまたは IAM 管理者ユーザーとしてサインインし直してみます。その後、もう一度環境を開いてみてください。この方法で環境を開くことができる場合、可能性が最も高いのは IAM ユーザーのアクセス権限に問題がある場合です。
-
-
この環境が AWS クラウドコンピューティングインスタンス (Amazon EC2 インスタンスなど) に関連する場合:
-
インスタンスに関連付けられている VPC が AWS Cloud9 用に正しく設定されていることを確認してから、もう一度環境を開いてください。詳細については、「AWS Cloud9 の Amazon VPC 要件」を参照してください。
AWS クラウドコンピューティングインスタンスに関連付けられている VPC が AWS Cloud9 用に正しく設定されているが、それでも環境を開くことができない場合は、インスタンスのセキュリティグループによって AWS Cloud9 へのアクセスが妨げられている可能性があります。トラブルシューティングの手法としてのみ、セキュリティグループをチェックして、少なくともポート 22 経由のインバウンド SSH トラフィックがすべての IP アドレス (
Anywhere
または0.0.0.0/0
) について許可されていることを確認してください。指示については、「Linux インスタンス用 Amazon EC2 ユーザーガイド」https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html#describing-security-groupの「セキュリティグループについて説明する」および「セキュリティグループルールを更新する」を参照してください。追加の VPC トラブルシューティングの手順については、関連する 5 分間のビデオ「AWS ナレッジセンターのビデオ: VPC 内のインスタンスに接続できない場合の確認点とは?
」を YouTube ウェブサイトでご覧ください。 警告 トラブルシューティングが完了したら、「AWS Cloud9 のインバウンド SSH IP アドレスの範囲」の説明に従って、インバウンドルールを適切なアドレス範囲に設定してください。
-
インスタンスを再起動して、インスタンスが実行されており、すべてのシステムチェックをパスしていることを確認してから、もう一度環境を開いてください。詳細については、「Linux インスタンス用 Amazon EC2 ユーザーガイド」の「インスタンスの再起動」と「ステータスチェックの表示」を参照してください。およびの。
-
-
環境 が SSH 環境 の場合、関連付けられているクラウドコンピューティングインスタンスまたは独自のサーバーが AWS Cloud9 によるアクセスを許可するように正しくセットアップされていることを確認してから、もう一度環境を開いてください。詳細については、「SSH 環境ホスト要件」を参照してください。
(先頭に戻る)
AWS Cloud9 Installer がハングまたは失敗する
問題: AWS Cloud9 インストーラをダウンロードして実行する際に、1 つ以上のエラーメッセージが表示され、インストーラのスクリプトに「Done
」と表示されません。
原因: AWS Cloud9 インストーラで 1 つ以上のエラーが発生し、このエラーから復旧できないために失敗しています。
解決策: AWS Cloud9 インストーラのトラブルシューティング で、一般的なエラー、考えられる原因、および推奨される解決策を参照してください。
(先頭に戻る)
SSH 環境エラー: 「pty.js をインストールするには Python バージョン 2.7 が必要です」
問題: AWS Cloud9SSH 開発環境 を開いた後、AWS Cloud9 IDE のターミナルに「pty.js をインストールするには Python バージョン 2.7 が必要です」で始まるメッセージが表示されます。
原因: SSH 環境が意図したとおりに動作するには、Python バージョン 2.7 がインストールされている必要があります。
解決策:環境に Python バージョン 2.7 をインストールします。バージョンを確認するには、サーバーのターミナルからコマンド python --version
を実行します。サーバーに Python 2.7 をインストールするには、次のいずれかを参照してください。
-
Python サンプルの ステップ 1: Python をインストールする。
-
Python ウェブサイトの Download Python
および Python Packaging User Guide の「Installing Packages」。
(先頭に戻る)
アプリケーションプレビューまたはファイルプレビュー通知:「サードパーティーの Cookie が無効になっています」
問題: アプリケーションまたはファイルをプレビューしようとすると、次のメッセージと通知が表示されます。「ブラウザでサードパーティーの Cookie が無効になっているため、プレビュー機能が無効になっています。」
原因: サードパーティー Cookie は AWS Cloud9 IDE を開くために必要ありませんが、アプリケーションプレビュー機能またはファイルプレビュー機能を使用するには、サードパーティー Cookie を有効にする必要があります。
解決方法: ウェブブラウザでサードパーティーの Cookie を有効にし、IDE を再読み込みしてから、もう一度プレビューを開いてみてください。
-
Apple Safari: Apple サポートウェブサイトの「Safari」で Cookie と Web サイトのデータを管理する
。 -
Google Chrome: Google Chrome ヘルプウェブサイトの Chrome で Cookie の削除、有効化、管理を行う
の「Cookie の設定を変更する」を参照してください。 -
Internet Explorer: Microsoft サポートウェブサイトの 「cookie の削除と管理
」の中の Cookie のブロックまたは許可。 -
Microsoft Edge: マイクロソフトサポートウェブサイトにある「サードパーティー Cookie を禁止する
」。 -
Mozilla Firefox: Mozilla サポートウェブサイトの「設定を追跡するためウェブサイトで使用するCookie を有効または無効にする
」でサードパーティー cookie を受け入れます。 -
他のウェブブラウザの場合は、そのウェブブラウザのドキュメントを参照してください。
AWS Cloud9 にのみサードパーティーの Cookie を有効化するには(ウェブブラウザでこの詳細度が可能な場合)、AWS を使用する先のサポートされている AWS Cloud9 リージョンに応じて、以下のドメインを指定します。
AWS 地域 | ドメイン |
---|---|
米国東部(バージニア北部) |
|
米国東部 (オハイオ) |
|
米国西部 (北カリフォルニア) |
|
米国西部 (オレゴン) |
|
アフリカ (ケープタウン) |
|
アジアパシフィック (香港) |
|
アジアパシフィック (ムンバイ) |
|
アジアパシフィック (大阪) |
|
アジアパシフィック (ソウル) |
|
アジアパシフィック (シンガポール) |
|
アジアパシフィック (シドニー) |
|
アジアパシフィック (東京) |
|
カナダ (中部) |
|
欧州 (フランクフルト) |
|
欧州 (アイルランド) |
|
欧州 (ロンドン) |
|
ヨーロッパ (ミラノ) |
|
欧州 (パリ) |
|
欧州 (ストックホルム) |
|
中東 (バーレーン) |
|
南米 (サンパウロ) |
|
(先頭に戻る)
アプリケーションプレビュータブにエラーが表示される、または空白になる
問題: IDEのメニューバーで、[プレビュー、実行中のアプリケーションのプレビュー)]または[ツール、プレビュー、実行中のアプリケーションのプレビュー)]を選択して IDEのプレビュータブでアプリケーションを表示しようとすると、タブにエラーが表示されるか、タブが空白になります。
考えられる原因:
-
アプリケーションが IDE で実行されていない。
-
アプリケーションが HTTP を使用して実行されていない。
-
アプリケーションが複数のポート経由で実行されている。
-
アプリケーションが
8080
、8081
、または8082
以外のポート経由で実行されている。 -
アプリケーションが
127.0.0.1
、localhost
、または0.0.0.0
以外の IP で実行されている。 -
ポート (
8080
、8081
、または8082
) がプレビュータブの URL で指定されていない。 -
ネットワークがポート
8080
、8081
、または8082
へのインバウンドトラフィックをブロックしている。 -
IP
127.0.0.1
、localhost
、または0.0.0.0
を含むアドレスに移動しようとしている。AWS Cloud9 IDE に組み込まれているデフォルトの動作では、環境に接続されたインスタンスまたは独自のサーバーに移動しようとせずに、ローカルコンピュータに移動しようとします。
推奨される解決策:
-
IDE でアプリケーションが実行されていることを確認します。
-
HTTP を使用してアプリケーションが実行されていることを確認します。Node.js および Python の例については、「」を参照してくださいアプリケーションの実行
-
アプリケーションが 1 つのポート経由のみで実行されていることを確認します。Node.js および Python の例については、「」を参照してくださいアプリケーションの実行
-
アプリケーションがポート
8080
、8081
、または8082
経由で実行されていることを確認します。Node.js および Python の例については、「」を参照してくださいアプリケーションの実行 -
アプリケーションが IP
127.0.0.1
、localhost
、または0.0.0.0
を使用して実行されていることを確認します。Node.js および Python の例については、「」を参照してくださいアプリケーションの実行 -
プレビュータブの URL に
:8080
、:8081
、または:8082
を追加します。 -
ネットワークがポート
8080
、8081
、または8082
経由のインバウンドトラフィックを許可していることを確認します。ネットワークを変更できない場合は、ネットワーク管理者にお問い合わせください。 -
127.0.0.1
、localhost
、または0.0.0.0
の IP を含むアドレスに移動しようとしている場合、代わりにhttps://12a34567b8cd9012345ef67abcd890e1.vfs.cloud9.us-east-2.amazonaws.com/
への移動を試みます。 ここでは、12a34567b8cd9012345ef67abcd890e1
は AWS Cloud9 が環境 に割り当てる ID であり、us-east-2
は 環境 用 AWS リージョンの ID です。 IDE 外でこのアドレスへの移動を試みることもできますが、環境用の IDE が開いており、アプリケーションが同じウェブブラウザで実行されている場合のみ機能します。 -
上記の条件がすべて満たされていることを確認して、アプリケーションを停止してから再度起動してみてください。
-
アプリケーションを停止してから再度起動した場合は、メニューバーで再度[Preview (プレビュー)]、[Preview Running Application (実行中のアプリケーションのプレビュー)]または[Tools (ツール)]、[Preview (プレビュー)]、[Preview Running Application (実行中のアプリケーションのプレビュー)]を選択します。対応するアプリケーションプレビュータブが既に表示されている場合は、そのタブで[Refresh (最新の情報に更新)]ボタン (円状の矢印) を選択します。
(先頭に戻る)
実行中のアプリケーションを IDE の外部で表示できない
問題: IDE 外部のウェブブラウザタブで実行中のアプリケーションを表示しようとすると、そのウェブブラウザタブがエラーを表示するか、空白になります。
考えられる原因:
-
アプリケーションが IDEで実行されていない。
-
アプリケーションが
127.0.0.1
またはlocalhost
の IP で実行されている。 -
アプリケーションが AWS Cloud9 EC2 開発環境で実行されており、対応する Amazon EC2 インスタンスに関連付けられている 1 つ以上のセキュリティグループが、アプリケーションで必要とするプロトコル、ポート、または IP アドレス経由のインバウンドトラフィックを許可していない。
-
アプリケーションが AWS クラウドコンピューティングインスタンス (Amazon EC2 インスタンスなど) 用の AWS Cloud9 SSH 開発環境 で実行されており、対応するインスタンスに関連付けられている Virtual Private Cloud (VPC) のサブネットのネットワーク ACL が、アプリケーションで必要とするプロトコル、ポート、または IP アドレス経由のインバウンドトラフィックを許可していない。
-
URL に誤りがある。
-
インスタンスのパブリック IP アドレスではなく、アプリケーションプレビュータブの URL がリクエストされている。
-
IP
127.0.0.1
またはlocalhost
を含むアドレスに移動しようとしている。これらの IP は、環境のリソースではなくローカルコンピュータ上のリソースにアクセスしようとします。 -
インスタンスのパブリック IP アドレスが変更された。
-
ウェブリクエストが、アプリケーションで必要とするプロトコル、ポート、または IP アドレス経由のトラフィックをブロックしている仮想プライベートネットワーク (VPN) から送信されている。
-
アプリケーションが SSH 環境で実行されており、サーバーまたは関連付けられたネットワークが、アプリケーションで必要とするプロトコル、ポート、または IP アドレス経由のインバウンドトラフィックを許可していない。
推奨される解決策:
-
IDE でアプリケーションが実行されていることを確認します。
-
アプリケーションが IP
127.0.0.1
またはlocalhost
を使用して実行されていないことを確認します。Node.js および Python の例については、「」を参照してくださいアプリケーションの実行 -
アプリケーションが AWS クラウドコンピューティングインスタンス ( Amazon EC2 インスタンスなど) で実行されている場合は、対応するインスタンスに関連付けられているすべてのセキュリティグループが、アプリケーションで必要とするプロトコル、ポート、および IP アドレス経由のインバウンドトラフィックを許可していることを確認します。指示については、実行中のアプリケーションをインターネット上で共有するの ステップ 2: インスタンスのセキュリティグループを設定する を参照してください。「Amazon VPC ユーザーガイド」の「VPC のセキュリティグループ」を参照してください。
-
アプリケーションが AWS クラウドコンピューティングインスタンスで実行されており、対応するインスタンスに関連付けられている VPC のサブネットにネットワーク ACL が存在する場合、そのネットワーク ACL でアプリケーションで必要とするプロトコル、ポート、および IP アドレス経由のインバウンドトラフィックを許可されていることを確認します。指示については、実行中のアプリケーションをインターネット上で共有するの ステップ 3: インスタンスのサブネットをセットアップする を参照してください。また、「Amazon VPC ユーザーガイド」の「ネットワーク ACL」を参照してください。
-
プロトコル (およびポートを指定する必要がある場合はポート) を含むリクエストしている URL が正しいことを確認します。指示については、実行中のアプリケーションをインターネット上で共有するの ステップ 4: 実行中のアプリケーションの URL を共有する を参照してください。
-
https://12a34567b8cd9012345ef67abcd890e1.vfs.cloud9.us-east-2.amazonaws.com/
形式 (12a34567b8cd9012345ef67abcd890e1
は AWS Cloud9 が環境に割り当てる ID、us-east-2
は AWS リージョンの ID) の URL リクエストは推奨されません。この URL を使用するには、環境の IDE が開いており、アプリケーションが同じウェブブラウザで実行されている必要があります。 -
IP
127.0.0.1
またはlocalhost
を含むアドレスに移動しようとしている場合、代わりに実行中のアプリケーションのローカルではない正しいアドレスに移動してみます。詳細については、「実行中のアプリケーションをインターネット経由で共有する」を参照してください。 -
アプリケーションが AWS クラウドコンピューティングインスタンスで実行されている場合、インスタンスのパブリック IP アドレスが変更されたかどうかを判断します。インスタンスのパブリック IP アドレスは、インスタンスが再起動されると変更される可能性があります。この IP アドレスの変更を防ぐには、Elastic IP アドレスを割り当てて、それを実行中のインスタンスに割り当てます。指示については、実行中のアプリケーションをインターネット上で共有するの ステップ 4: 実行中のアプリケーションの URL を共有する を参照してください。
-
ウェブリクエストが VPN から送信されている場合は、その VPN でアプリケーションで必要とするプロトコル、ポート、および IP アドレス経由のトラフィックが許可されていることを確認します。VPN を変更できない場合は、ネットワーク管理者にお問い合わせください。または、可能であれば別のネットワークからウェブリクエストを行います。
-
アプリケーションが独自のサーバーの SSH 環境で実行されている場合は、サーバーおよび関連付けられたネットワークで、アプリケーションで必要とするプロトコル、ポート、または IP アドレス経由のインバウンドトラフィックが許可されていることを確認します。サーバーまたは関連付けられているネットワークに変更を加えることができない場合は、サーバーまたはネットワークの管理者にお問い合わせください。
-
curl
コマンドに URL を続けて実行し、環境のターミナルからアプリケーションの実行を試みます。このコマンドでエラーメッセージが表示される場合、AWS Cloud9 に関連しない他の問題がある可能性があります。
(先頭に戻る)
環境を再ロードした後、アプリケーションプレビューを最新の情報に更新する必要がある
問題: アプリケーションプレビュータブを表示する環境を再ロードした後、タブにアプリケーションプレビューが表示されません。
原因: ユーザーの書き込みコードが無限ループを実行する場合や、使用するメモリ量が多すぎるためにアプリケーションプレビューを実行する際に AWS Cloud9 IDE が一時停止または停止する場合があります。これを防止するには、環境が再ロードされても、AWS Cloud9 ではアプリケーションプレビュータブを再ロードしません。
解決策: アプリケーションプレビュータブを表示する環境を再ロードした後で、アプリケーションプレビューを表示するには、タブの [Click to load the page (クリックしてページをロード)]ボタンを選択します。
(先頭に戻る)
EC2 環境で一部のコマンドまたはスクリプトが実行できない
問題: AWS Cloud9 EC2 開発環境 を開いた後、一部のタイプのパッケージのインストール、yum
または apt
などのコマンドの実行、通常 Ubuntu など、他の Linux オペレーティングシステムで使用されるコマンドを含むスクリプトの実行ができない。
原因: AWS Cloud9 が EC2 環境のために使用する Amazon EC2 インスタンスは Amazon Linux (Red Hat Enterprise Linux (RHEL) ベースのもの) または Ubuntu Server のいずれかに依存しています。
解決策: EC2 環境用に IDE でパッケージをインストールしたり管理したり、コマンドやスクリプトを実行したりする場合は、その環境のインスタンスに応じて、RHEL (Amazon Linux用) または Ubuntu Server と互換性があることを確認してください。
(先頭に戻る)
AWS CLI / aws-shell エラー: 「リクエストに含まれているセキュリティトークンが無効です」 (EC2 環境)
問題: AWS Command Line Interface (AWS CLI) または aws-shell を使用して EC2 環境の AWS Cloud9 IDE でコマンドを実行しようとすると、「リクエストに含まれているセキュリティトークンが無効です」というエラーが表示されます。
原因:AWS マネージド一時認証情報があり、以下のいずれかが発生すれば、セキュリティトークンが無効二なる可能性があります。
-
AWS マネージド一時認証情報によって許可されていないコマンドを実行しようとしました。許可されたコマンドの一覧については、「」を参照してくださいAWS マネージド一時認証情報によってサポートされるアクション
-
-AWSマネージド一時認証情報は 15 分後に自動的に有効期限切れになります。
-
共有環境の AWS マネージド一時認証情報が非アクティブ化されました。これは、環境所有者以外のユーザーによって新しいメンバーが追加されたためです。
推奨される解決策:
-
AWSマネージド一時認証情報によって許可されているあのコマンドのみを実行します。AWS マネージド一時認証情報によって許可されていないコマンドを実行する必要がある場合、環境のAWS CLI または aws-shell を一連の永続的認証情報を使って設定し、この制限を取り除くことができます。手順については、「環境に永続的アクセス認証情報を作成して保存する」を参照してください。
-
非アクティブ化または有効期限切れの認証情報については、環境所有者が環境を開き、AWS Cloud9 は、環境の一時的認証情報を更新できます。詳細については、「マネージド一時認証情報へのアクセスのコントロールAWS」を参照してください。
(先頭に戻る)
Amazon EC2 インスタンスが自動的に更新されない
問題: 最近のシステム更新が、AWS Cloud9 開発環境 に接続する Amazon EC2 インスタンスに自動的に適用されません。
原因: 事前の情報や承認なく自動的に最近の更新を適用すると、コードやAmazon EC2 インスタンスで予期しない動作が発生する可能性があります。
推奨される解決策:
「Linux インスタンス用 Amazon EC2 ユーザーガイド」の「インスタンスソフトウェアの更新」にある指示に従って、定期的に Amazon EC2 インスタンスにシステム更新を適用します。
インスタンスでコマンドを実行するには、インスタンスに接続されている環境 からAWS Cloud9 IDE でターミナルセッションを使用できます。
また、ssh や PuTTY などの SSH リモートアクセスユーティリティを使用してインスタンスに接続できます。これを行うには、ローカルコンピュータから、ssh-keygen または PuTTYgen などの SSH キーペア作成ユーティリティを使用します。インスタンスに接続されている環境からAWS Cloud9 IDE を使用して、生成したパブリックキーをインスタンスに保存します。次に、生成されたプライベートキーとともに SSH リモートアクセスユーティリティを使用して、インスタンスにアクセスします。詳細については、ユーティリティのドキュメントを参照してください。
(先頭に戻る)
Lambda ローカル関数実行エラー: SAM Local をインストールできない
問題: AWS Cloud9 IDE でローカルバージョンの AWS Lambda 関数の実行を試みた後、SAM Local のインストールで AWS Cloud9 に問題が発生したと書かれたダイアログボックスが表示されます。AWS Cloud9 は、 IDE でローカルバージョンの AWS Lambda 関数を実行するために SAM Local を必要とします。SAM Local がインストールされるまで、IDEでローカルバージョンの Lambda 関数を実行することはできません。
原因: AWS Cloud9 が環境の予定されたパスで SAM Local を見つけられません。これは ~/.c9/bin/sam
です。これは SAM Local がまだインストールされていないか、インストールされている場合は AWS Cloud9 がその場所に見つけられないためです。
推奨される解決策: AWS Cloud9 によって SAM Local のインストールが完了するまで待つか、自分でインストールします。
SAM Local をインストールするために AWS Cloud9 が行っている動作を確認するには、メニューバーで[Window (ウィンドウ)]、[Installer]を選択します。
SAM Local を自分でインストールするには、「AWS Serverless Application Modelデベロッパーガイド」の「Linux での AWS SAM CLIのインストール」で提供されている指示に従います。
IDE による警告:「この環境のメモリが不足しています」または「この環境の CPU ロードが高くなっています」
問題: IDE の実行中、「この環境のメモリが不足しています」または「この環境の CPU ロードが高くなっています」という内容のメッセージが表示される。
原因: IDE に、遅延やハングアップしないで実行を続けるのに必要なコンピューティングリソースがない可能性があります。
推奨される解決策:
-
実行中のプロセスを 1 つ以上停止し、使用可能なメモリを解放してください。これを行うには、メニューバーにある環境用 IDE で、[ツール、プロセスリスト)]を選択します。停止するプロセスごとに、プロセスを選択して[Force Kill (強制終了)]を選択します。
-
環境で swap ファイルを作成します。スワップファイルは、オペレーティングシステムが仮想メモリとして使用できる環境内のファイルです。
環境が現在、スワップメモリを使用しているかどうかを確認するには、
top
環境のターミナルセッションでコマンドを実行します。スワップメモリが使用されている場合、出力にゼロ以外のSwap
メモリ統計が表示されます (たとえば、Swap: 499996k total, 1280k used, 498716 free, 110672k cached
)。リアルタイムのメモリ情報の表示をやめるには、Ctrl + C
を押します。スワップファイルを作成するには、環境で次のようなコマンドを実行することができます。
sudo fallocate --length 512MB /var/swapfile && sudo chmod 600 /var/swapfile && sudo mkswap /var/swapfile && echo '/var/swapfile swap swap defaults 0 0' | sudo tee -a /etc/fstab > /dev/null
前述のコマンドは以下の処理を実行します。
-
swapfile
ディレクトリに/var
という 512 MB のファイルを作成します。 -
swapfile
ファイルのアクセス権限を所有者のみの読み取り/書き込みに変更します。 -
swapfile
ファイルをスワップファイルとして設定します。 -
情報を
/etc/fstab file
に書き込みます。これにより、システムが再起動するたびにこのスワップファイルが使用可能になります。
前述のコマンドを実行したら、再起動しなくてもこのスワップファイルをすぐに使用可能にするため、次のコマンドを実行します。
sudo swapon /var/swapfile
-
-
環境をコンピューティングリソースの多いインスタンスまたはサーバーに移動するか、サイズを変更します。Amazon EC2 インスタンスを移動またはサイズ変更するには、「環境の移動と Amazon EBS ボリュームのサイズ変更または暗号化」を参照してください。他のインスタンスまたはサーバータイプについては、インスタンスまたはサーバーのドキュメントを参照してください。
(先頭に戻る)
ファイルをプレビューすると 499 エラーが返される
問題: AWS Cloud9 IDE でプレビューするファイルに <script>
要素が含まれていて、この要素内に src
属性があり、type
属性が module
に設定されていると、499 エラーが発生し、スクリプトは予期どおりに実行されません。
原因: AWS Cloud9 IDE のファイルプレビューのフェッチリクエストでは、認証のためにウェブブラウザから Cookie を送信する必要があります。crossorigin
属性を追加した場合を除き、デフォルトでは、ウェブブラウザは通常のスクリプトリクエストに対しては Cookie を送信しますが、モジュールスクリプトリクエストに対しては Cookie を送信しません。
解決策: crossorigin
属性を <script>
要素に追加します。例えば、<script type="module"
src="index.js" crossorigin></script>
です。次に変更したファイルを保存し、再度プレビューを試みます。
(先頭に戻る)
環境の削除エラー:「1 つ以上の環境を削除できませんでした」
問題: AWS Cloud9 コンソールで 1 つ以上の環境を削除しようとすると、「1 つ以上の環境を削除できませんでした」というメッセージが表示されます。このとき、少なくとも 1 つの環境は削除されません。
考えられる原因: AWS CloudFormation で、1 つ以上の の削除に問題が発生しました (AWS Cloud9 が環境の作成または削除で AWS CloudFormation に依存しています)。
推奨される解決策: AWS CloudFormation を使用して、削除されなかった環境のそれぞれの削除を試みてください。手順は以下のとおりです。
https://console.aws.amazon.com/cloudformation
で AWS CloudFormation コンソール を開きます。 -
AWS ナビゲーションバーで、環境の AWS リージョンを選択します。
-
AWS CloudFormation スタックのリストで、[スタックの名前]に削除されなかった環境名が示され、[ステータス]が[DELETE_FAILED]になっているエントリを選択します。たとえば、環境名が
my-demo-environment
の場合は、aws-cloud9-my-demo-environment を含む名前で始まるスタックを選択します。(環境名の横にあるボックスまたはオプションを選択してください。環境名自体は選択しないでください)。 -
[アクション]、[スタックの削除]の順に選択します。
-
プロンプトが表示されたら、[はい、削除します]を選択します。
スタックの削除処理には数分かかる場合があります。
スタックがリストから消えた場合、環境は削除されています。
スタックがまだ表示されており、数分たっても[DELETE_FAILED]と表示されている場合、環境はまだ削除されていません。その場合は、障害が発生した各スタックのリソースを手動で削除してみてください。
障害が発生したスタックのリソースを手動で削除すると、スタック自体は AWS アカウントから削除されません。
これらのリソースを手動で削除するには、AWS CloudFormation コンソールで、障害が発生したスタックを選択してから[リソース]セクションを選択します。AWS で、このリストの各リソースのコンソールに移動し、それぞれのコンソールを使用して手動でリソースを削除します。
(先頭に戻る)
コンソールの警告:「最小限のコード補完エンジンに切り替えます...」
問題: AWS Cloud9 コンソールで作業している場合 (IDE を開いたり、IDE のウェブページを更新したりする場合など)、「1 つ以上のセッションまたは共同作業者がこの環境でアクティブです。メモリを節約するために最小限のコード補完エンジンに切り替えます。」」というメッセージが表示される。このメッセージと相関して、コード補完の動作が遅いか断続的になっている可能性がある。
原因: コード補完エンジンを実行すると、環境からメモリと CPU サイクルが消費されます。さらに、共同作業者および追加のセッションごとに個別のコード補完エンジンが必要です。特に t2.nano や t2.micro などの小さなインスタンスサイズで、リソースの使用量が多すぎないようにするため、AWS Cloud9 は最小限のコード補完エンジンに切り替えます。
推奨される解決策: 頻繁および長期間共同作業を行う場合は、EC2 環境を作成する際により大きい Amazon EC2 インスタンスを選択します。または、SSH 環境をより容量の大きいインスタンに接続します。
より大きな Amazon EC2 インスタンスを選択すると、 AWS アカウントに追加料金が発生する場合があります。詳細については、「Amazon EC2 の料金表
(先頭に戻る)
「Package Cloud9 IDE 1」を表示した後に AWS Cloud9 インストーラが終了しない
問題: AWS Cloud9 は、SSH 開発環境を作成するプロセスのパートとして、既存の Amazon EC2 インスタンスまたは独自のサーバーにインストールされます。[AWS Cloud9 インストーラ]ダイアログボックスに「Package Cloud9 IDE 1」というメッセージが表示されて、インストールが停止します。[キャンセル]を選択すると、「インストールに失敗しました」というメッセージが表示されます。このエラーは、お客様の SSH ホストに AWS Cloud9 パッケージをインストールできない場合に発生します。
原因: SSH ホストでは、Node.js がインストールされている必要があります。現在、Node.js 0.6.16 から Node.js 12.x までのバージョンがサポートされています。AWS Cloud9 でサポートされていないバージョンの Node.js がホストにある場合、インストールエラーが発生する可能性があります。
推奨される解決策:SSH ホストで AWS Cloud9サポートを行うNode.jsのバージョンをインストールする。
(先頭に戻る)
EC2-Classic アカウントの VPC エラー:「環境にアクセスできません」
問題: EC2-Classic は、Amazon EC2 のオリジナルリリースで導入されました。 2013 年 12 月 4 日より前に設定した AWS アカウントを使用している場合、AWS Cloud9 EC2 開発環境を作成する時に、virtual private cloud(Amazon VPC)とサブネットを明示的に設定しなければ、エラーが発生する可能性があります。
デフォルトの VPC 設定を受け入れると、Amazon EC2 インスタンスはデフォルト VPC のサブネットではなく EC2-Classic ネットワーク内で起動されます。環境の作成に失敗すると、次のメッセージが表示されます。
環境エラー
環境にアクセスできません
環境の作成はエラーで失敗しました: 次のリソースの作成に失敗しました:[インスタンス]。ユーザーによってロールバックがリクエストされました。
EC2 インスタンスがデフォルト VPC に存在しないためにエラーが発生したことを確認できます。開発環境のスタックイベント履歴を表示する場合に AWS CloudFormation を使用します。
-
AWS CloudFormation コンソールを開きます。詳細については、「AWS CloudFormationコンソールにログイン」を参照してください。
-
AWS CloudFormation コンソールで、[スタック]を選択します。
-
[スタック]ページで、作成に失敗した開発環境の名前を選択します。
-
[スタックの詳細]ページで、[イベント]タブを選択し、次のエントリ をチェックします。
ステータス: CREATE_FAILED
ステータスの理由: AssociatePublicIPAddress パラメータは、VPC の起動でのみサポートされています。[...]
原因: AWS Cloud9 開発環境は、特定の VPC 要件を満たす Amazon VPC に関連付けられている必要があります。EC2-Classic が有効なアカウントの場合、EC2 環境の作成 時にデフォルトのネットワーク設定を受け入れると、必要な EC2 インスタンスが VPC 内で起動されません。代わりに、インスタンスは EC2-Classic ネットワーク内で起動されます。
推奨される解決策: EC2-Classic アカウントでは、EC2 環境の作成時に VPC とサブネットを選択する必要があります。[設定の構成]ページの[ネットワーク設定 (アドバンスト)]セクションで、EC2 インスタンスを起動できる VPC とサブネットを選択します。
(先頭に戻る)
AWS Cloud9 環境が開けません:「この環境には現在、共同作業者がアクセスできません。マネージド一時認証情報の削除が完了するまでお待ちください。または、この環境の所有者にお問い合わせしてください。」
問題:環境所有者以外のユーザーによって新しい共同作業者が環境に追加された場合、AWS マネージド一時認証情報は、無効になっています。認証情報は、~/.aws/credentials
ファイルを削除すると無効になります。~/.aws/credentials
ファイルの削除が進行中の間、新しい共同作業者が AWS Cloud9 環境にアクセスできません。
原因: AWS マネージド一時認証情報の削除中に環境へのアクセスができないのは、セキュリティ対策です。環境の所有者は、信頼できる共同作業者だけがマネージド認証情報報にアクセスできるという確認を許可されます。共同作業者のリストが有効であることが確認できたら、環境所有者はマネージド認証情報を再度有効にして共有することができます。詳細については、「マネージド一時認証情報へのアクセスのコントロールAWS」を参照してください。
推奨される解決策: AWS Cloud9環境を開く再試行をする前に、~/.aws/credentials
ファイルの削除が完了するのをお待ちください。認証情報待機時間の有効期限は最大 15 分です。または、マネージド一時認証情報を再度有効または無効にするよう、環境所有者に依頼します。認証情報が再び有効または無効になると、共同作業者はすぐに環境にアクセスできます。(マネージド認証情報の状態を ENABLED または DISABLED に切り替えることで、環境所有者は認証情報が共同作業者が環境にアクセスできない中間状態のままにならないようにします)。
環境所有者と共同作業者が同じ AWS アカウントを使っている場合、共同作業者は、コンソール上の自分の環境ページで環境のカードをレビューして、連絡すべき環境所有者を識別してお問い合わせできます。環境所有者も、環境の詳細ページにあがっています。
(先頭に戻る)
AWS CloudFormation を使って EC2 環境を作成するときに「インスタンスプロファイル AWSCloud9SSMinStanceProfile がアカウントに存在しません」と報告するエラーメッセージ
問題:AWS::Cloud9::EnvironmentEC2 使用時、AWS CloudFormation リソースを使用して EC2 環境を作成した場合、ユーザーは「インスタンスプロファイル AWSCloud9SSMinStanceProfile がアカウントに存在しません
」というエラーメッセージを受け取ります。
原因:no-ingress EC2 環境を作成するときは、サービスロールAWSCloud9SSMAccessRole
およびインスタンスプロファイル AWSCloud9SSMInstanceProfile
を作成する必要があります。これらの IAM リソースにより、Systems Manager による開発環境をバックアップする EC2 インスタンスを管理が有効になります。
コンソールで no-ingress 環境を作成する場合、AWSCloud9SSMAccessRole
および AWSCloud9SSMInstanceProfile
は自動的に作成されます。しかし、AWS CloudFormation または AWS CLI を使用して初めて no-ingress 環境を作成する場合は、これらの IAM リソースを手動で作成する必要があります。
推奨される解決策:AWS CloudFormation テンプレート編集およびIAM 許可の更新の詳細については、「AWS CloudFormation を使用して、no-ingress EC2 環境を作成する」を参照してください。
AWS CloudFormation を使用してEC2環境を作成するときに「実行する権限がありません:ssm: StartSession on Resource」を報告するエラーメッセージ
問題:AWS::Cloud9::EnvironmentEC2 AWS CloudFormation リソースを EC2 環境の作成に使用するとき、ユーザーは AccessDeniedException
を受け取り、「ssm:StartSession をリソースで実行する認可がおりていません」と通知されます。
原因: ユーザーには no-ingress インスタンス用Systems Manager を活用する EC2 環境の設定パートとして必要なStartSession
API を呼び出す許可がおりていません。
推奨される解決策:AWS CloudFormation テンプレートの編集および IAM 許可の更新の詳細については、「AWS CloudFormation を使用して、no-ingress EC2 環境を作成する」を参照してください。
(先頭に戻る)
AWS CLI を使用して EC2 環境を作成するときに、「実行する権限がありません: iam:GetInstanceProfile
on resource: instance profile AWSCloud9SSMInstanceProfile
」を報告するエラーメッセージ
問題: AWS CLI を使用して EC2 環境を作成するときに、ユーザーは AccessDeniedException
を受け取り、自身の AWS Cloud9 環境で「実行する権限がありません: iam:GetInstanceProfile on resource: instance profile AWSCloud9SSMInstanceProfile
」と通知されます。
原因: AWS Cloud9 には no-ingress インスタンス用 Systems Manager を活用する EC2 環境の設定パートとして必要な StartSession
API を呼び出す許可がおりていません。
推奨される解決策: 必須の AWSCloud9SSMAccessRole
サービスロールと AWSCloud9SSMInstanceProfile
を AWS Cloud9 環境に追加する方法については、AWS CLI を使ったSystems Manager のインスタンスプロファイルの管理を参照してください。
(先頭に戻る)
VPC の IP アドレスが Docker によって使用されているため、EC2 環境に接続できません
問題:EC2 環境で、IPv4 クラスレスドメイン間ルーティング(CIDR)ブロック 172.17.0.0/16
を使用する Amazon VPC(仮想プライベートクラウド)に EC2 インスタンスを起動した場合、その環境を開こうとすると、接続が停止することがあります。
原因:Dockerは、ブリッジネットワークと呼ばれるリンクレイヤーデバイスを使用して、同じブリッジネットワークに接続されたコンテナが通信できるようにします。AWS Cloud9は、コンテナ通信にデフォルトのブリッジを使用するコンテナを作成します。デフォルトのブリッジは、コンテナのネットワークに通常 172.17.0.0/16
サブネットを使用します。
環境のインスタンスの VPC サブネットが、Docker で既に使用されているアドレス範囲と同じアドレス範囲を使用している場合、IP アドレスの競合が発生する可能性があります。したがって、AWS Cloud9 がインスタンスに接続しようとすると、その接続はゲートウェイルートテーブルによって EC2 インスタンスではなく Docker ブリッジにルーティングされます。このため、AWS Cloud9 は、開発環境をバックアップする EC2 インスタンスに接続できません。
推奨される解決策:同じ IPv4 CIDR アドレスブロックを使用する Amazon VPC と Docker によって引き起こされる IP アドレスの競合を解決するには、EC2 環境をバッキングするインスタンス用に新しい VPC を設定します。この新しいVPC では、172.17.0.0/16
とは異なるCIDR ブロックを設定します。既存の VPC またはサブネットの IP アドレスの範囲を変更することはできません。
設定情報については、「Amazon VPC ユーザーガイド」の「VPC とサブネットサイジング」を参照してください。
(先頭に戻る)
AWSツールキット実行時のエラー:「環境の inode が不足しています。'fs.inotify.max_user_watches' の制限を増やしてください。」
問題:AWSツールキットが使用するファイルウォッチャーユーティリティ は、監視できるファイルの現在の制限に近づいています。
原因: AWSツールキット は、ファイルとディレクトリの変更をモニタリングするファイルウォッチャーユーティリティを使用します。ユーティリティが監視できるファイルの現在の制限に近づくと、警告メッセージが表示されます。
推奨される解決策:ファイルウォッチャーで処理できるファイルの最大数を増やすには、次の操作を行います。
-
ターミナルセッションをスタートするには、メニューバーで、[Window (ウィンドウ)]、[New Terminal (新しいターミナル)]を選択します。
-
コマンドラインで次のとおりに入力します。
sudo bash -c 'echo "fs.inotify.max_user_watches=524288" >> /etc/sysctl.conf' && sudo sysctl -p
(先頭に戻る)
注意:コラボレーションサポートの依存関係をインストールできませんでした
問題: AWS Cloud9は、依存関係をダウンロードするためにインターネットアクセスが必要です。もしAWS Cloud9 がそれらの依存関係をダウンロードできない場合、Notice
ダイアログボックスに次のエラーが表示されます。
Failed to install dependencies for collaboration support Please try to resolve this problem and refresh the page to enable collaboration support. A common cause is a lack of available disk space. Error was: Error downloading from location <LINK> to <LOCATION> Problem was: Error: connect ETIMEDOUT <IPADDRESS>
考えられる原因:使用しているAWS Cloud9環境がプロキシを使用してインターネットにアクセスしている場合、AWS Cloud9 には、依存関係をインストールするプロキシ詳細が必要です。このエラーは、プロキシの詳細をAWS Cloud9 に提供していない場合、表示されます。
推奨される解決策:プロキシの詳細を AWS Cloud9 に提供する場合は、次の内容を環境~/.bashrc
ファイルに追加します。
export http_proxy=<proxy url for http> export https_proxy=<proxy url for https>
たとえば、http プロキシ URLが http://172.31.26.80:3128
であり、https プロキシ URL がhttps://172.31.26.80:3129
の場合は、以下の行を~/.bashrc
ファイルを追加します。
export http_proxy=http://172.31.26.80:3128 export https_proxy=https://172.31.26.80:3129
これらの環境変数が存在するのは /etc/profile
であり、~/.bashrc
ではなく、AWS Cloud9 はその変数を使用できません。/etc/profile
はログインシェル専用だからです。/etc/profile
も ~/.bashrc
をロードするため、~/.bashrc
で設定を行うことで、は、環境変数がログインシェルと AWS Cloud9 の両方で必ず利用できます。
(先頭に戻る)
C++ プロジェクトのデバッグ時に、gdb
を伴うエラー
問題:IDE で C++ プロジェクトをデバッグしようとすると、gdb
デバッガに報告されるエラー
考えられる原因:AWS Cloud9 環境が特定の EC2 インスタンスタイプ(t3.small
またはm5.large
など)を使用している場合、IDE の組み込みランナーを使用して C++ プロジェクトを実行およびデバッグしようとすると、デバッグエラーが発生することがあります。このエラーは、環境にプリインストールされた gdb
(GNU プロジェクトデバッガ) は、特定のプロセッサプラットフォームでは動作しません。次のエラーコードが表示されることがあります。
GDB server terminated with code 1
推奨される解決策:gdb
が特定のプロセッサプラットフォームをサポートしていないという問題は、バージョン3.0以降で修正されました。したがって、古いバージョンのデバッガをアンインストールし、新しいバージョンのgdb
にアップグレードします。
-
AWS Cloud9 ターミナルの次のコマンドを実行して、既存のバージョンのデバッガーを削除します。:
sudo yum -y remove gdb
-
gdb
のためのアーカイブを取得し、解凍してから、次のコマンドを実行して、展開したファイルが含まれているディレクトリに移動します。wget "http://ftp.gnu.org/gnu/gdb/gdb-8.3.tar.gz" tar xzf gdb-8.3.tar.gz cd gdb-8.3
-
次のコマンドを実行してデバッガを構築します (下のテキストを単一のブロックとして貼り付け、[Return (戻る)]を押して、
make
を実行します。)。./configure --prefix=/usr \ --with-system-readline \ --with-python=/usr/bin/python3 && make
-
デバッガをインストールします。
sudo make -C gdb install
-
最後に、更新されたバージョンのデバッガがインストールされていることを確認します。
gdb
--version
(先頭に戻る)
AWS Cloud9 環境に十分なディスク領域がないため、SAM アプリケーションをローカルのAWS ツールキットで実行中のエラー
問題:AWS ツールキットを使って、SAMテンプレートによって定義されたアプリケーション用 AWS SAM CLIコマンドを実行しようとするとエラーが発生します。
考えられる原因:サーバーレスアプリケーションをAWS ツールキットを使ってローカルで実行およびデバッグするときに、AWS SAM は、ランタイム環境を提供する Docker イメージを使用し、デプロイを計画している Lambda 環境をエミュレートするツールを構築します。
しかし、環境に十分なディスク容量がない場合、これらの機能を提供するDocker イメージは構築できず、ローカル SAM アプリケーションを実行できません。この問題が発生した場合は、次のように、[Output (出力)]タブにエラーが表示される場合があります、
Error: Could not find amazon/aws-sam-cli-emulation-image-python3.7:rapid-1.18.1 image locally and failed to pull it from docker.
このエラーは、Python ランタイムを使用して構築された SAM アプリケーションに関連します。アプリケーション用に選択したランタイムによっては、若干異なるメッセージが表示される場合があります。
推奨される解決策:Docker イメージを構築できるように、環境内のディスク領域を解放します。IDE の端末で次のコマンドを実行して、未使用の Docker イメージを削除します。
docker image prune -a
ディスク容量の制限により SAM CLI コマンドに問題が繰り返し発生する場合は、開発環境に切り替えを考え、別のインスタンスタイプを使用します。
(先頭に戻る)
古いバージョンの Microsoft Edge ブラウザを使用して IDE をロードできません
問題: Microsoft Edge ウェブブラウザを使ってAWS Cloud9 IDE をロードしようとしたときにHTTP403: FORBIDDEN
エラーが返ってきます。
考えられる原因: AWS Cloud9 IDE は、一部の古いバージョンの Microsoft Edge をサポートしていません。
推奨される解決策:ブラウザを更新するには、Microsoft Edge ツールバーの省略記号 (...) ボタンをクリックします。メニューで、[設定]を選択して[Microsoft Edge について]を選択します。アップデートが必要な場合は、自動的にダウンロードされ、インストールされます。
(先頭に戻る)
デフォルトの暗号化が Amazon EBS ボリュームに適用されている場合に、環境の作成障害がでる
問題: Failed to create environments. The development environment '[environment-ID]' failed
to create
Amazon EC2 環境を作成しようとすると、エラーが返されます。
考えられる原因:AWS Cloud9 IDE が、デフォルトで暗号化された Amazon EBS ボリュームを使用する場合、AWS Cloud9 用にAWS Identity and Access Management サービスにリンクされたロールは、これらの EBS ボリューム用のAWS KMS keys へのアクセスが必要です。アクセスが提供されない場合、AWS Cloud9 IDE の起動に失敗し、デバッグが困難になる場合があります。
推奨される解決策: アクセスを提供するには、AWS Cloud9、AWSServiceRoleForAWSCloud9
のサービスにリンクされたロールをAmazon EBS ボリュームで使用されるカスタマーマネージドキーに追加します。
このタスクの詳細については、AWS規範的ガイダンスパターンの「AWS Cloud9デフォルトの暗号化で Amazon EBS ボリュームを使用する を作成する」を参照してください。
(先頭に戻る)
サイトへの接続が安全でないため、IDE で ウェブコンテンツをプレビューできません
問題:AWS Cloud9 EC2 環境でホストされているWeb コンテンツ (WordPress サイトなど) にアクセスしようとすると、IDE プレビューウィンドウには表示できません。
考えられる原因:デフォルトでは、AWS Cloud9 IDE のアプリケーションのプレビュータブでアクセスするすべての Web ページは、自動的に HTTPS プロトコルを使用します。ページの URI が安全でない http
プロトコルを備えている場合、https
に自動的に置き換えられます。また、手動で https
を http
に戻す変更を行っても、安全でないコンテンツにアクセスすることはできません。
推奨される解決策: IDE でプレビューしようとしている ウェブサイトから安全ではない HTTP スクリプトまたはコンテンツを削除します。HTTPS の実装に関するガイダンスについては、ウェブサーバーまたはコンテンツ管理システムの指示に従ってください。
(先頭に戻る)
AWS License Manager ライセンス設定が Amazon EC2 インスタンスに関連付けられていると、コンソールから AWS Cloud9 を起動できません
問題: コンソールから AWS Cloud9 EC2 環境を起動しようとすると、「unable to access your environment
」エラーが返されます。
考えられる原因: AWS License Manager では、AWS Cloud におけるソフトウェアベンダーライセンスの管理が合理化されます。License Manager を設定するときは、エンタープライズ契約の条項に基づくライセンスルールのセットであるライセンス設定を作成します。これらのライセンス設定を Amazon マシンイメージ (AMI) や AWS CloudFormation などのメカニズムに添付できます。このメカニズムを使用して、EC2 インスタンスを起動します。
AWSServiceRoleForAWSCloud9 サービスにリンクされたロール (SLR) の AWSCloud9ServiceRolePolicy の古いバージョンには現在 license-configuration
リソース条件が含まれていないため、AWS Cloud9 ではそのインスタンスの起動と停止ができません。そのため、AWS Cloud9 の Amazon EC2 インスタンスへのアクセスは拒否され、エラーが返されます。
推奨される解決策: 既存の AWS Cloud9 環境にアクセスできず、License Manager を使用している場合は、古い AWSCloud9ServiceRolePolicy サービスにリンクされたロールを license-configuration
のインスタンスへの適用時に明示的に EC2 アクションを許可する SLR のバージョンに置き換えます。古いロールを削除するだけで置き換えることができます。その後、更新されたロールが自動的に作成されます。
(先頭に戻る)
tmux セッションエラーのため AWS Cloud9 でターミナルウィンドウと対話できない
問題:AWS Cloud9 で新しいターミナルウィンドウを起動しようとすると、期待されるコマンドラインインターフェイスが使用できない。コマンドプロンプトがなく、テキストを入力できない。
考えられる原因:ターミナルが応答しないのは、tmux エラーが原因である可能性があります。AWS Cloud9 は tmux
tmux セッションでは、ターミナルウィンドウに表示されるものはクライアントによって処理され、クライアントは複数のセッションを管理できるサーバーと通信します。サーバとクライアントは、tmp
フォルダにあるソケットを介して通信します。開発環境に tmp
フォルダがないか、適用される許可が過度に制限されている場合、tmux セッションは実行できません。この場合、IDE のターミナルウィンドウは応答しなくなります。
推奨される解決策: tmux エラーによってターミナルウィンドウとの対話が妨げられている場合は、tmux セッションを実行できるように、別の方法を使用して適切な許可を持つ tmp
フォルダを作成する必要があります。最も簡単なアプローチは、AWS Systems Manager を使用して、ホスト管理構成をセットアップすることです。これにより、Amazon EC2 コンソールを介して関連するインスタンスにアクセスできます。
ホスト管理の設定
最初に、AWS Cloud9 コンソールで、[環境] ページで関連するパネルを選択し、[詳細の表示] を選択して、環境のインスタンスの名前を見つけます。[環境の詳細] ページで [インスタンスに移動] を選択します。Amazon EC2 コンソールで、アクセスする必要があるインスタンスの名前を確認します。
ここで、AWS Systems Manager コンソールに移動し、ナビゲーションペインで [クイックセットアップ] を選択します。
[クイックセットアップ] ページで [作成] を選択します。
[設定タイプ] では、[ホスト管理] に移動し、[登録] を選択します。
[ホスト管理構成オプションのカスタマイズ] の [ターゲット]セクションで、[手動]を選択します。
アクセスする EC2 インスタンスを選択してから、[作成] を選択します。
インスタンスに接続してコマンドを実行する
以下の手順は、新しい EC2 コンソール用です。
Amazon EC2 コンソールのナビゲーションペインで、[インスタンス] を選択し、接続するインスタンスを選択します。
[Connect] を選択します。
[接続] がアクティブ化されていない場合は、最初にインスタンスの起動が必要になる場合があります。
[インスタンスへ接続] ペインの [接続方法] で、[Session Manager]、そして [接続] を選択します。
表示されるターミナルセッションウィンドウで、次のコマンドを入力し、tmux ソケットが利用可能になるように、適切な権限を持つ
tmp
フォルダを作成します。sudo mkdir /tmp sudo chmod 777 /tmp sudo rmdir /tmp/tmux-*
(先頭に戻る)