AWS Cloud9 のトラブルシューティング - AWS Cloud9
Installer (インストーラ)AWS Cloud9環境Amazon EC2その他の AWS サービスアプリケーションプレビューパフォーマンスサードパーティのアプリケーションとサービス

新規のお客様への AWS Cloud9 の提供は終了しました。AWS Cloud9 の既存のお客様は、通常どおりサービスを引き続き使用できます。詳細はこちら

AWS Cloud9 のトラブルシューティング

以下の情報を使用して、AWS Cloud9 の問題を特定および対処します。

該当する問題が以下に示されていない場合や、追加のヘルプが必要な場合は、AWS Cloud9 ディスカッションフォーラムを参照してください。このフォーラムにアクセスするには、サインインが必要になることがあります。当社に直接お問い合わせいただくこともできます。

Installer (インストーラ)

次のセクションでは、AWS Cloud9 インストーラーに関連する問題のトラブルシューティングについて概説します。

AWS Cloud9 Installer がハングまたは失敗する

問題: AWS Cloud9 インストーラをダウンロードして実行する際に、1 つ以上のエラーメッセージが発生し、インストーラのスクリプトに「Done」と表示されません。

原因: AWS Cloud9 インストーラで 1 つ以上のエラーが発生し、このエラーから復旧できないために失敗しています。

解決策: 詳細については、「AWS Cloud9 インストーラのトラブルシューティング」を参照してください。一般的な問題、考えられる原因、および推奨される解決策を参照してください。

「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 バージョンをインストールすることをお勧めします。ホストに AWS Cloud9 でサポートしていないバージョンの Node.js がある場合、インストールエラーが発生する可能性があります。

推奨される解決策:SSH ホストで AWS Cloud9サポートを行うNode.jsのバージョンをインストールする。

依存関係をインストールできませんでした

問題: AWS Cloud9は、依存関係をダウンロードするためにインターネットアクセスが必要です。

考えられる原因:

  • AWS Cloud9 環境がプロキシを使用してインターネットにアクセスしている場合、AWS Cloud9 には、依存関係をインストールするプロキシ詳細が必要です。AWS Cloud9 にプロキシの詳細を提供しなかった場合、このエラーが表示されます。

  • 別の原因としては、環境がアウトバウンドトラフィックを許可していないことが考えられます。

推奨される解決策:

  • プロキシの詳細を AWS Cloud9 に提供するには、次のコードを環境の ~/.bashrc ファイルに追加します。

    export http_proxy=[proxy url for http]
export https_proxy=[proxy url for https]
#Certificate Authority used by your proxy
export NODE_EXTRA_CA_CERTS=[path_to_pem_certificate]

    例えば、HTTP プロキシ URL が https://172.31.26.80:3128 で、HTTP プロキシ URL が https://172.31.26.80:3129 である場合、次の行を ~/.bashrc ファイルに追加し、NODE_EXTRA_CA_CERTS を PEM 形式で認証機関のパスに設定します。この変数の詳細については、「https://nodejs.org/api/cli.html#node_extra_ca_certsfile」を参照してください。

    export http_proxy=http://172.31.26.80:3128
export https_proxy=https://172.31.26.80:3129
export NODE_EXTRA_CA_CERTS=[path_to_pem_certificate]

  • no-ingress Amazon EC2 インスタンスを使用している場合は、Amazon S3 の Amazon VPC エンドポイントが設定されていることを確認する必要があります。詳細については、「Amazon S3 のダウンロード依存関係に対応する Amazon VPC エンドポイントの設定」を参照してください。

SSH 環境エラー: 「pty.js をインストールするには Python バージョン 3 が必要です」

問題: AWS Cloud9 SSH 開発環境を開いた後、AWS Cloud9 IDE のターミナルに「pty.js をインストールするには Python バージョン 3 が必要です」で始まるメッセージが表示されます。

原因: SSH 環境が意図したとおりに動作するには、Python バージョン 3 がインストールされている必要があります。

解決策: 環境に Python バージョン 3 をインストールします。バージョンを確認するには、サーバーのターミナルからコマンド python --version を実行します。サーバーに Python 3 をインストールする方法については、次のいずれかを参照してください。

AWS Cloud9環境

次のセクションでは、AWS Cloud9 環境に関連する問題のトラブルシューティングについて概説します。

環境の作成エラー:「EC2 インスタンスを作成することができません ...」

問題: AWS Cloud9 開発環境 の作成を試みると、「アカウントの検証とアクティベーション中に、アカウントで EC2 インスタンスを作成できません」というメッセージが表示される。

原因: 現在、AWS は AWS アカウントを検証およびアクティブ化中です。アクティベーションが完了するまで (最大 24 時間かかる場合があります)、この環境やその他の環境を作成することはできません。

解決策: 後で環境をもう一度作成してみてください。24 時間経ってもこのメッセージが届く場合は、サポートにお問い合わせください。さらに、重要な留意事項として、環境を作成する試行が失敗しても、AWS CloudFormation はアカウントに関連スタックを作成します。これらのスタックは、アカウントのスタック作成クォータにカウントされます。スタック作成クォータの消費を避けるために、これらの失敗したスタックを削除できます。詳細については、「AWS CloudFormation ユーザーガイド」の「AWS CloudFormation コンソールのスタックを削除」を参照してください。

環境作成エラー: 「sts:AssumeRole を実行する権限がありません」

問題: 新しい環境を作成しようとすると、エラー「sts:AssumeRole を実行する権限がありません」が表示され、環境が作成されません。

考えられる原因: AWS Cloud9 サービスにリンクされたロールが AWS アカウントに存在しません。

推奨される解決策: AWS Cloud9 サービスにリンクされたロールを AWS アカウントに作成します。これを行うには、次のコマンドを AWS Command Line Interface (AWS CLI) または AWS CloudShell で実行できます。

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 フェデレーテッドアイデンティティを使用して 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 ユーザーガイドの「サービスにリンクされたロールの使用」を参照してください。https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html

コンソールエラー: 「ユーザーにはリソースでアクションを実行する権限がありません」

問題: AWS Cloud9 コンソールを使用して AWS Cloud9 開発環境を作成または管理しようとすると、「ユーザー arn:aws:iam::123456789012:user/MyUser にはリソース arn:aws:cloud9:us-east-2:123456789012:environment:12a34567b8cd9012345ef67abcd890e1 で cloud9:action を実行する権限がありません」といったフレーズを含むエラーが表示されます。

  • arn:aws:iam::123456789012:user/MyUser は、リクエストするユーザーの Amazon リソースネーム (ARN) です。

  • action は、ユーザーがリクエストしたオペレーションの名前です。

  • arn:aws:cloud9:us-east-2:123456789012:environment:12a34567b8cd9012345ef67abcd890e1 は、ユーザーがオペレーションを実行するためにリクエストした環境の ARN です。

原因: AWS Cloud9 コンソールにサインインするときに使用したユーザーに、このアクションを実行するための正しい AWS アクセス許可がありません。

