プロが教える店舗&オフィスのセキュリティ対策術

logrotateでログが整理された後、
httpサーバーが再起動されますが、
その後、WEBサイトが見れなくなります。

/etc/init.d/httpd status で見るとrunning ですが、止まっています。
/etc/init.d/httpd restart すると回復します。



/etc/logrotate.d/httpdの中の再起動部分でおかしくなっています。

/var/log/httpd/*log {
missingok
notifempty
sharedscripts
postrotate
/bin/kill -HUP `cat /var/run/httpd.pid 2>/dev/null` 2> /dev/null || true
endscript
}



/bin/kill のところです。

毎回おかしくなる訳ではなく、たまになると言う頻度、httpd restart で回復します。
どういう対応すれば良いでしょうか。。

A 回答 (6件)

どもです、がるです。



> 「/etc/init.d/httpd」とapachectlではapachectlの方が良いのでしょうか?
これは…難しいですねぇ。
私は、ソースコンパイルでinstallするのと、ディストリビューションの関係などからもともと/etc/rc.d/init.dがないので、起動ファイルのほうでapachectl使うほうなのですが。
RedHatなどのディストリであれば、init.d/httpdを使うことで特に問題が出た、って話しも耳にしないので。
起動、停止、再起動などの手順を一本化できれば、選択は自由であるように思います。

> どちらも入れていないので、statusが機能しません。
> ですので使用を避けていました。
status…一応あるのは知っているのですが、そういえば使ったことがあまりないような(苦笑

> あと、apacheのマニュアルでは緩やかな再起動(USR1、graceful)なども推奨されています。
> /etc/init.d/httpd graceful
> はどうなのでしょうか?
ちと今手元にないので、init.d/httpdが graceful引数を持ってるかわからないのですが、持っていると仮定して。
kill -USER1は、避けたほうが無難です。っていうのも(まぁまず無いのですが)シグナルが変更になる可能性が0ではないので。
一方で、graceful引数は「状況次第では積極的に使う」感じになるかと。
判断基準としては
・セキュリティホールとかアタックに対する緊急対策の場合はrestartまたはstop/start
・性能改善などの緊急ではない場合はgraceful
というのが基準になるかと思います。
このあたりは「常にこっち」ではなく、それぞれの特性に合わせて、って感じになるかと思うです。

以上、何かの参考にでもなれば幸いです。
    • good
    • 0
この回答へのお礼

大変参考になりました。
ありがとうございました。

お礼日時:2006/07/05 09:36

がるです。


killprocに関しては…例えば
http://www.ksknet.net/cat24/killproc.html
をご覧いただけると。

端的にいうと、killは「コマンドの一つ」であり、killprocは「起動スクリプト内で用いられることの多い、定義されたファンクション(定義は大抵 /etc/rc.d/init.d/function )」というのが大きく異なります。

で、本題です(…よね?)。

> アパッチの再起動に関しては
> 直接/bin/kill
> /etc/init.d/httpd
> apachectl
とりあえず、直killはあんまりお勧めいたしません。
私は起動もapachectl使うので停止もapachectlしてますが、起動で/etc/init.d/httpdを使っているのであれば停止も/etc/init.d/httpdを使われたほうがより好ましいように思われます。

で…これは個人的見解なのですが。
実はあんまりrestartって信用してないので(苦笑
もし「起動する、概ね数秒程度の、Webの停滞に問題が無い」ようであれば、
/etc/init.d/httpd stop
/etc/init.d/httpd start
がベストであるように思われます。

次点は
/etc/init.d/httpd restart
です。

/etc/init.d/httpd reload
は「設定ファイルの読み直し」というニュアンスが強いので(実際どうかは不明ですが)、あまり好ましくないように思います。

この回答への補足

> 実はあんまりrestartって信用してないので(苦笑

そういう事もあるのですか、
でもうちの「/etc/init.d/httpd」では

case "$1" in
start)
start
;;
stop)
stop
;;
status)
status $httpd
RETVAL=$?
;;
restart)
stop
start
;;

という風になってますので、「stop&start」と「restart」はほぼ完全に等価です。

「/etc/init.d/httpd」とapachectlではapachectlの方が良いのでしょうか?

うちのapachectlは内部でステータス判定にlinksかlynxの入っている方でアクセスしに行きます。

LYNX="lynx -dump"
if [ -x /usr/bin/links ]; then
LYNX="links -dump"
elif [ -x /usr/bin/lynx ]; then
LYNX="lynx -dump"
else
LYNX="none"
fi

どちらも入れていないので、statusが機能しません。
ですので使用を避けていました。

if [ "$LYNX" = "none" ]; then
echo "The 'links' package is required for this functionality."
exit 8
fi

 :
 略
 :


status)
checklynx
$LYNX $STATUSURL | awk ' /process$/ { print; exit } { print } '
;;


linksは必要なのでしょうか?

apachectlを使えるならそちらを使うに越したことがないのでしょうか?


あと、apacheのマニュアルでは緩やかな再起動(USR1、graceful)なども推奨されています。

/etc/init.d/httpd graceful

はどうなのでしょうか?

補足日時:2006/06/30 17:58
    • good
    • 0

がるです。

いくつか補足っぽいものを。
んっと、killでの記載が「お決まり」との事なのですが。
いくつかの理由から、/etc/rc.dを使ったほうがよりよろしいかと思われます。
とりあえず端的に、各種デーモンは、いくつか起動方法があります。で、起動と終了(またはrestart)を「異なる手段で行う」と、異なる手段での起動/停止方法の同期を人間がいちいちとる必要があるために(かつ大抵は複数ファイルに渡るために)、結構面倒になります。
一方で、startとstopを同一のファイルから行えば、よっぽどのことが無い限り、大抵は「startと整合性の取れたstop」をすることが出来ます。

具体例としては。「つい」間違えて
/bin/kill -HUP `cat /var/run/httpd.pid 2>/dev/null`

/bin/kill `cat /var/run/httpd.pid 2>/dev/null`
とやって停止させてしまうと。起動マクロによっては「pidファイルが残ったままだからまだ残プロセスがあるから起動しない」みたいな、ちょっと面倒な状況もおきえます(で、こんな簡単なことに「焦っているために」気づかないってのが世の常です(苦笑))。

一方で、同一のマクロでstartとstopを行えば、そのマクロでバグが無い限り、そういったトラブルは可能な限り防げるので。

また、技術の世界において「周りと一緒だから多分大丈夫」は厳禁です。理由は述べるまでもないのですが、基本的に「理由はきちんとした理論の上に立脚する」ものだからです。

あと、
> killとkillprocの使い訳が分りません。
> また、一旦終わらせて改めて開始する場合と -HUPで再起動する場合の使い分けもわかりません。
ですが。killproc については、Googleあたりで検索するといくつか出てきます。
killのHUPについては、
http://www.linux.or.jp/JM/html/procps/man1/kill. …
をご覧いただけるとよろしいかと。
通例「restartと概ね等価」な実装をすることが多いのですが、そのあたりは純粋にアプリ依存なので。

この回答への補足

killproc は沢山ヒットしますが、「killとはここが違う」とか「こう使い分ける」とかが理解できるページには到達できませんでした。

アパッチの再起動に関しては
直接/bin/kill
/etc/init.d/httpd
apachectl
があります。
またシグナルに関して
TERM して改めて起動するべきか?
HUP にするべきか?
USR1 にするべきか?

それらの組み合わせから候補を挙げると以下になりますが、ログローテ後のリスタートとしてどれが適切なのか?
判断に困っています。


(1)/bin/killでHUP(一般的?)
/bin/kill -HUP `cat /var/run/httpd.pid 2>/dev/null` 2> /dev/null || true

(2)/etc/init.d/httpdでTERM
/etc/init.d/httpd restart

(3)/etc/init.d/httpdでHUP
/etc/init.d/httpd reload

(4)apachectlでTERM
/usr/sbin/apachectl restart

(5)apachectlでUSR1
/usr/sbin/apachectl graceful


どうしたものでしょうか。

補足日時:2006/06/30 12:35
    • good
    • 0

すべてのプロセスが無くなる前に起動しようとして失敗していた経験があります。

特にSSL使用時。
起動に失敗したときは、httpdプロセスがひとつだけ残っている状態でした。

そのときは「apachectl stop」と「apachctl start」の間に、2秒waitを入れることで解決させました。

この回答への補足

なるほど、そういう場合もあるのですね。
しかし、今回は終了して改めて別プロセスで開始でなく、
プロセスIDに対して再起動をかけている訳ですので微妙に違うのかもしれません。
情報ありがとう御座いました。

補足日時:2006/06/30 00:09
    • good
    • 0

こんばんは。



logrotete.d/httpd の/bin/killの行ですが、
FedoraCore VineLinux CentOS などすべて同じ記述ですし、特に問題ないと思いますが。

私の以前の体験ですが、logrotateの処理中に、/var のパーティションの空き領域が
0%になって、その後のApacheが起動できなかったトラブルがあります。
ディスクの空き領域は十分でしょうか?


>毎回おかしくなる訳ではなく、たまになると言う頻度、httpd restart で回復します。
>どういう対応すれば良いでしょうか。。

いずれにせよ、おかしかった時のログファイルにエラーがはかれていないか確認するのが
問題解決の第一歩ですが、ログを見たことないのでしょうか?

この回答への補足

私はターボ10です。
パーティションの容量は確認しましたが大丈夫でした。
ログも見ましたがこの部分に関して特に自分が分かる範囲での手掛かりはありませんでした。
ログ整理のスクリプトに失敗した事でログを見ないといけないというのは皮肉なものですね。。

補足日時:2006/06/29 23:45
    • good
    • 0

がると申します。


logrotateはあまり使わないのですが(自分でシェル書いたほうが以下略)。
気に掛かるのは、killのところです。
昨今のディストリビューションを使われているのであれば、恐らくはkillコマンドでHUPシグナル送るよりも、丁寧に(というか起動ルートを一本化する意味合いを込めて)
/etc/init.d/httpd stop
/etc/init.d/httpd start
(または /etc/init.d/httpd restart)
としておくほうが整合性が取れると思うのですがどうでしょうか?

直接の原因かは微妙なのですが、ちと気になったので。

この回答への補足

killのところは自分で書いたのではなくディストリビューションの範囲でインストールした結果そうなっているようです。

/bin/kill -HUP `cat /var/run/httpd.pid 2>/dev/null` 2> /dev/null || true

という書き方もお決まりのようです。
いっそこの部分を
/etc/init.d/httpd restart
に書き換えてやろうかと思ったのですが、
お決まりを崩して大丈夫なのかと心配だったので書き込んでみました。

それと疑問なのが
logrotateのなかのhttpの再起動はネット検索でヒットするどれもがkillで行われていますが、/etc/init.d/httpdのなかの起動、停止はkillprocです。

killとkillprocの使い訳が分りません。

また、一旦終わらせて改めて開始する場合と -HUPで再起動する場合の使い分けもわかりません。

この辺をご指導頂けませんでしょうか。

補足日時:2006/06/29 23:32
    • good
    • 0

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!