IDEでwsl連携して、アプリケーションを起動したときに、node実行部分で以下のエラーがでる
※適当にマスキングしてます(xxx)
Command 'npm xxx xxx' returned non-zero exit status 127.
> Process 'command 'aws'' finished with non-zero exit value 255
nodeでやっているところはawsとの連携設定なので、nodeから呼び出されたawscli部分で失敗してると推測。awscliのdefaultプロファイルの設定に問題がないか、認証できているかなど切り分けてくが、問題は見当たらない。
最終的に、原因はwslのPATHの設定で、Windows側のnpmが呼ばれていたこと。windows側のnpmが呼ばれた場合、Windows側のawscliが呼ばれていそう。そちらでは認証設定がwslと異なるので、npmが連鎖的に失敗する。
気づいたのは、wsl側で一度npmをアンインストールした状態でwhich npm
を実行したら、Windowsにインストールしたnpmのパスが返ってきたこと(ちなみにnpmはもともと nvmで入れてて、最近asdfに鞍替えした)。
メモってないんだけど、以下のような感じ
$ which npm
/mnt/c/Program Files/node
で、PATHをよくよくながめてみると、たしかにWindows側のパスをサーチする設定が中盤以降に結構入ってる
PATH=/xxx/xxx:/xxx/xxx:/xxx/xxx/:.............
/mnt/c/Windows/system32:/mnt/c/Windows:/mnt/c/Windows/System32/Wbem:
/mnt/c/Windows/System32/WindowsPowerShell/v1.0/:
...............
Windowsの標準的なパス以外にも、Windows側にインストールしたIDEやソフトウェアのパスも結構入ってる。
Windows側のPATH見てみると、なるほどシステム環境変数側のPATHが網羅的にセットされてるみたい。
で、今回の場合は以下のトラブルをたぶん踏んだ
- IDEの実行環境をwslにする
- アプリケーションを起動してnpmが呼び出される
- wslにnpmはインストールされているのだが、パッケージマネージャでインストールしたnpmのパスが認識されていない
- ここは切り分け甘いのだが、asdfやnvnでインストールしたnpmはユーザのホームディレクトリ配下にインストールされ、PATHが通されるが、そのPATHの指定の仕方(.bashrc, profileなど)によってはIDEのwslでセットされないため、見つからない
- PATHのサーチ順に従って、Windoows側のnpmが見つかり、呼び出される
- npmで(おそらくWindows側の)awscliが呼び出されるが、Windows側のawscliでは設定や認証が足りない
- awscliのエラーがでて、npm側にスローされる
- npmのエラーとして記録される
で、対応としては、npmをdegitalocean記載の手順でサーバにインストールした。こうすると/usr/bin/nodeに格納されるので、PATH周りのトラブルを回避しやすいと思う。
ただ、実行環境はasdfで統一したいのと、今後の使い方でWindows側でもnodejs必要になるかもしれないので、wsl周りの安全で独立した実行環境整備したい..
ということで、Windows, WSL両方でアプリケーション実行環境を立てているような使い方をしている場合注意が必要というお話でした