手順書どおりなのにコマンドが弾かれたときの対応
手順書どおりに打ったコマンドが弾かれた。原因はパスの違いでしたが、そのとき冷静に対応する先輩を見て感じたことと、No such file or directory・Permission denied などよくあるエラーの考え方をまとめました。
手順書どおりに打ったのに、弾かれた
こんにちは、コマンド学習道場を運営しているこすけです。
今回は、作業中にコマンドが弾かれたときの話。
先日、手順書どおりにコマンドを打っていたら、途中でエラーが出て弾かれてしまったことがありました。
書いてあるとおりに打ったはずなのに、なぜ？
頭の中が一瞬「？」でいっぱいになったのを覚えています。
私はまだ参画して日が浅いこともあり、その場は先輩に代わってもらうことに。
原因はパスが違っていただけ
結論から言うと、原因はパスが違っていただけでした。
手順書に書かれていたパスと、実際の環境のパスが食い違っていたんです。
先輩は原因を確かめたうえで、それまでの作業でミスをしていたわけではないことも確認。
そのまま後続の作業を進めていったんです。
その様子を横で見ていて、すごいなと素直に感じました。
慌てるでもなく、淡々と原因を確かめて、作業を止めるべきか進めてよいかを判断する。
何かあったときに冷静でいられることが、どれだけ大事かを実感した出来事です。
エラーメッセージは「ヒント」
この経験を通して改めて思ったのは、エラーメッセージは怖いものではなく、原因を教えてくれるヒントだということ。
英語のメッセージが出ると、それだけで焦ってしまいがちです。
でも、落ち着いて読んでみると、何が起きたのかがそのまま書いてあることも少なくありません。
まずはエラーメッセージを最後まで読む。
それが冷静に対応するための第一歩だと思っています。
こんなエラーのときは、こう考える
今回はパスの間違いでしたが、作業中に出会いやすいエラーはほかにもいろいろ。
よくあるエラーと、そのとき何を疑うかの例をまとめてみました。
どれも「すぐに打ち直す」前に、まず状況を確かめるのがポイントです。
No such file or directory と出たら
$ cp app.conf /opt/app/conf/
cp: cannot stat 'app.conf': No such file or directory「そのファイル（ディレクトリ）が見つからない」というエラー。
今回の私のケースもこれでした。
疑うのは、今いる場所とパスそのもの。
pwd で現在地を確認し、ls でファイルが本当にあるかを見てみます。
相対パスで書かれた手順は、今いるディレクトリが違うだけで弾かれるので要注意です。
Permission denied と出たら
$ cat /var/log/secure
cat: /var/log/secure: Permission deniedこちらは「権限がない」というエラー。
まずは whoami で、今どのユーザーで作業しているかを確かめます。
手順書では root や別のユーザーで実行する前提なのに、切り替えを忘れていた、というのはよくあるパターン。
ls -l でファイルの所有者や権限も見ておくと、原因がはっきりします。
ここで大事なのは、とりあえず sudo を付けて打ち直さないこと。
手順書にない権限で実行すると、想定外の影響が出ることもあるので、手順書の前提と照らし合わせるのが先です。
command not found と出たら
$ htop
bash: htop: command not found「そのコマンドが見つからない」というエラー。
考えられるのは、コマンド名の打ち間違い、そのサーバーにインストールされていない、あるいはそもそも作業するサーバーを間違えている、といったあたり。
hostname で接続先のサーバーを確かめ、which でコマンドの場所を探してみると切り分けやすくなります。
invalid option と出たら
$ date -v-1d # macOS など BSD 系の書き方
date: invalid option -- 'v'「そのオプションは使えない」というエラー。
手順書が別の OS やバージョンを前提に書かれていると、同じコマンドでもオプションが違うことがあります。
上の例は、macOS などで使う date の書き方を Linux で打ってしまったケース。
cat /etc/os-release で OS を確かめたり、--help や man で使えるオプションを調べたりして、手順書の前提と今の環境が合っているかを確認しましょう。
冷静さは「確認する順番」から
こうして並べてみると、どのエラーでもやっていることは似ています。
エラーを読んで、今の状況（場所・ユーザー・サーバー・環境）を確かめて、手順書の前提と比べる。
そしてもうひとつ大事なのが、それまでの作業に問題がなかったかを確かめること。
先輩がまさにそうしていたように、そこが確認できて初めて、後続の作業を進めてよいかを判断できます。
わからないときに無理に進めず、詰まったら先輩やチームに相談するのも、立派な判断のひとつです。
冷静さは、性格だけで決まるものではないのかもしれません。
確認する順番が頭に入っていれば、何かあったときにも落ち着いて手を動かせるはずです。
違和感にすぐ気づけるようになりたい
今回の件で、私の目標がひとつはっきりしました。
何かあったときに冷静に対応できて、「あれ、おかしいな」という違和感にすぐ気づけるエンジニアになること。
そのためには、普段からコマンドの出力やエラーメッセージをちゃんと読むクセをつけておくのが近道だと思っています。
障害対応の考え方をもっと知りたい方は、トラブルシューティングの記事もあわせてどうぞ。
エラーを実際に出して試してみたい方は、練習用ターミナルで気軽に練習できますよ。