晩酌しながらサーバ管理。 こんな「てきとー管理者」にサーバ預けて、大丈夫?
« 2011年10月 | メイン | 2012年1月 »
2011年11月のアーカイブ
Search
Powered by
Movable Type 4.23-ja
■■■■■免 責■■■■■
このサイトを参考にしたために発生した一切の損害に「てきとー管理者」は一切関知しませんし、補償もしません。 また、本サイトの記述が正しいことも保証しません。
自己責任にてお願いします。
-------------------------
京都の鍵トラブルなら鍵レスキュー 鍵師が、家・金庫・バイク・車等の解錠を始め鍵に関する全般、また防犯設備士からみた防犯診断の上の工事等、安心しておまかせ下さい。24時間対応致します。
岩塩ならクリスタルキンガ 野菜、肉、魚など素材本来の味を引き出します。上質でクセがなく西洋料理はもちろん中華、日本料理にも幅広くお使い頂けます。
本日連続してsignal Bus error (7)の為Apacheが再起動された。
コンテンツは問題無く表示(稼働)しているが、なんか気持ち悪い・・・・
バーチャルドメインのログを見ても、それらしきものは残っていない〜
coreが吐かれていたので、内容を確認したが以前と同じ・・・
(gdb) where
#0 0xb7bca697 in memset () from /lib/libc.so.6
#1 0xb7e987ab in apr_password_validate () from /usr/lib/libaprutil-1.so.0
#2 0xb7843bda in __cxa_finalize () from /etc/httpd/modules/mod_authn_file.so
#3 0xb7f11c6e in __cxa_finalize () from /etc/httpd/modules/mod_auth_basic.so
#4 0xb7f52a0d in ap_run_check_user_id ()
#5 0xb7f53d17 in ap_process_request_internal ()
#6 0xb7f6763b in ap_process_request ()
#7 0xb7f643ef in ?? ()
#8 0xb7f5fa0d in ap_run_process_connection ()
#9 0xb7f5fb0c in ap_process_connection ()
#10 0xb7f6c694 in ?? ()
#11 0xb7f6c9a1 in ?? ()
#12 0xb7f6d3a3 in ap_mpm_run ()
#13 0xb7f43157 in main ()
怪しいのは
mod_auth_basic.so
mod_authn_file.so
ここのところ、phpMyAdminに対しもログが残っている。
phpMyAdminのディレクトリにはベーシック認証を施している。
もしかすると、ベーシック認証を破る攻撃がなされば場合にApacheに不具合が出るのかもしれない。
しかし、ググッてもそれらしき情報が無いため、対策が打てない!
地道に攻撃元IPをブラック化(iptablesで破棄)するしか無いだろうな〜〜
昨晩、下記のログを吐いていた。
[Tue Nov 08 02:08:31 2011] [notice] child pid 27500 exit signal Segmentation fault (11)
しかし、swatchで感知しないw
設定ファイルには watchfor /signal Bus error (7)|signal Segmentation fault (11)/ のように記述しているが。。。。
何か、問題でも??
って事で、watchfor /signal Bus error|signal Segmentation fault/ こんな感じにしてみた。
それと、昔NICが死んでしまう現象があり、その時にお対策を行った事が有ったが、logrotateする際に、古いLogDATAを読み続けてしまう現象が有った。
今回のLogはApacheのログなので、logrotateした後にswatchを再起動するようにして、logrotateした後の新しいLogを参照するように追記してみた。
------------------------------------------------------------------------------------------
/var/log/httpd/*log {
weekly
rotate 13
missingok
notifempty
sharedscripts
postrotate
/sbin/service httpd reload > /dev/null 2>/dev/null || true
endscript
}
------------------------------------------------------------------------------------------
↓ ↓ ↓
------------------------------------------------------------------------------------------
/var/log/httpd/*log {
weekly
rotate 13
missingok
notifempty
sharedscripts
postrotate
/sbin/service httpd reload > /dev/null 2>/dev/null || true
/etc/rc.d/init.d/swatch restart ← ここ
endscript
}
------------------------------------------------------------------------------------------
これで、再度様子みてみようか・・・
その後、何故かわからないが不具合が出ない・・・w
良いことではあるが、せっかくswatchを仕掛けたのに〜〜
ちょっと時間が有ったので、ここ最近追加したドメインの配下を見てみたら、htdocsの下にcoreが吐かれてる。
findで検索すると、他のドメインでもcoreが吐かれてるドメインが有る。
今度、エラーが出てSwatchでApacheが再起動すればメールが飛んでくる。
そのタイミングで、各ドメイン配下にcoreが有るか確認すれば、追求出来るかも!!
※ドメイン配下に有ったcoreは調査する前に削除していたので、次回発生しないと調べられないw
その後、何度かcoreを吐くが、全く原因が掴めず。
このままでは、相当やばい!
って事で、
child pid XXXX exit signal Segmentation fault (11)
とか
child pid XXXX exit signal Bus error (7)
を吐いたら、Apacheを再起動するようにしてみた。
早速、swatchを導入。
通常 /root/.swatchrc に記述するようになっているが、これでは管理しにくいので、 /etc/swatch に設定ファイルを置いて動くようにしてみた。
# mkdir /etc/swatch
# cd /etc/swatch
# vi error_log.conf
----------------------------------------------------------------------------------------
#logfile: /var/log/httpd/error_log
watchfor /signal Bus error (7)|signal Segmentation fault (11)/
echo
mail admin@hogehoge.jp,subject=[Alert] Apache Restart!!
exec /etc/rc.d/init.d/httpd restart
----------------------------------------------------------------------------------------
こんな感じで設定。
swatchは標準で起動スクリプトが用意されていないので、色々調べてこんな感じで作ってみた。
----------------------------------------------------------------------------------------
#!/bin/sh
#
# Swatch
#
# chkconfig: 345 90 35
# description: swatch log monitoring
#
SWATCH=/usr/bin/swatch
LOCKFILE=/var/lock/subsys/swatch
CONFPATH=/etc/swatch
PROCFILE_PATH=/var/run
CONFFILE=*.conf
WORKPATH=/tmp
LOGFILE=/var/log/swatch/swatch.log
. /etc/rc.d/init.d/functions
start()
{
RESULT_CODE=0
if [ -f ${LOCKFILE} ]; then
echo "Swatch is already running."
exit 1
else
touch ${LOCKFILE}
fi
PROCCOUNT=0
for CONFIGFILE in ${CONFPATH}/${CONFFILE}
do
if [ -f ${CONFIGFILE} ]; then
PROCCOUNT=`expr ${PROCCOUNT} + 1`
TARGET_LOG=`head -1 ${CONFIGFILE} | awk 'BEGIN { FS = ":" }; { sub(/([ \t]+$|^[ \t]+)/, "", $2); print $2 }'`
echo -n "Starting swatch: ${TARGET_LOG}: "
daemon ${SWATCH} \
--config-file ${CONFIGFILE} \
--tail-file ${TARGET_LOG} \
--script-dir=${WORKPATH} \
--awk-field-syntax \
--daemon \
--pid-file ${PROCFILE_PATH}/swatch.${PROCCOUNT}.pid \
2>> ${LOGFILE}
RETVAL=$?
echo
if [ ${RETVAL} != 0 ]; then
RESULT_CODE=${RETVAL};
fi
else
RESULT_CODE=7
fi
done
return ${RESULT_CODE}
}
stop()
{
if [ -f ${LOCKFILE} ]; then
for PID in ${PROCFILE_PATH}/swatch.*.pid
do
if [ -f ${PID} ]; then
PID_NUMBER=`cat ${PID}`
echo -n "Shutting down swatch (pid ${PID_NUMBER}): "
killproc -p ${PID}
RETVAL=$?
rm -f ${PID}
echo
else
RETVAL=7
fi
done
fi
rm -f ${LOCKFILE}
rm -f ${WORKPATH}/.swatch_script.*
return ${RETVAL}
}
status()
{
if [ -f ${LOCKFILE} ]; then
echo -n "Swatch (pid :"
for PID in ${PROCFILE_PATH}/swatch.*.pid
do
if [ -f ${PID} ]; then
echo -n " `cat ${PID}`"
fi
done
echo ") is running."
else
echo "Swatch is stopped."
fi
return 0
}
case "$1" in
start)
start
RETVAL=$?
;;
stop)
stop
RETVAL=$?
;;
restart)
stop
start
RETVAL=$?
;;
status)
status
RETVAL=$?
;;
*)
echo "Usage: swatch {start|stop|restart|status}"
exit 1
esac
exit ${RETVAL}
----------------------------------------------------------------------------------------
これを
chkconfig --add swatch
して
service swatch start
して
chkconfig swatch on
こんな感じ!
これで、ちょっと様子見だな。
coreを吐かせても、解決策が分からない。
ましてや、どのドメインが問題なのかも分からない。
coreを吐いた時刻付近のログを調べたいが、150以上のドメインのログを見ていくのは辛い。
そこで、何か良い案は無いかと、知恵を絞ってみた。
grepコマンドで絞れそうな気がしてきた
現在、バーチャルドメインのディレクトリは /home/virtualdomain/ドメイン名 としている。 その配下にlogsを作成し、ドメインごとのログを取っている。
ターゲットは/home/virtualdomain/ドメイン名/logs/error.log だ!
多分こんな感じで行けるのかな?? と、やってみたら簡単に抽出できた。
grep "Wed Nov 02 06:52" /home/virtualdomain/*/logs/error.log
コンソールにはズラズラズラと出るが、分かり難い
そこで、抽出したデータを/tmp/error.dumpに書きだしてみる。
grep "Wed Nov 02 06:52" /home/virtualdomain/*/logs/error.log > /tmp/error.dump
すべてのドメインの error.log から、"Wed Nov 02 06:52"にHITするものが一目で見られるが、それらしきエラーは無い!
時間を変更して抽出しても、怪しい書き込みが無い・・・・
あらら。。。 お手上げだ〜〜〜