解決策: ユーザーが正しい AWS アクセス許可を持っていることを確認して、もう一度アクションを実行してみます。詳細については、次を参照してください:

環境に接続できない

問題: ユーザーは環境に接続できず、接続段階で行き詰まっています。

原因: ~/ .ssh/authorized_keys ファイルのアクセス許可を変更した後で、そのファイルから AWS Cloud9 キーを削除するか、ファイルを完全に削除すると、この問題が発生する可能性があります。

解決策: このファイルを削除しないでください。削除した場合は、環境を再作成して、既存の環境の EBS ボリュームを新しい EC2 環境にアタッチする必要があります。これにより、失われたデータが取得されます。アクセス許可が足りない場合は、ファイルに Read-Write アクセス許可があることを確認してください。これにより、SSH デーモンがファイルを読み取れるようにします。

環境を開くことができない

問題: 環境を開こうとすると、IDE が 5 分以上表示されません。

考えられる原因:

  • AWS Cloud9 コンソールにサインインした IAM ユーザーには、環境を開くために必要な AWS アクセス許可がありません。

  • この環境が AWS クラウドコンピューティングインスタンス (Amazon EC2 インスタンスなど) に関連付けられている場合は、以下の可能性があります。

    • インスタンスに関連付けられている VPC が、AWS Cloud9 の正しい設定になっていません。

    • AWS Cloud9 がインスタンスに接続しようとしたときに、インスタンスが状態から状態への遷移中であるか、自動化されたステータスチェックに失敗しています。

  • 環境が SSH 環境の場合、関連付けられているクラウドコンピューティングインスタンスまたは独自のサーバーが AWS Cloud9 によるアクセスを許可するように正しくセットアップされていません。

推奨される解決策:

  • AWS Cloud9 コンソールにサインインした IAM ユーザーには、環境を開くために必要な AWS アクセス許可があることを確認してください。その後、もう一度環境を開いてみてください。詳細については、以下を参照するか、AWS アカウント 管理者にお問い合わせください。

    サインインしている IAM ユーザーが環境をまだ開くことができない場合は、いったんサインアウトしてから、アカウントの AWS アカウント ルートユーザーまたは管理者ユーザーとしてサインインし直してみます。その後、もう一度環境を開いてみてください。この方法で環境を開くことができない場合は、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) について許可されていることを確認してください。指示については、「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 アドレスの範囲」を参照してください。

    • インスタンスを再起動して、インスタンスが動作していること、およびすべてのシステムチェックをパスしていることを確認してから、もう一度環境を開いてみます。詳細については、Amazon EC2 ユーザーガイドで「インスタンスの再起動」と「ステータスチェックの表示」を参照してください。

  • 環境が SSH 環境の場合は、それに関連付けられているクラウドコンピューティングインスタンスまたは独自のサーバーが AWS Cloud9 によるアクセスを許可するように正しく設定されていることを確認します。その後、もう一度環境を開いてみてください。詳細については、「SSH 環境ホスト要件」を参照してください。

AWS Cloud9 環境を開けません:「この環境には現在、共同作業者がアクセスできません。マネージド一時認証情報の削除が完了するまでお待ちください。または、この環境の所有者にお問い合わせしてください。」

問題: 環境所有者以外のユーザーが新しい共同作業者を環境に追加すると、AWS マネージド一時認証情報が無効になります。~/.aws/credentials ファイルを削除すると、認証情報は無効になります。~/.aws/credentials ファイルの削除中は、新しい共同作業者が AWS Cloud9 環境にアクセスできません。

原因: AWS マネージド一時認証情報の削除中に環境へのアクセスができないのは、セキュリティ対策です。これにより、環境所有者は、信頼できる共同作業者だけがマネージド認証情報報にアクセスできることを確認できます。共同作業者のリストが有効であることが確認できたら、環境所有者はマネージド認証情報を再度有効にして共有することができます。詳細については、「マネージド一時認証情報へのアクセスのコントロールAWS」を参照してください。

推奨される解決策: ~/.aws/credentials ファイルの削除が完了するまで待ってから、AWS Cloud9 環境を開いてみます。認証情報待機時間の有効期限は最大 15 分です。または、マネージド一時認証情報を再度有効または無効にするよう、環境所有者に依頼します。認証情報が再び有効または無効になると、共同作業者はすぐに環境にアクセスできます。マネージド認証情報の状態を ENABLED または DISABLED に切り替えることで、環境所有者は、認証情報が中間状態に残らないようにします。中間状態では、共同作業者が環境にアクセスできない可能性があります。

注記

環境所有者と共同作業者が同じ AWS アカウントに属しているとします。この場合、共同作業者は、コンソールの [Your environments] (自分の環境) ページで環境カードを確認し、連絡先の環境所有者を特定できます。環境所有者も、環境の詳細ページにあがっています。

環境の削除エラー:「1 つ以上の環境を削除できませんでした」

問題: AWS Cloud9 コンソールで 1 つ以上の環境を削除しようとすると、「1 つ以上の環境を削除できませんでした」というメッセージが表示され、少なくとも 1 つの環境が削除されません。

考えられる原因: AWS CloudFormation で、1 つ以上の環境を削除できない可能性があります。AWS Cloud9 は、環境を作成または削除するために AWS CloudFormation が必要です。

