# /etc/rc.d/init.d/httpd start
httpd を起動中: (98)Address already in use: make_sock: could not bind to address 0.0.0.0:80
no listening sockets available, shutting down
Unable to open logs
                                                           [失敗]

原因は既に他のプロセスがポートを使用していること。
大抵はapacheをバージョン違いで2つインストールしてるとか
skypeを入れてるとポートが被るようです。
#xamppで環境作ったりしてるとハマるみたいですね。
Apacheの重複もないしその他アプリで80番占拠もしてないので・・・
何で80番が占拠されるのかが不明。
とりあえずkillしてしまえば復旧できそうですが、起動しているサービスでポートが
重複している場合はポート変更をちゃんとしないと駄目ですね。

纏めて下記のコマンドkillっと・・・。

/sbin/fuser -kn tcp 80

その後に、Apache起動すれば問題なく起動したのでよしとするか・・・。

原因は推測だけど、プロセスを食い潰してる＋CPUもかなり喰ってたので
正常に停止できてなかったのかなと？

DL厨対策かミラーの公開を止めないとずっと続きそうだな・・・。

CentOS 5.5 リリースノート(英語)で変更点はみてください。

特に問題はでてないので通常の

yum clean all
yum update
shutdown -r now

で問題はないと思います。
※自己責任でねっ♪

2010/06/09追記
CentOS 5.4からのアップデート手順が公開されてるので追記。

yum clean all
yum update glibc\*
yum update yum\* rpm\* pyth\*
yum clean all
yum update mkinitrd nash
yum update selinux\*
yum update
shutdown -r now

