Browse Month: March 2009

cobbler 1.4.3 -概要編-

本番サーバをインストールするときに、cobbler を愛用しているけれど、このところ cobbler のバージョンアップが激しく、現在の安定版のバージョンは 1.4.3 になっている。かなり便利な機能がたくさん追加されたので、cobbler の基礎から使い方までをまとめてみる。

概要

cobbler には、便利な機能が盛り沢山。

  • MAC アドレスと IP アドレス、あるいはメニューによる PXE ネットワークブート
  • すでに存在している Linux システムの再インストールやアップグレード
  • 再インストールは、PXE 環境がなくても可能で SSH 経由ごしに再インストールする、Func とも組み合わせることができる
  • ネットワークインストール用の ISO イメージを生成する(PXE は必要ない)
  • キックスタートやイメージによる仮想マシンをインストールすることができる
  • koan と呼ばれているヘルパーツールを使う
  • 仮想化マシンをインストールするためのパラメータ(CPU、メモリ、ディスク容量)は中央管理する
  • 自分専用の PXE ツリーを管理する
  • インストール用の PXE メニューを自動生成する

あと、便利なのは memtest86+ がインストールされていると、自動的に PXE ブートメニューに追加されているのが便利すぎる(※環境によっては自動生成されない場合がある、詳細は別エントリにて)。cobbler を知ってしまうと、自分で PXE ネットワークブート環境を作る気がおこらなくなるほど便利です。

インストールターゲット

  • RHEL, Fedora, CentOS, OpenSuSE, Debian, Ubuntu, Windows

サーバプラットフォーム

  • RHEL 4+, Fedora, Debian, OpenSuSE

BSD 系は対応してないけれど、Linux なら主要なディストリビューションをサポートしています。僕は、どちらも CentOS 5 x86_64 の環境で使ってます。

コンポーネント

cobbler は、次の4つのコンポーネントから構成されているので、ざっと概念だけ説明しておきます。

  • distro
  • インストールするためのディストリビューションイメージ
  • DVD やインターネット上からインポートすることで追加する
  • profile
  • 実際にインストールするプロファイル
  • distro をインポートすると、自動的にデフォルトのプロファイルが生成される
  • インストールするときに使用する kickstart ファイルなどを指定する
  • system
  • ホスト名、IP アドレス、などの特定のホストに依存したプロファイル
  • bonding などもサポートしている
  • オプション扱い、プロファイルの方は必須になっている
  • repo
  • ローカルのリポジトリ
  • yum、apt、rsync、rhn、をサポートしている、breed というオプションで設定する

インストール

インストールは、いたって簡単 DownloadInstructions のページに SRPM とそれぞれのディストリビューション用の RPM があるのでダウンロードする。cobbler RPM をインストールするとき、httpd などいくつか必要なパッケージがあるので、注意する。僕は、SRPM をダウンロードして、cobbler で管理している自分独自のローカル yum リポジトリに入れてからインストールしている。今のところ、cobbler のマスターサーバは一台だけど。

セットアップ

cobbler は、/usr/bin/cobbler コマンドを使う。セットアップまわりは、以前のブログの内容とほとんど変わっていない。init.d スクリプトの問題もなおっている。

次回は、distro、profile、system、repo の作り方とその使い方について解説します。

SCALABLE INTERNET ARCHITECTURES