推奨される解決策: AWS CloudFormation を使用して、削除されなかった各環境の削除を試みてください。

  1. AWS CloudFormation コンソール (https://console.aws.amazon.com/cloudformation) を開きます。

  2. AWS ナビゲーションバーで、環境の AWS リージョンを選択します。

  3. AWS CloudFormation スタックのリストで、［スタックの名前］に削除されなかった環境名が示され、［ステータス］が［DELETE_FAILED］になっているエントリを選択します。たとえば、環境名が my-demo-environment の場合は、aws-cloud9-my-demo-environment を含む名前で始まるスタックを選択します。(環境名の横にあるボックスまたはオプションを選択してください。環境名自体は選択しないでください)。

  4. ［アクション］、［スタックの削除］の順に選択します。

  5. プロンプトが表示されたら、［はい、削除します］を選択します。

スタックの削除処理には数分かかる場合があります。

スタックがリストから消えた場合、環境は削除されています。

数分たってもスタックに［DELETE_FAILED］と表示される場合、環境はまだ削除されていません。この場合、障害が発生した各スタックのリソースを手動で削除できます。

注記

障害が発生したスタックのリソースを手動で削除すると、スタック自体は AWS アカウント から削除されません。

これらのリソースを手動で削除するには、次の手順に従います。AWS CloudFormation コンソールで、障害が発生したスタックを選択して、[Resources] (リソース) セクションを選択します。AWS で、このリストの各リソースに対応するコンソールに移動し、そのコンソールを使用してリソースを削除します。

AWS Cloud9 IDE での環境のタイムアウト時間の変更

問題: ユーザーは Amazon EC2 環境のタイムアウト時間を更新したいと考えています。

原因: デフォルトのタイムアウト時間は 30 分です。これは一部のユーザーには短すぎるかもしれません。

推奨される解決策:

  1. 設定する環境を開きます。

  2. [AWS Cloud9 IDE] のメニューバーで、[AWS Cloud9]、[設定] の順に選択します。

  3. [設定] ウィンドウで、[Amazon EC2 インスタンス] セクションまでスクロールします。

  4. 使用可能なリストからタイムアウト値を選択し、更新します。

AWS Cloud9 環境に十分なディスク領域がないため、SAM アプリケーションをローカルのAWS ツールキットで実行中のエラー

問題:AWS ツールキットを使って、SAMテンプレートによって定義されたアプリケーション用 AWS SAM CLIコマンドを実行しようとするとエラーが発生します。

考えられる原因: AWS Toolkit を使用してサーバーレスアプリケーションをローカルで実行およびデバッグする場合、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 ツールバーの省略記号 (...) ボタンをクリックします。メニューで、[Settings] (設定) を選択して [About Microsoft Edge] ( について) を選択します。アップデートが必要な場合は、自動的にダウンロードされ、インストールされます。

(先頭に戻ります)

AWS Cloud9 IDE ファイルエクスプローラーで /home/ec2-user/environment/home/ec2-user/environment というサブフォルダー構造を作成できません。

問題: AWS Cloud9IDE ファイルエクスプローラーで /home/ec2-user/environment/home/ec2-user/environment というサブフォルダ構造を作成すると、このディレクトリを開くことができないというエラーメッセージが表示されます。

考えられる原因: 現在、AWS Cloud9 IDE のファイルシステムを使用して同じ名前のフォルダ内に /home/ec2-user/environment というサブフォルダ構造を作成することはできません。AWS Cloud9 IDE ファイルエクスプローラーからこのディレクトリ内のファイルにアクセスすることはできませんが、コマンドラインを使用してアクセスすることはできます。この問題の影響を受けるのは /home/ec2-user/environment/home/ec2-user/environment のファイルパスだけです。/test/home/ec2-user/environment や /home/ec2-user/environment/test などのファイルパスは機能します。これは既知の問題で、AWS Cloud9 IDE File Explorer にのみ影響します。

推奨される解決策： 別のファイル名と構造を使用してください。

(先頭に戻ります)

CodeCatalyst 用のAWS Cloud9 IDE のファイルエクスプローラー内に /projects/projects というサブフォルダー構造を作成できません。

問題: CodeCatalyst の AWS Cloud9 IDE ファイルエクスプローラーで /projects/projects というサブフォルダ構造を作成すると、このディレクトリを開くことができないというエラーメッセージが表示されます。

考えられる原因: 現在、AWS Cloud9 IDE のファイルシステムを使用して同じ名前のフォルダ内に /projects というサブフォルダ構造を作成することはできません。AWS Cloud9 IDE ファイルエクスプローラーからこのディレクトリ内のファイルにアクセスすることはできませんが、コマンドラインを使用してアクセスすることはできます。この問題は /projects/projects のファイルパスにのみ影響します。/test/projects や /projects/test などのファイルパスは正常に機能します。これは既知の問題で、AWS Cloud9 IDE ファイルエクスプローラーにのみ影響します。

推奨される解決策： 別のファイル名と構造を使用してください。

(先頭に戻ります)

tmux セッションエラーのために AWS Cloud9 でターミナルウィンドウと対話できない

問題: AWS Cloud9 で新しいターミナルウィンドウを起動しようとすると、必要なコマンドラインインターフェイスを使用できません。コマンドプロンプトがないため、テキストを入力できません。tmux: need UTF-8 locale (LC_CTYPE) や invalid LC_ALL, LC_CTYPE or LANG などのエラーメッセージが返されます。

考えられる原因: ターミナルが応答しないのは、tmux エラーが原因である可能性があります。AWS Cloud9 は、tmux ユーティリティを使用します。これにより、ページがリロードされたり、開発環境に再接続しても、ターミナルに表示される情報は保持されます。

tmux セッションでは、ターミナルウィンドウの表示内容はクライアントによって処理されます。クライアントは、複数のセッションを管理できるサーバーと通信します。サーバーとクライアントは、tmp フォルダにあるソケットを介して通信します。開発環境に tmp フォルダがないか、過度に制限的なアクセス許可が適用されている場合、tmux セッションは実行できません。この場合、IDE のターミナルウィンドウは応答しなくなります。

推奨される解決策: tmux エラーによってターミナルウィンドウと対話できない場合は、別の方法を使用して適切な許可を持つ tmp フォルダを作成する必要があります。これにより、tmux セッションを実行できます。1 つの解決策は、.bash_profile または .bashrc ファイルの LC_CTYPE をエクスポートすることです。別の推奨される解決策としては、AWS Systems Manager を使用してホスト管理の設定をセットアップします。これにより、Amazon EC2 コンソールから該当するインスタンスにアクセスできるようになります。

ホスト管理の設定

  1. まず、AWS Cloud9 コンソールで、環境のインスタンスの名前を見つけます。これを行うには、[Your environments] (自分の環境) ページで該当するパネルを選択し、[View details] (詳細を表示) を選択します。[環境の詳細] ページで [インスタンスに移動] を選択します。Amazon EC2 コンソールで、アクセスする必要があるインスタンスの名前を確認します。

  2. ここで、AWS Systems Manager コンソールに移動し、ナビゲーションペインで [クイックセットアップ] を選択します。

  3. [クイックセットアップ] ページで [作成] を選択します。

  4. [設定タイプ] では、[ホスト管理] に移動し、[登録] を選択します。

  5. [ホスト管理構成オプションのカスタマイズ] の [ターゲット]セクションで、[手動]を選択します。

  6. アクセスする EC2 インスタンスを選択してから、[作成] を選択します。

インスタンスに接続してコマンドを実行する

注記

次の手順は、新しい EC2 コンソール用です。

  1. Amazon EC2 コンソールのナビゲーションペインで、[インスタンス] を選択し、接続するインスタンスを選択します。

  2. [接続]を選択します。

    [Connect] (接続) がアクティブ化されていない場合は、最初にインスタンスを起動する必要があります。

  3. [Connect to your instance] (インスタンスへ接続) ペインの [Connection method] (接続方法) で、[Session Manager]、[Connect] (接続) の順に選択します。

  4. 表示されたターミナルセッションウィンドウで、次のコマンドを入力します。これらのコマンドは、tmux ソケットを使用するための適切なアクセス許可を持つ tmp フォルダを作成します。

    sudo mkdir /tmp
sudo chmod 777 /tmp
sudo rmdir /tmp/tmux-*

(先頭に戻ります)

Amazon EC2

次のセクションでは、Amazon EC2 に関連する問題のトラブルシューティングについて概説します。

Amazon EC2 インスタンスが自動的に更新されない

問題: 最近のシステム更新が、AWS Cloud9 開発環境 に接続する Amazon EC2 インスタンスに自動的に適用されません。

原因: 事前の情報や承認なく自動的に最近の更新を適用すると、コードやAmazon EC2 インスタンスで予期しない動作が発生する可能性があります。

推奨される解決策:

「Amazon EC2 ユーザーガイド」の「インスタンスソフトウェアの更新」にある指示に従って、定期的に Amazon EC2 インスタンスにシステム更新を適用します。

インスタンスでコマンドを実行するには、インスタンスに接続されている環境 からAWS Cloud9 IDE でターミナルセッションを使用できます。

また、ssh や PuTTY などの SSH リモートアクセスユーティリティを使用してインスタンスに接続できます。これを行うには、ローカルコンピュータから、ssh-keygen または PuTTYgen などの SSH キーペア作成ユーティリティを使用します。インスタンスに接続されている環境から AWS Cloud9 IDE を使用して、生成済みのパブリックキーをインスタンスに保存します。次に、生成済みのプライベートキーと共に SSH リモートアクセスユーティリティを使用して、インスタンスにアクセスします。詳細については、ユーティリティのドキュメントを参照してください。

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」を参照してください。

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 がインスタンスに接続しようとすると、その接続はゲートウェイルートテーブルによって Docker ブリッジにルーティングされます。このため、AWS Cloud9 は、開発環境をバックアップする EC2 インスタンスに接続できません。

推奨される解決策: Amazon VPC と Docker が同じ IPv4 CIDR アドレスブロックを使用することで発生する IP アドレスの競合を解決するには、EC2 環境をバッキングするインスタンス用に新しい VPC を設定します。この新しいVPC では、172.17.0.0/16 とは異なる CIDR ブロックを設定します (既存の VPC またはサブネットの IP アドレスの範囲を変更することはできません)。

設定情報については、「Amazon VPC ユーザーガイド」の「VPC とサブネットサイジング」を参照してください。

AWS Cloud9 IDE ファイルエクスプローラーで /home/ec2-user/environment/home/ec2-user/environment というサブフォルダー構造を作成できません。

問題: AWS Cloud9IDE ファイルエクスプローラーで /home/ec2-user/environment/home/ec2-user/environment というサブフォルダ構造を作成すると、このディレクトリを開くことができないというエラーメッセージが表示されます。

考えられる原因: 現在、AWS Cloud9 IDE のファイルシステムを使用して同じ名前のフォルダ内に /home/ec2-user/environment というサブフォルダ構造を作成することはできません。AWS Cloud9 IDE ファイルエクスプローラーからこのディレクトリ内のファイルにアクセスすることはできませんが、コマンドラインを使用してアクセスすることはできます。この問題の影響を受けるのは /home/ec2-user/environment/home/ec2-user/environment のファイルパスだけです。/test/home/ec2-user/environment や /home/ec2-user/environment/test などのファイルパスは機能します。これは既知の問題で、AWS Cloud9 IDE File Explorer にのみ影響します。

推奨される解決策： 別のファイル名と構造を使用してください。

AWS License Manager ライセンス設定が Amazon EC2 インスタンスに関連付けられていると、コンソールから AWS Cloud9 を起動できません

問題: コンソールから AWS Cloud9 EC2 環境を起動しようとすると、エラーメッセージ unable to access your environment が返されます。

考えられる原因: AWS License Manager では、AWS クラウド におけるソフトウェアベンダーライセンスの管理が合理化されます。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 のバージョンに置き換えます。古いロールを削除するだけで置き換えることができます。その後、更新されたロールが自動的に作成されます。

EC2 環境で一部のコマンドやスクリプトを実行できない

問題: AWS Cloud9 EC2 開発環境を開いた後で、一部のタイプのパッケージのインストール、yum や apt などのコマンドの実行、または他の Linux オペレーティングシステムで通常使用されるコマンドを含むスクリプトの実行ができません。

原因: AWS Cloud9 が EC2 環境のために使用する Amazon EC2 インスタンスは Amazon Linux (Red Hat Enterprise Linux (RHEL) ベースのもの) または Ubuntu Server のいずれかに依存しています。

解決策: EC2 環境用に IDE でパッケージをインストールしたり管理したり、コマンドやスクリプトを実行したりする場合は、その環境のインスタンスに応じて、RHEL (Amazon Linux用) または Ubuntu Server と互換性があることを確認してください。

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環境を作成するときに「リソースで perform: ssm:StartSession を実行する権限がないこと」を報告するエラーメッセージ

問題: 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 環境には「リソース (インスタンスプロファイル AWSCloud9SSMInstanceProfile) に対して iam:GetInstanceProfile を実行する権限がありません」と通知されます。

原因: AWS Cloud9 には no-ingress インスタンス用 Systems Manager を活用する EC2 環境の設定パートとして必要な StartSession API を呼び出す許可がおりていません。

推奨される解決策: 必須の AWSCloud9SSMAccessRole サービスロールと AWSCloud9SSMInstanceProfile を AWS Cloud9 環境に追加する方法については、「AWS CLI を使ったSystems Manager のインスタンスプロファイルの管理」を参照してください。

デフォルトの暗号化が 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 Prescriptive Guidance パターンで「デフォルトの暗号化された Amazon EBS ボリュームを使用する AWS Cloud9 を作成する」を参照してください。

EC2-Classic アカウントの VPC エラー:「環境にアクセスできません」

問題: EC2-Classic は、Amazon EC2 のオリジナルリリースで導入されました。2013 年 12 月 4 日より前にセットアップした AWS アカウントを使用している場合、AWS Cloud9 EC2 開発環境の作成時に Amazon VPC とサブネットを設定しないと、エラーが発生する可能性があります。

デフォルトの VPC 設定を受け入れると、Amazon EC2 インスタンスは EC2-Classic ネットワーク内で起動されます。インスタンスはデフォルト VPC のサブネットで起動されません。環境の作成に失敗すると、次のメッセージが表示されます。

環境エラー

環境にアクセスできません

環境の作成はエラーで失敗しました: 次のリソースの作成に失敗しました:［インスタンス］。ユーザーからロールバックがリクエストされました。

EC2 インスタンスがデフォルト VPC に存在しないためにエラーが発生したことを確認できます。開発環境のスタックイベント履歴を表示する場合に AWS CloudFormation を使用します。

  1. AWS CloudFormation コンソールを開きます。詳細については、「AWS CloudFormationコンソールにログイン」を参照してください。

  2. AWS CloudFormation コンソールで、［スタック］を選択します。

  3. ［スタック］ページで、作成に失敗した開発環境の名前を選択します。

  4. [Stack details] (スタックの詳細) ページで [Events] (イベント) タブを選択し、次のエントリをチェックします。

    ステータス: CREATE_FAILED

    ステータスの理由: AssociatePublicIPAddress パラメータは、VPC の起動でのみサポートされています。[...]

原因: AWS Cloud9 開発環境は、特定の VPC 要件を満たす Amazon VPC に関連付けられている必要があります。EC2-Classic が有効なアカウントの場合、EC2 環境の作成 時にデフォルトのネットワーク設定を受け入れると、必要な EC2 インスタンスが VPC 内で起動されません。代わりに、インスタンスは EC2-Classic ネットワーク内で起動されます。

推奨される解決策: EC2-Classic アカウントでは、EC2 環境の作成時に VPC とサブネットを選択する必要があります。［設定の構成］ページの［ネットワーク設定 (アドバンスト)］セクションで、EC2 インスタンスを起動できる VPC とサブネットを選択します。

その他の AWS サービス

次のセクションでは、他の AWS サービスに関連する問題のトラブルシューティングについて概説します。

CodeCatalyst 用のAWS Cloud9 IDE のファイルエクスプローラー内に /projects/projects というサブフォルダー構造を作成できません。

問題: CodeCatalyst の AWS Cloud9 IDE ファイルエクスプローラーで /projects/projects というサブフォルダ構造を作成すると、このディレクトリを開くことができないというエラーメッセージが表示されます。

考えられる原因: 現在、AWS Cloud9 IDE のファイルシステムを使用して同じ名前のフォルダ内に /projects というサブフォルダ構造を作成することはできません。AWS Cloud9 IDE ファイルエクスプローラーからこのディレクトリ内のファイルにアクセスすることはできませんが、コマンドラインを使用してアクセスすることはできます。この問題は /projects/projects のファイルパスにのみ影響します。/test/projects や /projects/test などのファイルパスは正常に機能します。これは既知の問題で、AWS Cloud9 IDE ファイルエクスプローラーにのみ影響します。

推奨される解決策： 別のファイル名と構造を使用してください。

IDE の外部で実行中のアプリケーションを表示できない

問題: IDE 外部のウェブブラウザタブで実行中のアプリケーションを表示しようとすると、そのウェブブラウザタブがエラーを表示するか、空白になります。

考えられる原因:

  • アプリケーションが IDE で実行していません。

  • アプリケーションが 127.0.0.1 または localhost の IP で実行しています。

  • アプリケーションが AWS Cloud9 EC2 開発環境で実行しています。さらに、Amazon EC2 インスタンスに関連付けられているセキュリティグループの 1 つ以上が、アプリケーションで必要とするプロトコル、ポート、または IP アドレスを介したインバウンドトラフィックを許可していません。

  • アプリケーションが AWS クラウドコンピューティングインスタンス (Amazon EC2 インスタンスなど) の AWS Cloud9 SSH 開発環境で実行しています。さらに、対応するインスタンスに関連付けられている仮想プライベートクラウド (VPC) のサブネットのネットワーク ACL が、アプリケーションで必要とするプロトコル、ポート、または IP アドレスを介したインバウンドトラフィックを許可していません。

  • URL に誤りがある。

  • インスタンスのパブリック IP アドレスではなく、アプリケーションプレビュータブの URL がリクエストされている。

  • 127.0.0.1 または localhost の IP を含むアドレスに移動しようとしています。これらの IP は、環境のリソースではなく、ローカルコンピュータのリソースにアクセスしようとします。

  • インスタンスのパブリック IP アドレスが変更されています。

  • ウェブリクエストが、アプリケーションで必要とするプロトコル、ポート、または IP アドレス経由のトラフィックをブロックする仮想プライベートネットワーク (VPN) から送信されています。

  • アプリケーションが SSH 環境で実行しています。ただし、サーバーまたは関連付けられたネットワークが、アプリケーションで必要とするプロトコル、ポート、または IP アドレスを介したインバウンドトラフィックを許可していません。

推奨される解決策:

  • IDE でアプリケーションが実行されていることを確認します。

  • アプリケーションが 127.0.0.1 または localhost の IP を使用して実行されていないことを確認します。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 が開いており、アプリケーションが同じウェブブラウザで実行されている必要があります。

  • 127.0.0.1 または localhost の IP を含むアドレスに移動しようとしているとします。代わりに、実行中のアプリケーションの正しい非ローカルアドレスに移動してみてください。詳細については、「実行中のアプリケーションをインターネット経由で共有する」を参照してください。

  • このアプリケーションが、AWS クラウドコンピューティングインスタンスで実行しているとします。インスタンスのパブリック IP アドレスが変更されているかどうかを確認します。インスタンスのパブリック IP アドレスは、インスタンスが再起動されると変更される可能性があります。この IP アドレスの変更を防ぐには、Elastic IP アドレスを割り当てて、それを実行中のインスタンスに割り当てます。指示については、実行中のアプリケーションをインターネット上で共有するの ステップ 4: 実行中のアプリケーションの URL を共有する を参照してください。

  • ウェブリクエストが VPN から送信されている場合は、その VPN でアプリケーションで必要とするプロトコル、ポート、および IP アドレス経由のトラフィックが許可されていることを確認します。VPN を変更できない場合は、ネットワーク管理者にお問い合わせください。または、可能であれば、別のネットワークからウェブリクエストを行います。

  • アプリケーションが独自のサーバーの SSH 環境で実行しているとします。サーバーおよび関連付けられているネットワークが、アプリケーションで必要とするプロトコル、ポート、または IP アドレスを介したインバウンドトラフィックを許可していることを確認します。サーバーまたは関連付けられているネットワークを変更できない場合は、サーバーまたはネットワークの管理者にお問い合わせください。

  • curl コマンドに URL を続けて実行し、環境のターミナルからアプリケーションの実行を試みます。このコマンドでエラーメッセージが表示される場合は、AWS Cloud9 と関連しない他の問題がある可能性があります。

AWSツールキット実行時のエラー:「環境の inode が不足しています。'fs.inotify.max_user_watches' の制限を増やしてください。」

問題: AWS ツールキットが使用するファイルウォッチャーユーティリティ は、監視できるファイル数の現在の制限またはクォータに近づいています。

原因: AWSツールキット は、ファイルとディレクトリの変更をモニタリングするファイルウォッチャーユーティリティを使用します。ユーティリティが監視できるファイル数が現在のクォータに近づくと、警告メッセージが表示されます。

推奨される解決策:ファイルウォッチャーで処理できるファイルの最大数を増やすには、次の操作を行います。

  1. ターミナルセッションをスタートするには、メニューバーで、［Window (ウィンドウ)］、［New Terminal (新しいターミナル)］を選択します。

  2. 次のコマンドを入力します。

    sudo bash -c 'echo "fs.inotify.max_user_watches=524288" >> /etc/sysctl.conf' && sudo sysctl -p

Lambda ローカル関数実行エラー: SAM Local をインストールできない

問題: ローカルバージョンの AWS Lambda 関数を AWS Cloud9 IDE で実行しようとすると、ダイアログボックスが表示されます。このダイアログボックスに「AWS Cloud9 は SAM Local をインストールできません。IDE でローカルバージョンの AWS Lambda 関数を実行するには、AWS Cloud9 に 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のインストール」の手順を参照してください。

AWS Cloud9 を使用して Amazon EC2 環境を作成しようとしたときの AWS Control Tower エラー:「環境作成は次のエラーで失敗しました: 次のフックが失敗しました: [ControlTower::Guard::Hook]。」

問題: AWS Cloud9と AWS Control Tower のプロアクティブコントロール CT.EC2.PR.8 には互換性の問題があります。このコントロールが有効な場合、AWS Cloud9 で EC2 環境を作成することはできません。

原因: AWS Control Tower では、AssociatePublicIpAddress パラメータが AWS CloudFormation テンプレートに含まれていることが前提となっています。現在、このパラメータは追加できません。

推奨される解決策: AWS Control Tower コンソールからコントロール CT.EC2.PR.8 を無効化し、AWS Cloud9 で環境を再作成します。

デフォルトの暗号化が 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 Prescriptive Guidance パターンで「デフォルトの暗号化された Amazon EBS ボリュームを使用する AWS Cloud9 を作成する」を参照してください。

(先頭に戻ります)

AWS License Manager ライセンス設定が Amazon EC2 インスタンスに関連付けられていると、コンソールから AWS Cloud9 を起動できません

問題: コンソールから AWS Cloud9 EC2 環境を起動しようとすると、エラーメッセージ unable to access your environment が返されます。

考えられる原因: AWS License Manager では、AWS クラウド におけるソフトウェアベンダーライセンスの管理が合理化されます。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 のバージョンに置き換えます。古いロールを削除するだけで置き換えることができます。その後、更新されたロールが自動的に作成されます。

(先頭に戻ります)

アプリケーションプレビュー

次のセクションでは、アプリケーションプレビューに関連する問題のトラブルシューティングについて概説します。

環境を再ロードした後、アプリケーションプレビューを最新の情報に更新する必要がある

問題: アプリケーションプレビュータブを表示する環境を再ロードした後、タブにアプリケーションプレビューが表示されません。

原因: 無限ループを実行できるコードをユーザーが書くことがあります。または、コードによるメモリ消費量が多すぎて、アプリケーションプレビューの実行中に AWS Cloud9 IDE が一時停止または停止することがあります。これを防止するには、環境が再ロードされても、AWS Cloud9 ではアプリケーションプレビュータブを再ロードしません。

解決策: アプリケーションプレビュータブを表示する環境を再ロードした後で、アプリケーションプレビューを表示するには、タブの ［Click to load the page (クリックしてページをロード)］ボタンを選択します。

アプリケーションプレビューまたはファイルプレビュー通知:「サードパーティーの Cookie が無効になっています」

問題: アプリケーションまたはファイルをプレビューしようとすると、次のメッセージと通知が表示されます。「ブラウザでサードパーティーの Cookie が無効になっているため、プレビュー機能が無効になっています。」

原因: AWS Cloud9 IDE を開くのにサードパーティーの Cookie は不要です。ただし、アプリケーションプレビュー機能またはファイルプレビュー機能を使用するには、サードパーティーの Cookie を有効にする必要があります。

解決方法: ウェブブラウザでサードパーティーの Cookie を有効にし、IDE を再読み込みしてから、もう一度プレビューを開いてみてください。

お使いのウェブブラウザでこの精度が許容される場合は、AWS Cloud9 に対してのみサードパーティーの Cookie を有効にできます。そのためには、AWS Cloud9 を使用するサポート対象のドメインに応じて、次のドメインを指定します。

AWS リージョン ドメイン

米国東部(バージニア北部)

*.vfs.cloud9.us-east-1.amazonaws.com

vfs.cloud9.us-east-1.amazonaws.com

米国東部 (オハイオ)

*.vfs.cloud9.us-east-2.amazonaws.com

vfs.cloud9.us-east-2.amazonaws.com

米国西部 (北カリフォルニア)

*.vfs.cloud9.us-west-1.amazonaws.com

vfs.cloud9.us-west-1.amazonaws.com

米国西部 (オレゴン)

*.vfs.cloud9.us-west-2.amazonaws.com

vfs.cloud9.us-west-2.amazonaws.com

アフリカ (ケープタウン)

*.vfs.cloud9.af-south-1.amazonaws.com

vfs.cloud9.af-south-1.amazonaws.com

アジアパシフィック (香港)

*.vfs.cloud9.ap-east-1.amazonaws.com

vfs.cloud9.ap-east-1.amazonaws.com

アジアパシフィック (ムンバイ)

*.vfs.cloud9.ap-south-1.amazonaws.com

vfs.cloud9.ap-south-1.amazonaws.com

アジアパシフィック (大阪)

*.vfs.cloud9.ap-northeast-3.amazonaws.com

vfs.cloud9.ap-northeast-3.amazonaws.com

アジアパシフィック (ソウル)

*.vfs.cloud9.ap-northeast-2.amazonaws.com

vfs.cloud9.ap-northeast-2.amazonaws.com

アジアパシフィック (シンガポール)

*.vfs.cloud9.ap-southeast-1.amazonaws.com

vfs.cloud9.ap-southeast-1.amazonaws.com

アジアパシフィック (シドニー)

*.vfs.cloud9.ap-southeast-2.amazonaws.com

vfs.cloud9.ap-southeast-2.amazonaws.com

アジアパシフィック (東京)

*.vfs.cloud9.ap-northeast-1.amazonaws.com

vfs.cloud9.ap-northeast-1.amazonaws.com

カナダ (中部)

*.vfs.cloud9.ca-central-1.amazonaws.com

vfs.cloud9.ca-central-1.amazonaws.com

欧州 (フランクフルト)

*.vfs.cloud9.eu-central-1.amazonaws.com

vfs.cloud9.eu-central-1.amazonaws.com

欧州 (アイルランド)

*.vfs.cloud9.eu-west-1.amazonaws.com

vfs.cloud9.eu-west-1.amazonaws.com

欧州 (ロンドン)

*.vfs.cloud9.eu-west-2.amazonaws.com

vfs.cloud9.eu-west-2.amazonaws.com

欧州 (ミラノ)

*.vfs.cloud9.eu-south-1.amazonaws.com

vfs.cloud9.eu-south-1.amazonaws.com

ヨーロッパ (パリ)

*.vfs.cloud9.eu-west-3.amazonaws.com

vfs.cloud9.eu-west-3.amazonaws.com

ヨーロッパ (ストックホルム)

*.vfs.cloud9.eu-north-1.amazonaws.com

vfs.cloud9.eu-north-1.amazonaws.com

中東 (バーレーン)

*.vfs.cloud9.me-south-1.amazonaws.com

vfs.cloud9.me-south-1.amazonaws.com

南米 (サンパウロ)

*.vfs.cloud9.sa-east-1.amazonaws.com

vfs.cloud9.sa-east-1.amazonaws.com

アプリケーションプレビュータブにエラーが表示される、または空白になる

問題: IDEのメニューバーで、［プレビュー、実行中のアプリケーションのプレビュー)］または［ツール、プレビュー、実行中のアプリケーションのプレビュー)］を選択して IDEのプレビュータブでアプリケーションを表示しようとすると、タブにエラーが表示されるか、タブが空白になります。

