あるサーバーからAWS S3にファイルのアップロード/ダウンロードするPHPのプログラムを作成し検証しているときに、こんな問題が発生しました。
ERROR: /root/.s3cfg: None
ERROR: Configuration file not available.
ERROR: Consider using --configure parameter to create one.
プログラムの内容としては、PHPのshell_execを使ってs3cmdを実行するというもの。まぁ、PHPを使ってAWS SDKを使わずにAWS S3を使うにあたっては普通のプログラムだと思います。もちろんsudoは使わずにapacheユーザーで実行するように作っています。が、エラーの内容を見るとrootユーザーで実行しようとしています。
ハテ？
これには正直悩みました。設定は合っているし、PHPのプログラムの実行ユーザーを調べてもapacheユーザーを返してくる。まぁ、当たり前ですわな。逆にrootユーザーを返されたら恐ろしい話です。巨大なセキュリティホール発生ですから（苦笑）
為す術もなく、やむを得ずhttpdを再起動したらエラーが出なくなった！＼(^O^)／
ハズなんですが、別のサーバーで同じプログラムを展開すると、やっぱりエラーになるとの報告が。httpdを再起動してもダメだと言う。
困った…
で、調べたところ僕が再起動したときはserviceコマンドを使っていたのに対して、別のメンバーは/etc/init.d配下のスクリプトを直接実行している。でもなぁ、両方とも同じだよなぁ。何が違うんだろうと悩むが埒が明かず「/etc/init.d service 違い」で検索すると…
何と、両者では設定される環境変数が大幅に異なるという情報が！そこで示されていたテストスクリプトで試しに両方の差違を探ると、以下のような違いがあることが判明しました。そこで、全てが解決しました。
/etc/init.d配下のスクリプトを使うとUSER=rootという環境変数がセットされ、
serviceを使うとセットされない！
もうお判りですね？
/etc/init.d配下のスクリプトを使うと環境変数USERを参照してrootユーザーで実行しようとしていたわけです。僕が再起動したときはserviceを使っていた（というか、僕は今まで/etc/init.d配下のスクリプトで再起動したことはない）ので環境変数USERがセットされなかったためapacheユーザーで実行されたわけです。Linuxを使って10年ちょっとになりますが、サービスを再起動するときは/etc/init.d配下のスクリプトで再起動している情報が多くて、serviceとinit.dは同じ挙動だと思い込んでいたのですが、全然違うというオチがあったわけです。
ちなみに、情報は「デーモンの起動・終了にはserviceコマンドを利用しよう – インフラエンジニアway – Powered by HEARTBEATS」という記事から得ました。この記事に記載されているテストスクリプトも実行して確かめました。
なお、サーバー自体を再起動したときには/etc/init.d配下のスクリプトが実行されるわけなのですが、serviceコマンドでサービスを再起動したときと同じ挙動になります（当たり前ですが念のため）。
コメント