ど素人がつまづいた、シェルスクリプトの自動起動設定

ことの発端

上司「ぼく君さぁ・・・EC2のインスタンスを平日の営業時間だけ立ち上がってる状態にしてくれない？」

ぼく「！ｗ」

上司「8:30に自動的に立ち上がって、18:30に自動停止させたらいいから。簡単でしょ？」

ぼく「？ｗｗｗ！？ｗ！？！ｗｗｗｗｗ」

上司「じゃ、まかせたね～」

ぼく「・・・ｗ」

概要

・EC2インスタンスを8:30に立ち上げ、18:30に停止させる
・インスタンス立ち上げた際にwebアプリケーション立ち上げのシェルスクリプトを実行する

実装に必要なこと

• Lambdaでインスタンスの自動起動と停止を行うための処理をそれぞれ用意する

  • 丸パクリ⇒　http://dev.classmethod.jp/cloud/aws/lambda_cloudwatch-events_ec2-star-stop-python/

• CloudWatchに8:30と18:30のそれぞれLamda関数を呼び出す処理を用意

  • 参考⇒　http://qiita.com/tiwu_official/items/76b01a9a42070ffb6f68#cloudwatch

• インスタンスの起動とともにアプリケーション起動シェルの自動起動を設定

ど素人がハマったこと

まず、やることはすごく単調で調べればそれらしい内容はいくらでも出てきたので、AWS上ではそこまで問題らしい問題は起こりませんでした。
（CloudWatchの時間設定方法がUTCなため、平日起動時間をミスって設定してしまい、インスタンスを土曜も立ち上がらせたくらい。）

ではどこでハマったかというと、

インスタンス立ち上げた際にwebアプリケーション立ち上げのシェルスクリプトを実行する

こいつ。

失敗1

[ /etc/rc.localに起動させたいシェルを書き込む ]

「自動起動 シェルスクリプト」
これで検索した時に一番初めにでてきたものがrc.localへの記述だったため、すぐ採用。

・結果

おっしゃ動いたやんけ！！！はい余裕～

ぼく「上司さん！できましたわ！」
上司「お、いいね！早いしちゃんと起動して・・・ん？シェル実行された時に生成されるディレクトリ諸々の権限違うくない？」
ぼく「えっ、」
⇒やりなおし

・原因

⇒/etc/rc.localはrootで実行される

---

失敗2

[ root権限で実行されるならスクリプト内にsuコマンド付け足してec2-userに変えたろ！！ ]

sudo -u ec2-user bash << EOF
~~~~~~
EOF


・結果

⇒そもそも/etc/rc.localの記述スクリプトを読んでいない。

・原因

⇒不明。

---

失敗3

[ ユーザーを変更し、起動したいシェルを呼び出すためのスクリプトを作成、/etc/rc.localに記述 ]

・結果

⇒用意したシェルも/etc/rc.localからは呼び出されず。

・原因

⇒不明。このあたりから、suコマンドを用いたシェルは/etc/rc.localで使用できないのではないかと思い始める。泣きそう。

---

解決

上記の失敗1～3までの検証を行っている間に気がつけばAWS上の実装とは別に1人日消費しておりました。
この辺で思うように実装できないことよりも、意味の分からないタスクを寄こした上司を恨むように。

再度「自動起動 シェルスクリプト」で検索。

方法

[ crontab内にOSの起動時、自動起動させるためのコマンド@rebootを記述 ]

@reboot /bin/sh /home/ec2-user/bin/shell.sh
この一行を追加するだけ！！！だけ！！！！返してぼくの1人日！！！！！！

参考⇒ http://nort-wmli.blogspot.jp/2016/02/cron-osreboot-shellsh.html

まとめ

インスタンスの起動時、自動起動させたいシェルスクリプトの実行権限はrootで良い？
YES ⇒　/etc/rc.localに実行シェルを
NO　⇒　crontabの@rebootを使用する。

---

実装する時は策を2つ以上用意しとかないとこういうことになるんですね。
どっと疲れた。。。

ちなみに/etc/rc.localにsuを含んだシェルスクリプトを記述して実行されない理由は分かりませんでした。もしかしたら実行権限がないとか、そういった部分なのかも。