考えられる原因:

  • アプリケーションが IDE で実行していません。　

  • アプリケーションが HTTP を使用して実行していません。

  • アプリケーションが複数のポート経由で実行されている。

  • アプリケーションが 8080、8081、または 8082 以外のポート経由で実行されている。

  • アプリケーションが 127.0.0.1、localhost、または 0.0.0.0 以外の IP で実行されている。

  • ポート (8080、8081、または 8082) がプレビュータブの URL に指定されていません。

  • ネットワークがポート 8080、8081、または 8082 へのインバウンドトラフィックをブロックしています。

  • 127.0.0.1、localhost、または 0.0.0.0 の IP を含むアドレスに移動しようとしています。デフォルトでは、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 で ウェブコンテンツをプレビューできません

問題: AWS Cloud9 EC2 環境でホストされているウェブコンテンツ (WordPress サイトなど) にアクセスしようとしても、IDE プレビューウィンドウにウェブコンテンツが表示されません。

考えられる原因:デフォルトでは、AWS Cloud9 IDE のアプリケーションのプレビュータブでアクセスするすべての Web ページは、自動的に HTTPS プロトコルを使用します。ページの URI が安全でない http プロトコルを備えている場合、https に自動的に置き換えられます。また、手動で https を http に戻す変更を行っても、安全でないコンテンツにアクセスすることはできません。