SCALABLE INTERNET ARCHITECTURES というすこし古い資料になるが、とても興味深かったのでまとめておく。

  • Apache 1.3 のスケーリングについて
  • Keepalive はオフにする … N: 1ユーザごとのページリリース数の平均、T1: 接続を確立する時間、T2: データの統合時間、K: Keepalive 時間、とすると 1 クライアント w/Keepalive あたりのハンドリング時間は T1 + N * T2 + K、1 クライアント w/o Keepalive あたりのハンドリング時間は N * (T1 + T2)、そのうえさらにクライアントが増えると (N – 1) * T1 時間を失うことになる、と書いてあるけれどこのスライドだけだとよく意味が分からない w と o はなんだろうか
  • Apache のスケーリングについて
  • SendBufferSize をあなたの最大ページサイズに設定する
  • リバースプロキシをセットアップする
  • 圧縮転送を設定する(mog_gzip、mod_deflate、PHP の ob_gz_handler、mod_perl の gzip ハンドラ)、PHP の ob_gz_handler は知らなかった
  • 効果は低いが、スタティックコンテンツには Apache を使うのはやめる、prefork マルチプロセスモデルはスタティックコンテンツを配布するためには効率的ではない、選択肢は Apache2(worker MPM のことだと思う)、THTTPDTUX とある、THTTPD はサーバ/インフラ本ではてなが使っているとあったのでいいかもしれない、ベンチマークをとってみる
  • 同じく効果は低いが、ソケットを閉じているハンドリングをオフにする
  • 同じく効果は低いが、ローカルプロキシを設定する(1つのホストに2つの Apache インスタンスを動かして、mod_rewirte, mod_proxy あるいは mod_backend を使う)、Apache インスタンスが大きいので今は二つ同時に起動しないほうがいいと思う、やるなら仮想化する
  • アプリケーションレベルのキャッシング、実際の構成例がのっているウェブサーバの前にキャッシュサーバを挟むという定番の方式とか、NAS にスタティックファイルを入れるとか
  • TYPICAL TWO TIER MODEL, TYPICAL THREE TIER ARCHITECTURE は、基本に2層、3層アーキテクチャ、3層アーキテクチャを図で紹介、基本中の基本なのでみておくといいかも(個人的に3層アーキテクチャをめざして作業中)
  • ローカルのロードバランサーとして、ハードウェアとソフトウェアの選択肢が紹介されている
  • ハードウェアのロードバランサーは高速で安定しているがカスタマイズしにくいコストが高い特殊なスキルが必要になる
  • ログの分散について、syslog、データベース、mog_log_shared の選択肢がある(rsyslog がいいのかなと思う、Apache なら mod_log_spread がいいかなと思ったけれどアップデートされない)

monit で httpd を監視するときの tips

先日のエントリ「monit tips」で、httpd を監視する方法を変更したわけだが、先日ウェブサーバがメモリ不足になって落ちてしまった原因は次のとおりでだった。

  • Passenger を使っていると、かなりの高負荷のとき httpd を restart すると、httpd から fork している ruby のプロセスや ruby のプロセスを制御している ApplicationPool がちゃんと終了しない
  • そのため、ApplicationPool が複数起動して、AppliationPool から ruby のプロセスがたくさん起動した
  • その結果、メモリ不足となった
たしかに、ウェブサーバの負荷が高いときに apache を再起動してみると終了するのに数秒(3〜4秒くらい)かかる。
monit で restart の意味は monit 公式サイトのドキュメントに、次のような記載がある。
RESTART restarts the service and sends an alert. Restart is conducted by first calling the service’s registered stop method and then the service’s start method.
stop method を実行してから start method を実行するとなっている。stop method を実行してから、start method を実行するまでのウェイト時間を指定できないかなとドキュメントを読んでみたが、残念ながらそのような記載はなかった。
仕方がないので、monit 4.10.1 のソースコードで restart を実行する部分に焦点をあてて読んでみた。該当のソースコードは、control.c の次の部分だった。
case ACTION_RESTART:
if(s->type==TYPE_PROCESS && (!s->start || !s->stop)) {
DEBUG(“%s: Start or stop method not defined — process %s\n”, prog, S);
Util_monitorSet(s);
return;
}
LogInfo(“‘%s’ trying to restart\n”, s->name);
do_depend(s, ACTION_STOP);
if(do_stop(s)) {
/* Only start if stop succeeded */
do_start(s);
do_depend(s, ACTION_START);
} else {
/* enable monitoring of this service again to allow the restart retry
* in the next cycle up to timeout limit */
Util_monitorSet(s);
}
break;
do_stop 関数を呼んでから do_start 関数を実行している。それぞれの関数では、単純に設定ファイルで指定したプログラムを spawn 関数を呼んでいるだけだった。restart を指定する場合は、ウェイト時間を設定することができない。
monit は、なかなかきれいな C 言語のプログラムなので、ソースコードが読みやすいと思った。

対策を検討した結果、ヘルスチェックで失敗したときは httpd を終了させる専用のシェルスクリプトを実行するように変更することにした。こうすることで、ヘルスチェックに失敗すると、httpd を終了させて 60秒以内に httpd が起動していないので monit が自動的に httpd を起動してくれる。テストしたところで想定通りの動作をすることで、この設定でいくことにした。

