前書き
SSMセッションマネージャからログインするとき、デフォルトでは Bourne Shell (sh) で接続することになります。これをbashに変更したくていろいろトライしていたのですが、失敗してしまったので備忘録として残しておきます。
成功例
本来はめちゃくちゃ簡単にできます。
こちらの記事にあるように
１，SSMのセッションマネージャー > 設定 > 編集 を順にクリック
２，対象のshell profileに「/bin/bash」と書く
これだけでOKです。
何を失敗したのか
実は以前にも同様の機能を実装しようとしたことがありました。その際に、実験として/home/ssm-user/.bashrc配下にエイリアス(その時はalias k='kubectl')を記述し、bashを読み込むとエイリアスが使えました。ただし、一度セッションが切れてしまうとそのエイリアスは使えませんでした。
そこで、/home/ssm-userを開くたびに、/home/ssm-user/.bashrcを読み込めばいいのではないか？と思いました。ここまではよかったのですが、ここでなぜか/home/ssm-user/.bashrcにsource ~/.bashrcと書けばよいのではないか？と思ってしまいました。
こんな感じです↓
h-5.2$ cat .bashrc
# .bashrc
alias k='kubectl'
source ~/.bashrc
・・・
今思えば読み込まれてないファイル内で自身のファイルを読み込もうとしている意味不明なコードですが、当時はこれで思った通りのことができる！しかもちょっと前まで意味不明だったシェル触れてる！と浮かれていました。
しかし、当然こんなことを書いても自動で/home/ssm-user/.bashrcは読み込まれませんでした。
そしてそのあとの行動が良くなかったのですが、ほかの作業は特に問題もなく進められたのでこのコードを放置してしまっていました。
数か月後
AWSでのインフラ構築も慣れてきて、自分のタスクに少しゆとりが出てきたころにkubectl completion（kubectlで使うコマンドをタブ補完できるツール）を導入することになりました。
その前段階としてSSMセッションマネージャからログインするときに自動でbashが使えるようにしようとしました。上記の記事を見つけて余裕をましていたところ、こんなエラーが出てきてしまいました。
/bin/bash
sh-5.2$ /bin/bash
Segmentation fault (コアダンプ)
エラーが出てるものの、まあ調べれば何とかなるだろうと思い「SSM セッションマネージャー Segmentation fault (コアダンプ)」などで調べてみるも全くヒットせず。
GPT先生に聞いてみると、メモリアクセスやスタックのオーバーフローなどの可能性があると言われました。
ちょっとよくわからない領域に話が進みだして、これは時間がかかってしまうかも...といういやなセンサーが働き始めました。
実験として、ほかのインスタンスでも同じような状況になるかと思い試してみましたが、問題ありませんでした。また、ssm-userではなくrootで当該インスタンスに入り込んだ時も問題なくbashが使えました。
さらに、メモリの容量も確認してみても余裕がありました。
これは詰んだか...?と思っていた時に数か月前に.bashrcをいじっていたことを思い出しました。そういえばsource ~/.bashrcって書いていたな......
もしかしてループしてる？？だからオーバーフローしてるんじゃない？？と思いつき、この記述を消すとうまくいきました！
ちなみにkubectl completionは以下を参考にすると一瞬で利用できるようになりました
感想
今回の失敗をもとに感じたことを4つ挙げようと思います
うまくいかなかったときは元の状態に戻す
bash自動で読み込めてなさそうやけどほかの機能には影響がないからまあいいや、の精神が数か月後の自分の作業時間を数時間奪ってしまいました。とくに、チーム開発では他者のコードが自分の開発作業に影響してしまうということがあります。実験するのはよいことですが、うまくいかなかったときはきちんと元の状態に戻しておきましょう。
始めてやることはまず検索する
今回の失敗はちょっとLinuxを理解し始めて不用意に.bashrcをいじってしまったのが問題でした。.bashrcをいじる前に「SSMセッションマネージャー bash」などで検索するだけでこの失敗は避けられていたので、今後はまず先人たちの知恵に頼ることにします。
検索しても解決策が出てこないエラーはその前段階で問題があることが多い
今回はSSMセッションマネージャ特有の問題ではなく、~/.bashrcにsource ~/.bashrcと書いてあることが問題でした。まずは検索することが大事ですが、検索してもめぼしい記事がなかった時はもっと前の段階で問題が発生していることが多いです。特に、以前違和感があったもののほったらかしにしていた何かがあるときはそいつが悪さをしている可能性大です。
エラー解消は知識を身につけるチャンス
tech系の記事だけでなく、ChatGPTなどの生成系AIが台頭している現代では手順通りにやればそれなりに動く成果物ができます。ものすごくありがたい反面、なんとなく自分の技術として身についている感覚がないのも事実です。エラー解消は同じ文言のエラーでも状況によって解決策が違うことが多いので、自分が必要なエラー解決手順を探すのに一苦労します。すこし骨が折れることもありますが、その分起きたエラーやその周辺の知識は普通に記事を読むより何倍も体にしみこんでいると思います。エラー解消は成長のチャンスだと思って必死に解消しましょう。自力で解決できるとめちゃくちゃ気持ちいいです。