推奨される解決策: IDE でプレビューしようとしている ウェブサイトから安全ではない HTTP スクリプトまたはコンテンツを削除します。HTTPS の実装に関するガイダンスについては、ウェブサーバーまたはコンテンツ管理システムの指示に従ってください。

ファイルをプレビューすると 499 エラーが返される

問題: AWS Cloud9 IDE でプレビューするファイルに <script> 要素が含まれていて、この要素内に src 属性があり、type 属性が module に設定されていると、499 エラーが発生し、スクリプトは予期どおりに実行しません。

原因: AWS Cloud9 IDE のファイルプレビューのフェッチリクエストでは、認証のためにウェブブラウザから Cookie を送信する必要があります。デフォルトでは、ウェブブラウザは、通常のスクリプトリクエストに対して Cookie を送信します。crossorigin 属性を追加しない限り、モジュールスクリプトリクエストに対しては Cookie を送信しません。

解決策: crossorigin 属性を <script> 要素に追加します。例えば、<script type="module" src="index.js" crossorigin></script> と指定します。次に、変更したファイルを保存し、もう一度プレビューを試みます。

パフォーマンス

次のセクションでは、パフォーマンスに関連する問題のトラブルシューティングについて概説します。

AWS Cloud9 IDE が長時間フリーズする