check process httpd with pidfile /var/run/httpd.pid
start program = “/sbin/service httpd restart”
stop program = “/sbin/service httpd stop”
if failed host localhost port 80 protocol http
and request “/healthcheck/heartbeat”
for 3 cycles then exec “/home/hoge/bin/httpd_stop.sh”

この設定だと、/healthcheck/heartbeat で HTTP のステータスコード 200 以外に3回連続でなったとき、/home/hoge/bin/httpd_stop.sh を実行する。わざわざ終了するシェルスクリプトを用意したのは、Passenger のプロセスも含めてちゃんと終了するため。

ちなみに、/home/hoge/bin/httpd_stop.sh は、次のようになっている。

#!/bin/sh

if [ ! -f /var/run/httpd.pid ]; then
echo “httpd is not running”
exit 1
fi

service httpd stop

if [ -f /var/lock/subsys/httpd ]; then
rm -f /var/lock/subsys/httpd
fi

pkill -f ‘merb’
pkill -f ‘ApplicationPool’
ipcs -s | grep apache | awk ‘{print “sudo ipcrm -s “,$2}’ | sh

pkill しているのは、本番環境で使っている merb プロセスを落とすため。ApplicationPool も念のため kill する。最後に Apache のセマフォが使いきっていることがあるので、念のため入れておいた。

この設定で1週間くらい運用しているけれど問題ない様子。これで、メモリ不足になってリモートからサーバに接続できないこともなくなるだろう。

引き続き、httpd のヘルスチェックに失敗する原因を調査して、そもそも httpd が落ちないようにしよう。

MySQL Slave でハードディスクが一杯になったときの挙動

MySQL Slave サーバで、ハードディスクが一杯になったので、そのときの挙動をメモしておく。

ハードディスクが一杯になったときには、/var/log/mysqld.log に次のログが記録される。

InnoDB: Error number 0 means ‘Success’.

InnoDB: Some operating system error numbers are described at

InnoDB: http://dev.mysql.com/doc/refman/5.0/en/operating-system-error-codes.html

090322  2:03:52 [ERROR] /usr/libexec/mysqld: Disk is full writing ‘./relay-bin.000447’ (Errcode: 28). Waiting for someone to free space… Retry in 60 secs

090322  2:50:58 [ERROR] /usr/libexec/mysqld: Disk is full writing ‘binlog/mysql-bin.000152’ (Errcode: 28). Waiting for someone to free space… Retry in 60 secs

090322  2:51:01 [ERROR] /usr/libexec/mysqld: Disk is full writing ‘./relay-bin.000447’ (Errcode: 28). Waiting for someone to free space… Retry in 60 secs

090322  3:00:58 [ERROR] /usr/libexec/mysqld: Disk is full writing ‘binlog/mysql-bin.000152’ (Errcode: 28). Waiting for someone to free space… Retry in 60 secs

090322  3:01:01 [ERROR] /usr/libexec/mysqld: Disk is full writing ‘./relay-bin.000447’ (Errcode: 28). Waiting for someone to free space… Retry in 60 secs

090322  3:10:58 [ERROR] /usr/libexec/mysqld: Disk is full writing ‘binlog/mysql-bin.000152’ (Errcode: 28). Waiting for someone to free space… Retry in 60 secs

090322  3:11:01 [ERROR] /usr/libexec/mysqld: Disk is full writing ‘./relay-bin.0

何回か試して、それでもハードディスクが一杯のままだと binlog に書き込むことをやめるようで、一定時間後上のようなログは記録されない。

その状態で数時間後、Slave の状態を show slave status でみてみると、Slave_IO_State が次の状態になっている。

Slave_IO_State: Queueing master event to the relay log

そして、Seconds_Behind_Master の数字が増え続けている。Slave_IO_Running と Slave_SQL_Running は YES の状態になっているので、Slave 自体は動いているということになる。

ハードディスクの空き容量を確保すると、自動的にリレーログに書き込まれる。

ここから学んだ教訓は、次のとおり。

  • ハードディスクの空き容量の監視は忘れずに設定する
  • 今回ハードディスクを圧迫した原因である、不要な古い大量のログファイルは圧縮して保存するか、削除する
  • ログファイルの集計サーバは、別に用意する

引き続き、がんばろう。

MySQL の wait_timeout と thread_cache_size の関係

