More than 5 years have passed since last update.

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

Last updated at 2017-09-11Posted at 2017-09-11

#ことの発端
上司「ぼく君さぁ・・・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に変えたろ！！ ]

~~~~~~
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人日！！！！！！

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

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

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