問題: 起動中および更新の実行時に、AWS Cloud9 IDE ターミナルが長時間フリーズして使用できなくなります。

原因: ご使用の環境に大量のファイルがあり、AWS Cloud9 のファイル監視モジュールによって再帰的に監視されている可能性があります。

推奨される解決策: ファイル監視の深さを減らし (最小値は 1)、大きいフォルダや、ソースコードに関係のないフォルダ (ビルド出力/アーティファクト、サードパーティパッケージ) を、無視するパターンに追加することを検討できます。これを行うには、[設定] > [ユーザー設定] > [ファイル監視] に移動します。これにより、AWS ツールキットの CodeLenses が正しく動作しなくなることに注意してください。

別の解決策としては、検索するファイルの最大数を減らして、ソースコードに関係のない大きなファイルやフォルダを無視することを検討します。これを行うには、[設定] > [プロジェクト設定] > [フォルダを指定して検索] に移動します。これにより、無視したフォルダはファイル検索に表示されなくなることに注意してください。

コンソールの警告:「最小限のコード補完エンジンに切り替えます...」

問題: AWS Cloud9 コンソールで作業している場合 (IDE を開いたり、IDE のウェブページを更新したりする場合など)、「1 つ以上のセッションまたは共同作業者がこの環境でアクティブです。メモリを節約するために最小限のコード補完エンジンに切り替えます。」」というメッセージが表示される。このメッセージと相関して、コード補完の動作が遅いか断続的になっている可能性がある。