Jeremy Zawodny 氏のブログに MySQL, Linux, and Thread Caching という興味深い記事があったので、理解するために自分翻訳してみた。この記事は、今はないけれども rember.yahoo.com で MySQL を使ったときの話のようです。ちなみに MySQL のバージョンは 4.0.4。

わぉ、とても忙しい一週間だった。私は、remeber.yahoo.com の MySQL サーバや関連するものごとに実に何日かを費した。そして、私は1日か2日を休息に使った(睡眠やシャワーなど)

ところで、私はいくつか興味深い発見をした。もっとも驚いたことは MySQL サーバがとても忙しくなったときの Linux 上でのスレッドキャッシングの挙動だ。ポイントは、忙しいときのみということだ。忘れずに。

あなたも分かっていると思うが、われわれがすべてのウェブサーバは一つのマスター DB サーバを持っていて PHP を使って接続しているということだ(これはいつか変えたいと思っているが)。このことは一つのタイルを作ることを含んでいて、一つのタイルがクールになるということだ。加えてマスター DB サーバはとても忙しくなるということだ。

なぜならこのとき 20 台から 45 台のフロントエンドのweb サーバがあって、それぞれのサーバの Apache プロセス数が 70 以上になって接続が必要になったときある問題が発生した。つまりマスター DB サーバは最悪のケースで 45 x 70 = 3,150 の接続をハンドリングすることが必要だった。ほとんどの PHP コードは mysql_pconnect 関数を使って持続的な接続 (persistent connections) を保っていた。

ただ心配するまでもなく、私は wait_timeout をとても低い値である 15 秒に設定していた。これは MySQL は 15 秒異常になったアイドル状態の接続を閉じるということだ。しかし、私はウェブサーバからマスター DB サーバへの接続が拒否されるというレポートを受け取るまで問題に気がつかなかった。なぜか?なぜなら、私はマスター DB サーバの my.cnf で意味のある最大接続数を設定していたからだ。

set-variable = max_conenctions=180

set-variable = max_user_connections=140

このとき、wait_timeout は 600 秒(10分)に設定していた。問題は明かになった。それはたくさんのアイドルなクライアント接続があると、新しいクライアントからの接続はブロックされてしまうことだった。

何をしたのか?

われわれは mysql_pconnect 関数を使うことを止めたが、あなたにも分かるとおり遅延する問題を解決することができなかった。これは本当にくだらなかった。そして私は MySQL 4.0.4 を動作させていたことを分かっていた。私は再起動することなしでサーバの設定をほとんど変更点できるという新しい機能をもっていた。このオンラインマニュアルを読んでみよう。

すばらしい!

次のコマンドを実行することが必要だった。

SET GLOBAL wait_timeout=60;

60 の部分を異なる値に置き換えればよい。

私は15秒のタイムアウトに設定した。

しかし、とても興味深く予期せぬ現象に遭遇した。それは Linux サーバはかなりの高負荷になったとき新しいスレッドを生成しているということだ。これは CPU 時間の量からも明かだった。

CPU 時間はどのくらいか?そのときの SHOW STATUS の出力を見てみると、次の状態だった。

| Threads_cached | 0 |

| Threads_created | 270194 |

| Threads_connected | 46 |

| Threads_running | 28 |

とても悪い現象が起こった。マシンはとても少ないアイドルの CPU 時間を持っていたほとんどの場合、約 5-10%。しかし、本当はそれほど仕事をしていなかった、たぶん 1 秒あたり 40 クエリーほど。私は、すこし戸惑った。しかし、Thread_cached の数字が飛びぬけているのが分かった。それはとても高く増え続けていた。

幸運なことに私は thread_cache の設定を覚えていた。だから、私はさらに詳しく調べてみることにした。

mysql> SELECT @@global.thread_cache_size;

@@thread_cache_size が 0 になっている。

オー、これはいかん。私は my.cnf にスレッドキャッシュの設定をしていなかったのでデフォルト値であった。これは悪かった。それは Apache 1.3 の fork 前の許容量を削除しているようなものだったので忙しいウェブサーバになってしまった。新しいリクエストごとに新しいプロセスをフォークするということは、とても高くついてしまった。

Ugh!

すぐにスレッドキャッシュの設定を次のようにした。

SET GLOBAL thread_cache_size=40;

これは 40 スレッドをキャッシュするという意味になって、われわれはたくさんの仕事をしなくて済むことができた。

別のウィンドウでは私は vmstat 1 コマンドを実行していて動的な変化に注意していた。マシン上のアイドル CPU はすぐに 35-40% から 5-10% になった。