念のため・・・
# cat /etc/redhat-release
CentOS release 5.5 (Final)
になってるか確認するといいかも(^^♪

体験版とかのファイルは1ファイル数百MB(最近は500BM以上)が多くなっています。
うちは元々回線が脆弱なのでDLツールを使われると鯖と回線への負荷が大変なことになってます。
ってことで閉め出すのが一番と判断・・・。

※かなり端よった記事になってます。

分割ツールが何故迷惑なのかは・・・某サイト様で掲載されていたのを引用
ダウンロードツールには初期設定で10分割ダウンロードとなっているものが少なくないと思います。
これはファイル全体を10個に分けて、10並列でダウンロードしていると理解しているかも
しれませんが、それは間違いです。

実際には10回より多くのダウンロードが行われていて、数百～数千回のダウンロードを
行うケースが多いのです。
数百～数千のダウンロードが実行されると、それぞれに不正アクセス対策の検査が行われるため、
転送効率が大きく悪化します。

最速でダウンロードを行うことを意図しているのか、トリッキーな挙動が観測されています。
例えば、途中でダウンロードを中断してダウンロードサイズをどんどん小さくしていく場合や、
最初から小さいサイズでダウンロードを多数実行するケースが多く見られます。

20MBのファイルを16KBずつダウンロードすると1,280回になりますし、
200MBのファイルを16KBずつダウンロードすると12,800回にもなります。
(16KBは観測される最小のサイズです)

このように一人が数百～数千回のダウンロードを連続して行うと、アクセスの検査に
10秒前後かかることがあります(ディスクのアクセスの待ち時間よりもはるかに長くなります)。
そして、実際のデータ(16KB)のダウンロードには0.1秒もかかりません。
つまり、分割ダウンロードするため転送速度が百分の一以下に落ちているのです。

転送速度を測りながらサイズを小さく変更するダウンロードツールの場合、
最初は100KB～1MBのサイズで分割するものの、上の状況の通り転送速度が
低めに出るために16KBにサイズを下げてしまいます。
そして、状況をさらに悪化させます。

ダウンロードツールが10分割ダウンロードしたくても、Webサーバーが混雑しているために
全て(10個)は受け付けられない場合がよくあります。
また、サイトによって同時接続数を制限しているところが多数あります。

そのような状況でも、常に10個のダウンロードのリクエストを＜待ち時間無し＞で出し続ける
ダウンロードツールが多いので、処理不可能なリクエストを延々と出し続ける→
サーバーの処理の負荷が上がったままになるという状況になります
(エラーで応答する場合でも処理コストがかかります)。

このために、状況を悪化させる→応答速度が悪くなる→転送速度が落ちるという悪循環になります。

ダウンロードツールでは重複したダウンロードを防ぐ仕組みが用意されていないのです。

例えば、あるサーバーでダウンロード設定をしたものの、なかなかファイルが落ちてこないので、
別のサーバーでダウンロード設定をしたらすぐに落とせた場合、
最初のダウンロード設定を残したままにするケースがあります。
そのため、混雑しているサーバーのリクエストが残ったまま減らない困った状況になります。

分割ダウンロードはサーバー運用コストを本来の10倍以上に引き上げる迷惑行為です。

.htaccessでの締め出し

USER AGENTで有名どころのDLツールをお断り。

<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{HTTP_USER_AGENT} ^.*【USER AGENTの文字列】.*$ [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^.*【USER AGENTの文字列】.*$ [NC]
RewriteRule .*$ http://www.google.co.jp/ [L]
</IfModule>

こんな感じで【USER AGENTの文字列】にHitするものがあればGoogleさんへ
飛ばしてお引き取りしてます。

iptablesでの締め出し

# 1秒間に○回を超える80番へのリクエストはログを記録して破棄
# ※DLTool攻撃対策
iptables -N LOG_DLTOOLDEATH
iptables -A LOG_DLTOOLDEATH -m limit --limit 1/s --limit-burst ○ -j ACCEPT
iptables -A LOG_DLTOOLDEATH -j LOG --log-prefix '[IPTABLES DLTOOLDEATH] : '
iptables -A LOG_DLTOOLDEATH -j DROP
iptables -A INPUT -p tcp --dport 80 -j LOG_DLTOOLDEATH

※「–limit-burst ○ -j ACCEPT」の「○」に回数を数字で指定
例：「–limit-burst 5 -j ACCEPT」
これで1秒間に指定した回数のリクエストを送ってきたら接続を拒否されます。

その他の方法での締め出し

Apacheのモジュールでmod_dosdetector(DOS攻撃対策)やmod_limitipconn
(同時ダウンロード数制限)を導入するのも効果的です。
さらにSWATCH(ログ監視ツール)で監視してFWでカットさせるのもいいかもです。
また、DLツールにはクッキー非対応の物があるのでDL時にクッキーを発行して
あるかないかのチェックをさせるのもいいかもです。

弊害？

iptablesでの締め出しの場合、全パケットを審査するので・・・
表示速度が落ちます(;ﾟロﾟ)
しかしかなりのDLツールを閉め出せます。
効果>利便性 となっていまいます(；´Д｀)

また、SWITCHはあまりシビアな設定にすると・・・・
メモリをスワップまで食いつぶしてくれることになります。
#iptablesでの締め出しを未適用の時。
処理が追いつかないで鯖が死亡とかになります・・・。

その他

これ以上の締め出し設定は利便性がさらに犠牲になるので無理でしょうね。
効果>>>利便性 みたいな感じに？
これ以上する場合は、鯖の分離(Web用とデータ置き場用)にして・・・
ルーターもいいやつに買い換えてとかしないと駄目そうです。

まぁ素人が設定してるのでプロからしたら、なんちゅ～設定してるんじゃ！
ってなるかもでしょうけどね(;ﾟロﾟ)

主な新機能は以下みたいです。
・最新プロセッサのサポート
・仮想化機能の拡張
・Windowsとの相互運用性の向上
他にも数多くの機能追加・修正があるらしいですが・・・。

CentOS 5.5は5月辺りにはリリースされるのかな？
Red Hat Enterprise Linux 6βも4月下旬頃に公開されるとか？
今からいろいろと楽しみです。

ぼちぼちyum updateの自動実行を止めておくかな。

PHP Warning: preg_replace() [function.preg-replace]: Compilation failed: support for \\P, \\p, and \\X has not been compiled at offset 16 in

確認するにはpcretest -Cで確認できます。
# pcretest -C
PCRE version 6.6 06-Feb-2006
Compiled with
UTF-8 support
No Unicode properties support
Newline character is LF
Internal link size = 2
POSIX malloc threshold = 10
Default match limit = 10000000
Default recursion depth limit = 10000000
Match recursion uses stack
「No Unicode properties support」・・・サポートしてませんね(´д｀)
リビルドするのは面倒なのでできものを頂いてきました。
ここからpcre-66-27×86_64.rpmをDLしてインストール。
# wget http://gaarai.com/wp-content/uploads/2009/01/pcre-66-27x86_64.rpm
# rpm -ivh pcre-66-27x86_64.rpm
# /etc/rc.d/init.d/httpd restart

再度pcretest -Cで確認
# pcretest -C
PCRE version 6.6 06-Feb-2006
Compiled with
UTF-8 support
Unicode properties support
Newline character is LF
Internal link size = 2
POSIX malloc threshold = 10
Default match limit = 10000000
Default recursion depth limit = 10000000
Match recursion uses stack
「Unicode properties support」になりました。
PHP Warningも消えたので良しとしよう(笑)

CentOS 5.4 リリースノートで変更点はみてください。

アップデート手順は下記で行いました。

yum clean all
yum update glibc\*
yum update yum\* rpm\* python\*
yum clean all
yum update
yum update kernel\*
shutdown -r now

無事に起動したら・・・再度yum updateを実行してください。
うちでは下のエラーがでました（汁

Transaction Check Error:
  file /usr/share/emacs/site-lisp/psvn.el from install of subversion-1.6.5-0.1.el5.rf.x86_64 conflicts with file from package subversion-1.4.2-4.el5_3.1.i386
  file /usr/share/locale/de/LC_MESSAGES/subversion.mo from install of subversion-1.6.5-0.1.el5.rf.x86_64 conflicts with file from package subversion-1.4.2-4.el5_3.1.i386
  file /usr/share/locale/es/LC_MESSAGES/subversion.mo from install of subversion-1.6.5-0.1.el5.rf.x86_64 conflicts with file from package subversion-1.4.2-4.el5_3.1.i386
  file /usr/share/locale/fr/LC_MESSAGES/subversion.mo from install of subversion-1.6.5-0.1.el5.rf.x86_64 conflicts with file from package subversion-1.4.2-4.el5_3.1.i386
  file /usr/share/locale/it/LC_MESSAGES/subversion.mo from install of subversion-1.6.5-0.1.el5.rf.x86_64 conflicts with file from package subversion-1.4.2-4.el5_3.1.i386
  file /usr/share/locale/ja/LC_MESSAGES/subversion.mo from install of subversion-1.6.5-0.1.el5.rf.x86_64 conflicts with file from package subversion-1.4.2-4.el5_3.1.i386
  file /usr/share/locale/ko/LC_MESSAGES/subversion.mo from install of subversion-1.6.5-0.1.el5.rf.x86_64 conflicts with file from package subversion-1.4.2-4.el5_3.1.i386
  file /usr/share/locale/nb/LC_MESSAGES/subversion.mo from install of subversion-1.6.5-0.1.el5.rf.x86_64 conflicts with file from package subversion-1.4.2-4.el5_3.1.i386
  file /usr/share/locale/pl/LC_MESSAGES/subversion.mo from install of subversion-1.6.5-0.1.el5.rf.x86_64 conflicts with file from package subversion-1.4.2-4.el5_3.1.i386
  file /usr/share/locale/pt_BR/LC_MESSAGES/subversion.mo from install of subversion-1.6.5-0.1.el5.rf.x86_64 conflicts with file from package subversion-1.4.2-4.el5_3.1.i386
  file /usr/share/locale/sv/LC_MESSAGES/subversion.mo from install of subversion-1.6.5-0.1.el5.rf.x86_64 conflicts with file from package subversion-1.4.2-4.el5_3.1.i386
  file /usr/share/locale/zh_CN/LC_MESSAGES/subversion.mo from install of subversion-1.6.5-0.1.el5.rf.x86_64 conflicts with file from package subversion-1.4.2-4.el5_3.1.i386
  file /usr/share/locale/zh_TW/LC_MESSAGES/subversion.mo from install of subversion-1.6.5-0.1.el5.rf.x86_64 conflicts with file from package subversion-1.4.2-4.el5_3.1.i386
  file /usr/share/man/man1/svn.1.gz from install of subversion-1.6.5-0.1.el5.rf.x86_64 conflicts with file from package subversion-1.4.2-4.el5_3.1.i386
  file /usr/share/man/man1/svnadmin.1.gz from install of subversion-1.6.5-0.1.el5.rf.x86_64 conflicts with file from package subversion-1.4.2-4.el5_3.1.i386
  file /usr/share/man/man1/svnlook.1.gz from install of subversion-1.6.5-0.1.el5.rf.x86_64 conflicts with file from package subversion-1.4.2-4.el5_3.1.i386
  file /usr/share/man/man5/svnserve.conf.5.gz from install of subversion-1.6.5-0.1.el5.rf.x86_64 conflicts with file from package subversion-1.4.2-4.el5_3.1.i386
  file /usr/share/man/man8/svnserve.8.gz from install of subversion-1.6.5-0.1.el5.rf.x86_64 conflicts with file from package subversion-1.4.2-4.el5_3.1.i386
  file /usr/share/xemacs/site-packages/lisp/psvn.el from install of subversion-1.6.5-0.1.el5.rf.x86_64 conflicts with file from package subversion-1.4.2-4.el5_3.1.i386

Error Summary
-------------

subversionの64bit版を入れたいが32bit版が入ってるから無理だよ と解釈して・・・

# rpm -e subversion-1.4.2-4.el5_3.1.i386

を実行して32bit版をアンインストール

その後、yum updateをしたら問題なくsubversionの64bit版がインストールできました。
他にもperl-Archive-Zip等がアップデートされてました。

動作確認してみましたが特に問題ないのでアップデート完了です(゜-゜)

念のため・・・
# cat /etc/redhat-release
CentOS release 5.4 (Final)
になってるか確認するといいかも(^^♪

ところがWordPressのページを更新しようと思ったら白紙ページが表示されました。
Apacheのログをみると下記が出力されました。

Allowed memory size of 33554432 bytes exhausted (tried to allocate 17 bytes)
Allowed memory size of 33554432 bytes exhausted (tried to allocate 17 bytes)
Allowed memory size of 33554432 bytes exhausted (tried to allocate 17 bytes)
Allowed memory size of 33554432 bytes exhausted (tried to allocate 17 bytes)
Allowed memory size of 33554432 bytes exhausted (tried to allocate 64 bytes)

PHPのメモリ割り当てが足りなくなった場合に出るエラーですね。
PHP.INIのmemory_limitの設定値を確認すると・・・デフォルトの32MBのままでした（汁
どれくらい割り当てるかは算出するのが面倒だったので
倍の64MBを割り当ててこっそりApacheを再起動。

次にエラーが出る前にきっちりとした値を決めて割り当てしたいともいます。
う～ん。他に抜けてる設定あったかな・・・。

OSによってパスが違うので適用に読み替えてください。

・起動
/etc/rc.d/init.d/httpd start

・停止
/etc/rc.d/init.d/httpd stop

・再起動
/etc/rc.d/init.d/httpd restart

・設定ファイルの再読み込み
/etc/rc.d/init.d/httpd reload

・設定ファイルの書式チェック
/etc/rc.d/init.d/httpd configtest

・状態確認
/etc/rc.d/init.d/httpd status

・プロセスを切断しないで再起動
/etc/rc.d/init.d/httpd graceful

捕捉：
gracefulはプロセスの通信が終わるのを待って、
順次新しい設定を反映したhttpdを起動させる方法。
Webサーバを公開していて、サービスの停止が出来ない場合に便利。

最近再起動よりgracefulを多用している気が(笑)

■MySQLのDBバックアップ

・個別でDBのバックアップを手動で実行するなら下記を実行
※「******」はMySQLのrootのパスワード
※「dbname」はMySQLのデータベース名
# mysqldump -u root -p****** dbname > dbname.sql

復元方法
# mysql -u root -p****** dbname < dbname.sql

・全DBのバックアップを手動で実行するなら下記を実行
# mysqldump -u root -p****** –all-database > alldb.sql

全DBの一括復元方法
# mysql -u root -p****** < alldb.sql

全バックアップファイルから個別のDBを選んで復元する方法
# mysql -u root -p****** dbname < alldb.sql

■DBや各種設定ファイルの自動バックアップ
手動は面倒なので自動バックアップさせましょう。

うちで使ってるのは下記です。

# cat /root/backup.sh

#!/bin/sh
today=`date +%Y%m%d`
oldday=`date --d "7day ago" +%Y%m%d`
target_dir="/sub_disk/backup"
db_dump="/usr/bin/mysqldump"
mysql="/usr/bin/mysql"

function mk_dir(){
 if [ ! -e $target_dir/$today ]
 then
 mkdir -p $target_dir/$today/{DB,ETC}
 fi
}
function etc_backup(){
 etc_list=`ls /etc`
 for i in $etc_list
 do
 tar cfz $target_dir/$today/ETC/$i.tar.gz /etc/$i
 done
}
function db_backup(){
 database_list=`$mysql -u root -p****** -e "show databases"|grep -v Database`
 for i in $database_list
 do
 echo "db backup $i"
 /usr/bin/mysqldump -u root -p****** $i>$target_dir/$today/DB/${i}.DB.sql
 done
}
function rm_dir(){
 if [ -e $target_dir/$oldday ]
 then
 rm -fr $target_dir/$oldday
 fi
}

mk_dir
etc_backup
db_backup
rm_dir

7日間バックアップを保存し、古いものから削除させてます。
取得はDBを個別で吐き出させてるのと、/etc以下をフォルダorファイル単位で固めてバックアップしてます。

このスクリプトを使用する場合は、target_dir/db_dump/mysqlのパス変更と
MySQLのrootのパスワード(******)を2箇所修正してください。
target_dirが保存先となります。

後はbackup.shに実行権つけてcronで毎日任意の時間に実行させればOK。

・復元方法
DBの復元は・・・
# mysql -u root -p****** dbname < dbname.sql

設定ファイルを戻したい場合は、解凍後に移動とかしてください。

適当にサービスあげてるけど・・・CentOS 5.2 → 5.3 へのUpDateはyumで
# yum update glibc\* && yum update
でさっくりとUpdateしました。

*.conf.rpmnewって感じで何個か設定ファイルの新しいのが保存されてたので、旧ファイルと見比べて修正箇所を適用して鯖再起動で完了っと。
とりあえず影響でてないのでこのまま使います～。