原因: コード補完エンジンを実行すると、環境からメモリと CPU サイクルが消費されます。さらに、共同作業者および追加のセッションごとに個別のコード補完エンジンが必要です。特に t2.nano や t2.micro などの小さなサイズのインスタンスで、リソースを過剰に使用しないように、AWS Cloud9 は最小限のコード補完エンジンに切り替わります。

推奨される解決策: 長期間にわたって頻繁に共同作業を行う場合は、EC2 環境の作成時により大きい Amazon EC2 インスタンスを選択します。または、SSH 環境をより容量の大きいインスタンスに接続します。

注記

より大きな Amazon EC2 インスタンスを選択すると、AWS アカウントに追加料金が発生する場合があります。詳細については、「Amazon EC2 の料金」を参照してください。

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

    前述のコマンドは以下の処理を実行します。

    1. /var ディレクトリに swapfile という名前で 512 MB のファイルを作成します。

    2. swapfile ファイルのアクセス権限を所有者のみの読み取り/書き込みに変更します。

    3. swapfile ファイルをスワップファイルとして設定します。

    4. /etc/fstab file に情報を書き込みます。これにより、システムをリブートするたびに、このスワップファイルを使用できます。

    前述のコマンドを実行したら、このスワップファイルをすぐに使用可能にするために、次のコマンドを実行します。

    sudo swapon /var/swapfile

  • 環境をコンピューティングリソースの多いインスタンスまたはサーバーに移動するか、サイズを変更します。Amazon EC2 インスタンスを移動またはサイズ変更するには、「Amazon EBS ボリュームからの AWS Cloud9 IDE の移動」を参照してください。他のインスタンスまたはサーバータイプについては、インスタンスまたはサーバーのドキュメントを参照してください。

AWS Cloud9 IDE にファイルをアップロードできない

問題: ユーザーが AWS Cloud9 IDE に大容量ファイルをアップロードできません。アップロードは失敗しています。

原因: AWS Cloud9 が AWS Cloud9 IDE へのアップロードの速度をスロットリングするため、ファイルのアップロード要求がタイムアウトします。

推奨ソリューション: Amazon S3 にファイルをアップロードし、AWS Cloud9 IDE で CLI を使用して Amazon S3 からファイルを環境にダウンロードします。Amazon S3 にファイルをアップロードする方法の詳細については、「Amazon S3 ユーザーガイド」の「オブジェクトのアップロード」を参照してください。

AWS Cloud9 IDE のダウンロード速度が遅い

問題: ユーザーが AWS Cloud9 IDE からファイルをダウンロードしようとすると、ダウンロード速度が遅くなります。

原因: IDE からローカルファイルシステムにファイルをダウンロードする場合、転送速度は 0.1 メガバイト/秒に制限されます。

推奨ソリューション: ファイルの転送速度を上げるには、AWS Cloud9 IDE の CLI を使用してファイルを Amazon S3 にアップロードし、Amazon S3 からファイルをダウンロードするようにします。