もしたった一つだけ私はすぐに考えることができた。(?)

だから、物語りのモラルはこれだ「もしあなたはたくあんの素早い接続をしていくる忙しいサーバを持っていたらのなら、SHOW STATUS の Threads_created の値が増え続けるのを止めるために十分に高いスレッドキャッシュの設定をしなさい。あなたの CPU にありがとうを言おう。

私は悪く考えたとは感じなかった。われわれはコードを最適しようとしていたが、サーバが動き続けていてとても少ないスリープをしていた。スレッドキャッシングは、本当に我々問題の中で最悪なものではなかった。しかし、それは大きくなる前に解決できた問題になった。

それはとても経験から学べることが多かったことであった。

ということで、MySQL のスレッドキャッシングの設定を見直してみたいと思います。

まず、現在の wait_timeout を見るには、次のコマンドを実行する。

$ mysql -u root -e ‘show variables like “wait_timeout”‘

+—————+——-+

| Variable_name | Value |

+—————+——-+

| wait_timeout  | 28800 |

+—————+——-+

次に、thread_cache_size の値をみてみる。

$ mysql -u root -e ‘select @@thread_cache_size’

+———————+

| @@thread_cache_size |

+———————+

|                 250 |

+———————+

そして、Thread_created の値をみてみる。

$ mysql -u root -e ‘show status’ | grep Threads_created

Threads_created 251

wait_timeout を変更するときには、次のコマンドを実行する。変更したあとは、/etc/my.cnf の mysqld セクションに wait_timeout = 60 の追記を忘れずに。my.cnf に追記しないと再起動したときに戻ってしまうので要注意。

$ mysql -u root -e ‘SET GLOBAL wait_timeout=60’

もし、MySQL に接続して比較的長いバッチ処理をするのなら、あまり短い時間を設定してしまうと接続が切れてしまうので注意する。

次に thread_cache_size を変更するときには、次のコマンドを実行する。thread_cache_size はキャッシュするスレッドサイズの数を指定する。この値は、MySQL のスレッドが使用するメモリ容量を考えて設定する必要がある。MySQL のスレッドスタックサイズは通常 2MB となっている(show variables の thread_stack の値がそれ)。そして、SHOW STATUS コマンドの Threads_connected(現在開いている接続の数)、Threads_created(接続を処理するために生成されたスレッド数)、Threads_running(スリープ状態になっていないスレッド数)、の値を見ながら調整する調整する必要がある。my.cnf に追記する場合は、thread_cache = 10 となるので要注意。

$ mysql -u root -e ‘SET GLOBAL thread_cache_size=10’

あわせて、max_connections を変更するときには、次のコマンドを実行する。max_connections はただ単に増やしてしまうと MySQL がメモリ不足になってしまうので要注意。サーバのリリースをみながら変更していくのが吉。max_connections = thread_cache_size / 3 で設定している例が多いようです。

$ mysql -u root -e ‘SET GLOBAL max_connections=100’

MySQL の show status コマンドで、Threads_created が増えている場合はスレッドキャッシュを設定するといいかもしれません。

Apache がセマフォを使いきる

Apache の負荷が高いときに Apache を service httpd restart として再起動すると、まれに次のようなエラーメッセージを表示して Apache を再起動できないときがある。

[Mon Feb 09 17:54:50 2009] [crit] (28)No space left on device: mod_rewrite: could not create rewrite_log_lock
Configuration Failed

えっ、ハードディスクの空き容量がなくなったと勘違いしそうなエラーメッセージだけれど、これは Apache がセマフォを使いきっているために起こる現象。サーバを再起動すればすぐになおすことができるが、そうそうサーバを再起動できないので、次のコマンドで Apache ユーザが使用しているリソース一覧を表示して確認する。

$  sudo ipcs -s | grep apache

0x00000000 7831552    apache    600        1

(略)

Apache が起動していないのに、Apache ユーザが使用しているリソースがあるのはおかしいので、次のコマンドでリソースを解放する。

$ sudo ipcs -s | grep apache | awk ‘{print “sudo ipcrm -s “,$2}’  | sh

これで、ちゃんと Apache を起動することができる。

puppet 2009年2月開発状況

puppet の作者である Luke Kanies 氏のブログに「Summary of February 2009 Puppet Developer call」がポストされていて、puppet ユーザとするととても興味深いかったので、簡単にまとめておく。