サイトへの接続が安全でないため、IDE で ウェブコンテンツをプレビューできません

問題: AWS Cloud9 EC2 環境でホストされているウェブコンテンツ (WordPress サイトなど) にアクセスしようとしても、IDE プレビューウィンドウにウェブコンテンツが表示されません。

考えられる原因:デフォルトでは、AWS Cloud9 IDE のアプリケーションのプレビュータブでアクセスするすべての Web ページは、自動的に HTTPS プロトコルを使用します。ページの URI が安全でない http プロトコルを備えている場合、https に自動的に置き換えられます。また、手動で https を http に戻す変更を行っても、安全でないコンテンツにアクセスすることはできません。

推奨される解決策: IDE でプレビューしようとしている ウェブサイトから安全ではない HTTP スクリプトまたはコンテンツを削除します。HTTPS の実装に関するガイダンスについては、ウェブサーバーまたはコンテンツ管理システムの指示に従ってください。

(先頭に戻ります)

サードパーティのアプリケーションとサービス

次のセクションでは、サードパーティのアプリケーションとサービスに関連する問題のトラブルシューティングについて概説します。

tmux セッションエラーのために AWS Cloud9 でターミナルウィンドウと対話できない

問題: AWS Cloud9 で新しいターミナルウィンドウを起動しようとすると、必要なコマンドラインインターフェイスを使用できません。コマンドプロンプトがないため、テキストを入力できません。tmux: need UTF-8 locale (LC_CTYPE) や invalid LC_ALL, LC_CTYPE or LANG などのエラーメッセージが返されます。

考えられる原因: ターミナルが応答しないのは、tmux エラーが原因である可能性があります。AWS Cloud9 は、tmux ユーティリティを使用します。これにより、ページがリロードされたり、開発環境に再接続しても、ターミナルに表示される情報は保持されます。

tmux セッションでは、ターミナルウィンドウの表示内容はクライアントによって処理されます。クライアントは、複数のセッションを管理できるサーバーと通信します。サーバーとクライアントは、tmp フォルダにあるソケットを介して通信します。開発環境に tmp フォルダがないか、過度に制限的なアクセス許可が適用されている場合、tmux セッションは実行できません。この場合、IDE のターミナルウィンドウは応答しなくなります。

推奨される解決策: tmux エラーによってターミナルウィンドウと対話できない場合は、別の方法を使用して適切な許可を持つ tmp フォルダを作成する必要があります。これにより、tmux セッションを実行できます。1 つの解決策は、.bash_profile または .bashrc ファイルの LC_CTYPE をエクスポートすることです。別の推奨される解決策としては、AWS Systems Manager を使用してホスト管理の設定をセットアップします。これにより、Amazon EC2 コンソールから該当するインスタンスにアクセスできるようになります。

ホスト管理の設定

  1. まず、AWS Cloud9 コンソールで、環境のインスタンスの名前を見つけます。これを行うには、[Your environments] (自分の環境) ページで該当するパネルを選択し、[View details] (詳細を表示) を選択します。[環境の詳細] ページで [インスタンスに移動] を選択します。Amazon EC2 コンソールで、アクセスする必要があるインスタンスの名前を確認します。

  2. ここで、AWS Systems Manager コンソールに移動し、ナビゲーションペインで [クイックセットアップ] を選択します。

  3. [クイックセットアップ] ページで [作成] を選択します。

  4. [設定タイプ] では、[ホスト管理] に移動し、[登録] を選択します。

  5. [ホスト管理構成オプションのカスタマイズ] の [ターゲット]セクションで、[手動]を選択します。

  6. アクセスする EC2 インスタンスを選択してから、[作成] を選択します。

インスタンスに接続してコマンドを実行する

注記

次の手順は、新しい EC2 コンソール用です。

  1. Amazon EC2 コンソールのナビゲーションペインで、[インスタンス] を選択し、接続するインスタンスを選択します。

  2. [接続]を選択します。

    [Connect] (接続) がアクティブ化されていない場合は、最初にインスタンスを起動する必要があります。

  3. [Connect to your instance] (インスタンスへ接続) ペインの [Connection method] (接続方法) で、[Session Manager]、[Connect] (接続) の順に選択します。

  4. 表示されたターミナルセッションウィンドウで、次のコマンドを入力します。これらのコマンドは、tmux ソケットを使用するための適切なアクセス許可を持つ tmp フォルダを作成します。

    sudo mkdir /tmp
sudo chmod 777 /tmp
sudo rmdir /tmp/tmux-*

古いバージョンの Microsoft Edge ブラウザを使用して IDE をロードすることはできません

問題: Microsoft Edgeウェブブラウザを使って AWS Cloud9 IDE をロードしようとしたときにHTTP403: FORBIDDEN エラーが返ってきます。

考えられる原因: AWS Cloud9 IDE は、一部の古いバージョンのMicrosoft Edge をサポートしていません。

推奨される解決策: ブラウザを更新するには、Microsoft Edge ツールバーの省略記号 (...) ボタンをクリックします。メニューで、[Settings] (設定) を選択して [About Microsoft Edge] ( について) を選択します。アップデートが必要な場合は、自動的にダウンロードされ、インストールされます。

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 にアップグレードします。

  1. AWS Cloud9 ターミナルで次のコマンドを実行して、現在のバージョンのデバッガーを削除します。

    sudo yum -y remove gdb

  2. gdb のアーカイブを取得して展開し、次のコマンドを実行して、展開したファイルが含まれているディレクトリに移動します。

    wget "http://ftp.gnu.org/gnu/gdb/gdb-8.3.tar.gz"
tar xzf gdb-8.3.tar.gz
cd gdb-8.3

  3. 次のコマンドを実行してデバッガーを構築します。これを行うには、次のテキストをコピーして単一のブロックとして貼り付け、Return を押して make を実行します。

    ./configure --prefix=/usr \
            --with-system-readline \
            --with-python=/usr/bin/python3 &&
make

  4. デバッガーをインストールします。

    sudo make -C gdb install

  5. 更新したバージョンのデバッガーがインストールされたことを確認します。

     gdb --version

AWS Cloud9 での PHP ランナーの問題

問題: ユーザーは PHP CLI ランナーターミナルで出力を表示できません。

原因: CLI ランナーを PHP に設定し、デバッガーモードを有効にする必要があります。

推奨される解決策: CLI ランナーを PHP に設定し、デバッガーモードが有効になっていることを確認します。

Node.js に関連する GLIBC エラー

問題: ユーザーが Node.js を実行できず、GLIBC エラーが発生します。エラーメッセージの例を以下に示します。

node: /lib64/libm.so.6: version `GLIBC_2.27' not found (required by node)
node: /lib64/libc.so.6: version `GLIBC_2.28' not found (required by node)

原因: 使用しているインスタンスに関連する Node.js バージョンに問題がある可能性があります。

推奨ソリューション: Node.js を AWS Cloud9 にインストールする方法について、「ステップ 1: 必要なツールをインストールする」セクションを参照してください。