開発の方針について

  • puppet の開発は git に移行している
  • puppet の開発は開発者ごとにリポジトリをもっていて、マージしていく作業が必要とのこと
コア vs モジュール
  • puppet のコア部分は、たくさんのコアではない機能によってはじまっている(例えば、nagios の実装など)
  • nagios のような実装は、別のプラグインリポジトリを使うアイディアがあるが、中央リポジトリで一元管理できないのでよくないと思っているとのこと
ロードマップとリリース状況
  • 0.25 系を2月にリリースしたい(現在はリリースされていない)
  • 現在の安定版である 0.24.7 の重要なバグを修正した 0.24.8 をリリースする予定
Facter の設定と Shadow
  • RailsMachines が Shadow PuppetShadow Facter をリリースした
  • Shadow Puppet は Puppet 用の Ruby DSL、Shadow Facter は Puppet 用の Ruby DSL
0.24.7 は不具合があるみたいだけれど、本番環境に導入してしまった。。。

Google Friend Connect

wordpress の GFC Plugin を使って、このブログの下に Google Friend Connect を追加してみた。以下、セットアップ手順。

  1. Google Friend Connect から新しいサイトを追加する
  2. Google Friend Connect から発行される canvas.html と rpc_reply.html を、Wordpress のインストールディレクトリ以下におく
  3. Google Friend Connect でサイト認証すると発行される siteid をとっておく(URL の siteid パラメータに該当する)
  4. GFC プラグインを有効にして、Friend Connect siteid と URL を必ず入力して、Social Bar オプションを有効にする

これで、Friend Connect の Social Bar が、このブログの下に表示されるようになる。これでしばらく試してみる。

CentOS Tips

このサイトのサーバが別のマシンになったということで関係者の皆様お疲れ様でございました。

今日は、CentOS Tips をいくつか紹介しておく。

[ネットワークインストール編]

  • netinstall.iso を利用して、http or ftp で URL とパスを入力したが、ディレクトリ構成とメディアの組み合わせがおかしいといわれてしまう
  • 原因:メディアが i386 で、指定した URL とパスが x86_64 だった罠、それぞれの iso は違うので注意しよう
  • tzdata やいろいろなパッケージをインストールすることができない
  • 原因:指定したサイトがちゃんとミラーされていないのが原因、ftp.riken.jp はうまくいかなった ftp.kddilabs.jpftp.iij.ad.jp なら大丈夫だった

[OS をインストールしたあと編]

  • yum でアプリケーショングループ単位でのインストール

例えば、まとめて開発ツールをインストールしたいというときに、とても便利。

$  sudo yum -y groupinstall Base “Development Tools”

CentOS 5.2 だと、約 117 個のパッケージ 118MB くらいダウンロードされる。事前に yum-fastestmirror をインストールしておいたほうがよい。

あまり Tips になっていないなぁ。

CentOS をインストールしたあとに、まず行う設定

野良で CentOS をインストールしたあとに、まず行う設定をまとめておく。

  • SSH を公開鍵認証のみにする、SSH のリロードをしてから ssh -v で公開鍵認証のみになっていることを確認する
  • sudo の設定をしてから、root アカウントを無効にする (sudo passwd -l root)
  • 不要なサービスを停止する (下のようなシェルスクリプトを準備しておくと便利)
  • iptables の設定を確認する (iptables の設定は /etc/sysconfig/iptables にあるので雛形を作っておくと便利)
  • 時刻を NTP であわせる
  • ipv6 を使っていないならオフにする
  • ZeroConfiguration をオフにする (/etc/sysconfig/network に NOZEROCONF= yes を追加して、sudo /etc/init.d/network reload)

不要なサービスを停止するシェルスクリプト

#!/bin/sh
function get_cmd() {
echo ‘acpid auditdi autofs avahi-daemon bluetooth cups firstboot gpm hidd ip6t
ables mcstrans mdmonitor netfs nfslock pcscd restorecond rpcgssd rpcidmapd sendm
ail xfs yum-updatesd’
}
for cmd in `get_cmd`; do
/sbin/chkconfig $cmd off
/etc/init.d/$cmd stop
done

kudzu はオフにしない方が懸命。kudzu をオフにしたら、Xen DomU が起動しなかったので要注意。

  • 1
  • 2