[an error occurred while processing this directive]
■ 【ぷろじぇくと ぞうさん】 〜E-Bananaサーバ 構築日記〜

目次に戻る
1日目 2日目 3日目 4日目 5日目 6日目 7日目
8日目 9日目 10日目 11日目 12日目 13日目 14日目
15日目 16日目 17日目 18日目 19日目 20日目 21日目
22日目 23日目 24日目 25日目 26日目 27日目 28日目
29日目 30日目 31日目 32日目 33日目 34日目 35日目
36日目 37日目 38日目 39日目 40日目 41日目 42日目
43日目 44日目 45日目 46日目 47日目 48日目 49日目
50日目 51日目 52日目 53日目 54日目 55日目 56日目
57日目 58日目 59日目 60日目 61日目 62日目 63日目
64日目 65日目 66日目 67日目 68日目 69日目 70日目
71日目 72日目 73日目 74日目 75日目 76日目 77日目
78日目 79日目 80日目 81日目 82日目 83日目 84日目
85日目 86日目 87日目 88日目 89日目 90日目 91日目
92日目 93日目 94日目 95日目 96日目 97日目 98日目
99日目 100日目 101日目 102日目 103日目 104日目 105日目
106日目 107日目 108日目 109日目 110日目 111日目 112日目
113日目 114日目 115日目 116日目 117日目 118日目 119日目
120日目 121日目 122日目 123日目 124日目 125日目 126日目
127日目 128日目 129日目 130日目 131日目 132日目 133日目
134日目 135日目 136日目 137日目 138日目 139日目 140日目
141日目 142日目 143日目 144日目 145日目 146日目 147日目
148日目 149日目 150日目 151日目 152日目 153日目 154日目
155日目 156日目 157日目 158日目 159日目 160日目 161日目
162日目 163日目 164日目 165日目 166日目 167日目 168日目
169日目 170日目 171日目 172日目 173日目 174日目 175日目
176日目 177日目 178日目 179日目 180日目 181日目 182日目
183日目 184日目 185日目 186日目 187日目 188日目 189日目
190日目 191日目 192日目 193日目 194日目 195日目 196日目
197日目 198日目 199日目 200日目 201日目 202日目 203日目
204日目 205日目 206日目 207日目 208日目 209日目 210日目
211日目 212日目 213日目 214日目 215日目 216日目 217日目
218日目 219日目 220日目 221日目 222日目 223日目 224日目
225日目 226日目 227日目 228日目 229日目 230日目 231日目
232日目 233日目 234日目 235日目 236日目 237日目 238日目
239日目 240日目 241日目 242日目 243日目 244日目 245日目
246日目 247日目 248日目 249日目 250日目 251日目 252日目
253日目 254日目 255日目 256日目 257日目 258日目 259日目
260日目 261日目 262日目 263日目 264日目 265日目 266日目
267日目 268日目 269日目 270日目 271日目 272日目 273日目
274日目 275日目 276日目 277日目 278日目 279日目 280日目
281日目 282日目 283日目 284日目 285日目 286日目 287日目
288日目 289日目 290日目 291日目 292日目 293日目 294日目
295日目 296日目 297日目 298日目 299日目 300日目 301日目
302日目 303日目 304日目 305日目 306日目 307日目 308日目
309日目 310日目 311日目 312日目 313日目 314日目 315日目
316日目 317日目 318日目 319日目 320日目 321日目 322日目
323日目 324日目 325日目 326日目 327日目 328日目 329日目
330日目 331日目 332日目 333日目 334日目 335日目 336日目
337日目 338日目 339日目 340日目 341日目 342日目 343日目
344日目 345日目 346日目 347日目 348日目 349日目 350日目
351日目 352日目 353日目 354日目 355日目 356日目 357日目
358日目 359日目 360日目 361日目 362日目 363日目 364日目
第61日目:【障害復旧対応】花子救出大作戦 with Mumumu

どうも、('A`)です。
もうね、何というか・・・先週末は色んな事が起きまして、心も体も休まりません。
先週土曜日未明に発生したPIEのネットワーク障害ですが、David社長やRobertなど
PIEのネットワーク担当者の頑張りで、現在は小康状態になっています。
が、公式発表はもうちょっと時間がかかる見込みです。。。
最終的に問題解決するにはまだ幾つか対応が必要で、早ければ火曜日未明から
行われる予定です。

今回は特定のIP(しかも、本来はどこにも使用されていない未使用のIPアドレス:
一般にBogonと呼ばれています)を使って送信元を偽装し大量(数百メガ)のデータを
一度に送信してくる、という不正なアクセスが先週土曜日未明に発生しました。
その為にPIEのネットワークが麻痺状態になりました。
David社長がルータやスイッチの設定で該当のIPからのアクセスを遮断する様に
修正をおこなったのですが、次々と違うIPで同じ様なアクセスがひっきりなしに来ます。
なので、暫定的な対応ですがBogonフィルタ対策を実施し、Bogonアドレスからの
アクセスが来ても、すぐに遮断される様になりました。

ただ、現在のPIEのネットワークのスピードは通常時よりも遅くなっています。。。
アクセスが普段多いサーバを利用されている人は「なんか重い」「繋がりにくい」と
感じるかもしれません。
この状況は現在のスイッチの設定とBogonフィルタ部分との最終調整をおこなう事で
解決される見通しです。
不便に感じる人もいらっしゃるかもしれませんが、正常化までもう少しお待ち下さい。

そして今回はこの障害の前日から発生していたbanana3000(花子)サーバのダウンと
復旧に関して、ご報告したいと思います。
悪い事は得てして重なるものですが、今回復旧作業の過程で新たな事実が発覚したり、
むむむさんのお力をお借りして幾つかサーバ設定を変更しながら解決する、という事も
あり、他の人たちにも参考にしていただければ、と思いまして。。。
(久しぶりにむむむさんとの「二人羽織」でした。)
それでは、「花子救出大作戦」の始まりですー


[第一節 -花子、七転八倒-]

banana3000(花子)が倒れたのは金曜日(6月20日)の朝でした。
緊急連絡フォームからお知らせを受けて、遠隔リブートをおこなったのですが、
戻ってきません。なので、PIEの技術スタッフにお願いしてシングルユーザモードで
起動してもらい、手動でfsckを実行してもらう様お願いしました。
花子のfsckは通常3〜4時間かかるので、その後、fsckが終わっていたら再起動して
もらう手筈になっていました。。。

んで、金曜日の昼過ぎに「fsckが終わったので、これから再起動するよ」という
連絡をもらって、待機していました。
でも、いつまで経ってもページが表示されません。「('A`)おかしいなあ・・・」と
思ってサーバの中に入ってみると・・・/homeがマウントされていません。
でもfsckプロセスは動いていないので、とりあえすApacheを一時的に停止し、
/homeをマウントしてからApacheを再起動しました。

再起動後15分くらい経ったでしょうか、突然花子に繋がらなくなりました。
また、ダウンしたようです。
何か/homeが正常に動作しない状況に陥っているのかもしれないと思い、
再びPIEの技術スタッフに手動でのfsckをお願いしました。
今度は fstab を参照しての方式ではなく、各パーティションを明示的に指定して
実行してもらう様にお願いしました。

んで、夕方が過ぎ、夜になっても連絡がないので、流石に「('A`)大丈夫か?」と
心配になり現地スタッフに聞いてみると・・・不思議な現象が起きていました。
手動でfsckを実行し、その後再起動を行うと、なぜかApacheが立ち上がりません。
スタッフがもう一度電源ボタンを押してサーバを再起動すると、今度は「手動で
fsckを実行して下さい」のメッセージが出て、途中で止まります。
「何度か繰り返したけど、同じ事の繰り返しになる」と困惑していました。
('A`)にとっても初めての経験です。
これは花子が壊れたのかもしれないと思い、Brian( ^ω^)に診てもらおうと
お願いしたら、、、ネットワークの大障害が発生して、上へ下への大騒ぎ・・・

翌日の土曜日(6月21日) 9:40頃、ネットワーク障害も小康状態になり、改めて
Brian( ^ω^)にコンソール上に何かメッセージが出ていないか確認をお願いして
いた処、、、むむむさん(以下、"む"で省略:顔文字無いんだよなあ・・・)が
オンラインになりました。

"む":「おはようございます。banana3000の状況は、どんな感じですか?」
('A`):「えーと、banana3000ですが、手動で/homeパーティションをfsckして
    リブートすると、なぜかもう一度fsckしろ、と言われて、、、
    現在原因を調べているところです。。。」
"む":「fsck でちゃんと clean になったのに、そう言われるのですか?」
('A`):「もしかすると 何らかの理由で/homeパーティションのfsck自体が
    正常終了していない可能性があります。
    今Brianにコンソール上で何かエラーのメッセージが表示されていないか
    確認してもらっているところです。」
"む":「もし可能なら、KVM(リモートコンソール)をセットアップしてもらって、
    確認してみるとよいです。」
('A`):「えーと、、、花子はKVMが利用できない環境に置かれています。。。
    質問なのですが、fsckを実行中、何らかの理由でfsckの処理そのものが
    続行不能になるようなケースってあるものなのでしょうか?
    (例えば作業時に必要なメモリとかディスクの領域とかが取れない、とか)」
"む":「fsckは、例えばハードウェア的にディスクが壊れたりすれば、もちろん
    修復はできない(続行不能)ですね。
    そういうこともありえますが、通常のオペレーションなら、ディスク領域を
    そこまで使ってしまうことはありえないです。
    で、メモリは仮想記憶使うので、よほどの事が無い限り普通は大丈夫かと。」
('A`):「そうなのか、、、うーん。。。」
"む":「もし手動でのfsckがうまくいっていないなら、一度 /etc/fstab を編集し、
    起動時に/homeをマウントしない形に修正して再起動しましょう。
    そうすれば、SSHでログインできますし、リモートでサーバの状況が把握
    できますから。」

やがて、、、Brian( ^ω^)から「('A`)、変なメッセージが出ていた。KVMが使えないから
写真撮って、メールで送るね。」と返事がきました。送られてきた写真を見ると、、、
fsck_ufs: cannot alloc 11776 bytes for inoinfoの文字が・・・
何かよく判らないけど、メモリか何かで必要な領域を割り当てられなかったので、
fsckの処理ができない、と言っているなあ。。。
このままでは同じ事が繰り返されるので、Brian( ^ω^)に/etc/fstabを修正してもらって、
サーバを立ち上げなおしてもらおう。

('A`):「えーと、やはりfsck処理で失敗していました。。。
    先ほどのメッセージが表示されていました。」
"む":「ふうむ。ちょっと、調べてみます。。。」

こうして花子をなんとかリモートで操作できる様に作業が始まりました。
ちょっと時間がかかるので、その間に('A`)は病院へと向かいました。
もう何もかもボロボロ・・・


[第二節 -呪文炸裂!fsck実行-]

13:00に病院から帰ってくると、banana3000が/homeなしの状態で立ち上がっていました。
"む":「花子上がったようですね。
    ちょっとプロセスを見える様にして頂けると助かります。」
('A`):「(sysctl security.bsd.see_other_uids=1 実行)
    どうでしょう、見えますか?」
"む":「はい。ではまず状況チェックしましょう。
    disklabel -r /dev/da0p1と打ってみて下さい。」
('A`):「あ、こんな情報でてきました。」

banana3000# gpt show /dev/da0p1
start size index contents
0 1 PMBR
1 1 Pri GPT header
2 32 Pri GPT table
34 12695041914 1 GPT part - FreeBSD UFS/UFS2
12695041948 33
banana3000#

"む":「うん。中身は、少なくともラベルは無事か。じゃ、あせることはないですね。
    では次に、read onlyでmountできるか確認しましょう。」
('A`):「(mount -r /dev/da0p1 /home実行)
    マウントできましたー」

banana3000# df
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/ad12s1a 1012974 71426 860512 8% /
devfs 1 1 0 100% /dev
/dev/ad12s1d 2026030 853230 1010718 46% /usr
/dev/ad12s1e 4058062 319166 3414252 9% /var
/dev/md0 89326 8 82172 0% /md
/dev/da0p1 6147826942 2604227980 3051772808 46% /home
banana3000#

"む":「スーパーブロック(mountのための情報)も無事みたいですね。
    なら、怪我は軽いです。少なくともデータのほとんどは無事でしょう。
    これで、あせることはないとわかりました。
    いったん umount しましょう。」
('A`):「(umount /home実行)
    じゃあ、次は /home を書き込み可能状態にしてマウントですね?」
"む":「あー、いやいや、fsck しなきゃだめですよ。
    深呼吸、深呼吸。まずはじっくり。」
('A`):「う、、、すー、はー・・・」
"む":「ではfsckを動かしてみましょう。
    fsck_ufs /dev/da0p1
('A`):「実行しましたー。プロセス番号は 8897 で動いています。」
"む":「じゃ、鼻薬をかがせましょう。
    renice -20 8897
    これでfsckのプロセスはちゃんと最大優先度になります。
    あと変なfindとか上がるといまいちなので、cronを切っておきましょう」
('A`):「(cd /etc/rc.d
    sh cron stop
  実行)」

これで順調に動けばよかったのですが、、、1時間後に突然fsckのプロセスが
消えてしまいました。二人ともちょっとびっくり。

"む":「お、fsck いなくなった?」
('A`):「あ、fsckが・・・コマンド投入していた画面がフリーズしている。。。
    で、プロセスは消えてなくなりました・・・orz」
"む":「あらら、、、。ちょっと、調べてみましょう。mount /dev/da0p1 /home は
    できますか?
    WARNING: /home was not properly dismounted と言われるかどうかが
    ここではポイントです。」
('A`):「弾かれました。こんなメッセージが表示されます。」

    mount: /dev/da0p1: Operation not permitted

"む":「ふむ。。。mount -r /dev/da0p1 /home はできるんですよね?」
('A`):「はい。コマンドを実行したら /home がちゃんと表示されます。」

/dev/da0p1 6147826942 2604227980 3051772808 46% /home

"む":「では、umount してください。fsck に何か起きたか、あるいは一定時間
    idle だと、ターミナルソフトが切ってしまうような仕様なのか、、、」
('A`):「/home をいったんアンマウントしました。」
"む":「ちゃんと syslog(dmesg) に出てますね。fsck は完走していません。

WARNING: R/W mount of /home denied. Filesystem is not clean - run fsck

    とにかく fsck を完走させなけれダメなので、再度、fsck_ufs ですね。
    ちょっと乱暴ですが、大きく壊れていないはずなので、以下の様に
    やってみてください。
    cd /root
    fsck_ufs -y /dev/da0p1 >& fsck.log & 」
('A`):「(なるほど・・・バックグラウンドに動かして、ログ情報を記録するのか。)」

で、この時の会話は午後2時、、、その40分後にまたfsckのプロセスが消えていました。

"む":「fsckいなくなりましたね。ログには何と入っていますか?」
('A`):「あー、午前中にお伝えしたメッセージがはいっています。」

banana3000# cat fsck.log
fsck_ufs: cannot alloc 11776 bytes for inoinfo
** /dev/da0p1
** Last Mounted on /home
** Phase 1 - Check Blocks and Sizes
2129443632 DUP I=530043346
2129443633 DUP I=530043346

(途中 省略)

2122152119 DUP I=530307453
INCORRECT BLOCK COUNT I=578424178 (4 should be 0)
CORRECT? yes
banana3000#

"む":「なるほど、DUP があるんですね。で、テーブルがあふれたんでしょう。
    何らかの。。。ちと、対策考えて見ます。」
('A`):「(テーブルのあふれ・・・?)」
"む":「info = calloc((unsigned)inosused, sizeof(struct inostat));
    if (info == NULL)
        errx(EEXIT, "cannot alloc %u bytes for inoinfo",
          (unsigned)(sizeof(struct inostat) * inosused));

    なるほど、2箇所ありますが、いずれもcalloc が失敗しているのか。」
('A`):「(亜空間に飛ばされてしまった・・・)」
"む":「/usr/src/sbin/fsck_ffs/pass1.c
      void *
      calloc(size_t number, size_t size);

    だから、mallocできてないってことね。」
('A`):「(引き続き亜空間に滞在中・・・)」
"む":「このOS、確か32bit版ですよね?」
('A`):「(やっと帰ってこれた・・・) はい、そうです。 6.2R i386です。」
"む":「/boot/loader.conf をいじって、リブートが必要か・・・
    ちょっとこわいけど、やってみましょ。
('A`):「(えっ・・・ひょっとして"禁術"?)」
"む":「/boot/loader.conf の最後に、以下を足してください。」

    kern.maxdsiz="2G"

('A`):「え、、、えーと、これって最大メモリ使用量を指定するのですか?
    ちなみにbanana3000は2GBのメモリしか搭載されていません。」
"む":「*仮想記憶*だから、大丈夫ですよ。
    この値、デフォルトは確か512Mです。
    でかいプロセスになると、おっこちちゃうわけです。
    まぁ、リミッターってことですね。」
('A`):「loader.conf 修正しました。あと /etc/fstab は /homeをマウントしない
    状態のままにしています。」
"む":「では、花子を再起動しましょう。
    ちなみに2Gより大きな値は、32bitでは*絶対*指定してはいけません。
('A`):「(ブルルッ・・・)花子、リブートしましたっ!」
"む":「了解。この設定は、花子に限り、残しておくとよいでしょう。
    64bitだったら、こんな制限ないんですけどね、、、。
    最近64bitにラブラブな私。」
('A`):「(64bitには痛い目しかあっていない私・・・
    A-Tigerのカーネル再構築でつまづいてもいるし。)
    あ、花子戻ってきました。」
"む":「成功ですね。

%limit
cputime unlimited
filesize unlimited
datasize 2097152 kbytes
stacksize 65536 kbytes
coredumpsize unlimited
memoryuse unlimited
vmemoryuse unlimited
descriptors 14781
memorylocked unlimited
maxproc 7390
sbsize unlimited

    この datasize 2097152 kbytes という値を他のT-Bananaサーバと
    比べてみて下さい。」
('A`):「本当だ。他のサーバは512Mに設定されている・・・」

datasize 524288 kbytes

"む":「じゃ、もう一度fsckを始めましょうか。
    まず、cronを切る。
    cd /etc/rc.d
    sh cron stop
    次に私の方でも結果が見れる様にする為、/tmpに移動してから
    バックグラウンドでfsckを実行。
    cd /tmp
    fsck_ufs -y /dev/da0p1 >& fsck.log &
    最後に優先度を上げる為、fsck_ufs プロセスをrenice -20 してください。」
('A`):「実行しましたー」
"む":「了解です。あとは、待ちということで。」
('A`):「しばらく様子をみます。今まで40分後くらいに終わっちゃっていたので、
    まずはそのラインを超えるか見てみます。」
"む":「お、top でみて、(fsckプロセスの)サイズが 407M ありますね。
    ここが 512M 近くなると、死んでいたんじゃないかなと推測。」
('A`):「あ、そうです。ここが430M位になる処までは気づいていたのですが・・・
    そんなからくりだったか、、、、」
"む":「32bitのOSって、いまとなっては結構足かせが多いんですよね。。。」

で、再びfsckが動き出したのが午後3時10分・・・これから4時間近くかかるのかあ

「呪文」を適用してから、fsckは順調に動きました。そして判ったのです。
「デフォルトのkern.maxdsizじゃ、今の花子のデータ量に対してfsckは正常に
実行できない」事を。。。
topコマンドで見ていたら、どんどんプロセスで使用されているデータサイズが
膨らんでいきました。
(最終的にはこの値、610Mまで膨らみました。。。)

"む":「どうやら、当たりだったのかな?」

PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
961 root 1 -8 -20 520M 520M physrd 1 1:20 2.05% fsck_ufs

('A`):「そうみたいですね。」

あー、そうだよなあ・・・花子は今まではスッカスカだったけど、oyster902が
「大破」した時にログをお引っ越しして、今は半分近く(2.4TB)使われているから。
ブロックのテーブルのサイズもケタ違いになっちゃうんだろうなあ。

・・・あれ?だとすると「花子」だけじゃなくて「花代(banana3001)」も同じ問題が
起きちゃうのか・・・?

[補足]
kern.maxdsiz というパラメータはdatasize (プロセスのデータ使用量)の上限となります。
FreeBSD では、1プロセスあたりのメモリサイズはデフォルトは最大512MBとなっていますが、
今回の様に増やすことができます。(なお、カーネル再構築は必要ありません)。
で、この「使用可能なメモリサイズ」は、limit コマンドで確認できます。
ちなみにkern.maxdsiz の設定値が大きすぎると、システム(OS)を起動できなくなる場合が
あります。
(理論上32bit(i386)なら仮想メモリ空間のザイズは4GBあるはずなのですが、
むむむさんが言う様に2GB以上指定するのは避けた方が良いです。)


[第三節 -復活!そして花子の秘められた"謎"-]

午後3時10分から再開したfsckの処理が午後7時15分に終わりました。
バックグラウンド実行時に指定したログファイルにも
***** FILE SYSTEM MARKED CLEAN *****

***** FILE SYSTEM WAS MODIFIED *****
と記録され、fsckが正常終了した事が確認できました。
"む":「よかった、よかった。ではlost+found ができているかを確認しましょう。」
('A`):「/home をマウントしました。lost+found、ありますね。」
"む":「ではそこの下にファイルが入っているか確認できますか?」
('A`):「データはできています。」

banana3000# ls -l /home/lost+found/
total 8
-rw-r--r-- 1 www users 56 May 29 11:52 #554557670
-rw-r--r-- 1 www users 56 May 29 11:53 #574363433
-rw-r--r-- 1 ch2comi7 users 77 Jun 19 15:13 #605922763
-rw-r--r-- 1 ch2book4 users 77 Jun 19 15:12 #606352767
banana3000#

"む":「なるほど。comic7 のファイルの一部と、book4 のファイルの一部か。
    いずれも77バイトですね。中身、見ていただけますか?
    ちなみに www ユーザのほうは、たぶん、おすすめ2ちゃんねるの
    ファイルですね。あまり気にしなくてよいかと。」
('A`):「データの中身はこんな感じですね。」

banana3000# cat /home/lost+found/#605922763

banana3000# cat /home/lost+found/#606352767

banana3000#

"む":「広告のところですね。あんまり気にしなくておkです。
    ということで、これらのファイルは消しておきましょう。
    (次のfsckの時に干渉する可能性があるので)。
    まず、umount /home して、改めて mount /home してみてください。」
('A`):「(えーと、umountして、次に mount して、と・・・)マウントしました。」

すると、ちょっとした沈黙の後、むむむさんが「ううっ」と唸りました。
え、何かマウントの仕方がまずかったのかなあ・・・ちょっと心配していると、
次のICQのメッセージで「驚くべき事実」が判ったのです。。。

"む":「確認しました・・・('A`)さん、softupdate フラグがオフになってますね。
    これで遅かったのか、、、。アクセスが。」
('A`):「(え、え、、、softupdateって、何?)」
"む":「/dev/da0p1 on /home (ufs, local)
    softupdate フラグをオンにしておきましょう。
    いったん、umount /home してください。」
('A`):「う、了解です。。。」
"む":「softupdate がオフだと、ファイルシステムの破損も起こりやすいです
    いいことは何もないです。。。」
('A`):「ア、アンマウントしましたー」
"む":「では、
    tunefs -n enable /dev/da0p1
    と実行して下さい。」
('A`):「実行しました。こんなメッセージが出ました。。。」

banana3000# tunefs -n enable /dev/da0p1
tunefs: soft updates set
banana3000#

"む":「OKです。では改めて /home をマウントして下さい。」
('A`):「マウントしました。どうでしょう?」
"む":「mount と打てば、自分で確認できますよ。」
('A`):「ああっ、本当だ。」

banana3000# mount
/dev/ad12s1a on / (ufs, local)
devfs on /dev (devfs, local)
/dev/da0p1 on /home (ufs, local, nosuid, soft-updates) ← ココ注目!
/dev/ad12s1d on /usr (ufs, local, soft-updates)
/dev/ad12s1e on /var (ufs, local, soft-updates)
/dev/md0 on /md (ufs, local, soft-updates)
banana3000#

"む":「ちゃんとセットされてますね。これで、花子の不安定とパフォーマンス
    不足は、解消することでしょう。」
('A`):「これって、fstabを直す必要がありますか?」
"む":「その必要はありません。ファイルシステムに直接フラグが書かれるのです。
    umount 状態じゃないと、softupdate のフラグは変えられないです
    では、lost+found の下のごみを掃除しておきましょう。」
('A`):「(cd /home/lost+found rm -f * ・・・)消しましたー!」
"む":「これまで「/homeが遅いなぁ、RAIDのせいかなぁ」と思っていたのは、
    単に設定の問題だった事がわかって、私としてはちょっとうれしいです。」
('A`):「(ぐはっ・・・そうだったのね。。。)」
"む":「これで作業はすべて終了のはずです。リブートすれば、通常の状態に
    戻るはずです。

    では、いきましょう。

    お祈り
    sync
    reboot 」
('A`):「(1、2、3)リブートォォォォ!」
"む":「祈りましょう、祈りましょう、、、。」

やがて、花子が戻ってきました。さっそくSSHでログインしてdfコマンドで/homeが
マウントされているか確認しました。

('A`):「/home マウント確認しました。」

banana3000# df -h
Filesystem Size Used Avail Capacity Mounted on
/dev/ad12s1a 989M 70M 840M 8% /
devfs 1.0K 1.0K 0B 100% /dev
/dev/da0p1 5.7T 2.4T 2.8T 46% /home
/dev/ad12s1d 1.9G 833M 987M 46% /usr
/dev/ad12s1e 3.9G 312M 3.3G 9% /var
/dev/md0 87M 126K 80M 0% /md
banana3000#

"む":「見違えるように、/home が速いですね。成功です。よかった。
    ls -l /home/admin とかやれば、速いのが実感できるはずですよ。」
('A`):「本当だ・・・凄く早くなってる。」

lsコマンドでディレクトリ一覧を表示する時、以前の花子だと表示前に一瞬
「止まって」いたのです。ちょうど「うーん」って踏ん張っている様に・・・
で、その一瞬の間の後に"ドーーーー"と結果が表示されていたのです。
それが、この「施術」を施して以降、スルッと表示される様になったのです。
/homeには200アカウント以上もあるのに、まったくストレスを感じません。
これが「softupdate」の威力なのか・・・

('A`):「この softupdate はもしかして花子や花代だけじゃなく、すべての
    サーバに言える事なのですか?」
"む":「はい、そうですよ。
    でも普通にFreeBSDのインストーラで作ったファイルシステムなら、
    通常、softrupdateフラグは自動でつきますね。(/ 以外)

    一方、花子や花代はOSインストールとは別のタイミングで個別に
    パーティションをフォーマットしていたんだと思うのです。
    で、newfs の時に*オフ*がFreeBSD標準なので(罠ですねぇ)
    newfs -U /dev/da0p1 とか、明示的にやらないとダメだめなんですよ。
    インストーラはちゃんとそのへんのところをケアしてくれるんですが、
    個別でやるときには、注意が必要なわけです。」

大変貴重な経験と知識を頂きました。
(ってかそんな罠仕込まないで下さいよ、FreeBSDの中の人。。。)
今後の事もあるので、大急ぎでBrian( ^ω^)に今回判明したフォーマット時の問題と
解決法を伝えました。

で、同じ問題が花代(banana3001)も持っていたので、花子の作業が終わった後に続けて
修正作業を行ないました。
花代の修正作業においては、「サーバをリブートしないやり方」で対応しました。
やり方は以下の通り。
1) サーバにログインする。
2) スーパーユーザになる前に、/homeパーティションにアクセスしない様に
  cd(チェンジディレクトリ)する。(例えば cd / とか)
3) スーパーユーザモードになる。
4) /homeをアクセスしていると思われるプロセスを止める。
  (a) httpd を止める (httpd -k stop)
  (b) cron を止める (cd /etc/rc.d → sh cron stop)
  (c) MySQL を止める (cd /usr/local/etc/rc.d → mysql.server stop)
  (d) qmail 関連のプロセスを止める。
      cd /var/service
      svc -d smtpd
      svc -d pop3d
      svc -d qmail
5) /home をアンマウントする。 (umount /home)
6) softupdate をオンにする。 (tunefs -n enable /dev/da0p1)
7) /home をマウントする。 (mount /home)
8) 4)で止めていたプロセスを再起動する。
  (a) qmail 関連のプロセスを起動する。
      cd /var/service
      svc -u smtpd
      svc -u pop3d
      svc -u qmail
  (b) MySQL を再起動する (cd /usr/local/etc/rc.d → mysql.server start)
  (c) cron を起動する (cd /etc/rc.d → sh cron start)
  (d) httpd を起動する (httpd -k start -DSSL)
9) mount と実行して、 /home の処が以下の表示になっているか確認する。
  (変更前)
   /dev/da0p1 on /home (ufs, local, nosuid)
  (変更後)
   /dev/da0p1 on /home (ufs, local, nosuid, soft-updates)
10) /boot/loader.conf に以下の行を追加する。
    kern.maxdsiz="2G"

上記手順で、 2) は重要です
cd /tmp とか cd / とかをしておかないと、 /home を掴んだ状態のままになるんです。
何故か・・・それはSSHではroot以外のアカウントでログインするのですが、ログイン時に
最初 /homeに割り当てられている自分自身のディレクトリ(例えば /home/admin とか)が
カレントディレクトリとしてポイントされるからです。
(この時点で結果として /home を掴んでしまうのです。)
今回ここで一度失敗して、むむむさんを巻き込んで右往左往してしまいました。。。


で、全ての作業が終わったのが午後8時10分。
むむむさん、ありがとうございました。花子と共に('A`)も助かりました。
(もっとも、新しいDNSパッケージ(PowerDNSとか)のススメとかも受けまして、、、
また宿題ができたかな?ちょっと挑戦してみようかな?余裕があればですが・・・)
今回の日記は長編になりまして、「読みづらいなあ」と思われるかもしれませんが、
少しでも「当時の様子(二人羽織の感じ)」がイメージ化できる様、当時交わされた
会話をできるだけ再現してみました。

ユーザの皆さんには長期間ご不便をおかけして申し訳ございませんでした。
花子も花代も封印されていた「本来の力」を発揮して、今日も元気に動いています。
もう大丈夫です。ご安心下さい。


・・・って、あー、ロードバランサーの説明がまだでしたね。。。
ちょっとこれ以上書くと「長編」を通り越してしまうので、こちらは次回という事で、
お楽しみに
それでは、また


60日目に戻る。   62日目に続く。

目次に戻る
1日目 2日目 3日目 4日目 5日目 6日目 7日目
8日目 9日目 10日目 11日目 12日目 13日目 14日目
15日目 16日目 17日目 18日目 19日目 20日目 21日目
22日目 23日目 24日目 25日目 26日目 27日目 28日目
29日目 30日目 31日目 32日目 33日目 34日目 35日目
36日目 37日目 38日目 39日目 40日目 41日目 42日目
43日目 44日目 45日目 46日目 47日目 48日目 49日目
50日目 51日目 52日目 53日目 54日目 55日目 56日目
57日目 58日目 59日目 60日目 61日目 62日目 63日目
64日目 65日目 66日目 67日目 68日目 69日目 70日目
71日目 72日目 73日目 74日目 75日目 76日目 77日目
78日目 79日目 80日目 81日目 82日目 83日目 84日目
85日目 86日目 87日目 88日目 89日目 90日目 91日目
92日目 93日目 94日目 95日目 96日目 97日目 98日目
99日目 100日目 101日目 102日目 103日目 104日目 105日目
106日目 107日目 108日目 109日目 110日目 111日目 112日目
113日目 114日目 115日目 116日目 117日目 118日目 119日目
120日目 121日目 122日目 123日目 124日目 125日目 126日目
127日目 128日目 129日目 130日目 131日目 132日目 133日目
134日目 135日目 136日目 137日目 138日目 139日目 140日目
141日目 142日目 143日目 144日目 145日目 146日目 147日目
148日目 149日目 150日目 151日目 152日目 153日目 154日目
155日目 156日目 157日目 158日目 159日目 160日目 161日目
162日目 163日目 164日目 165日目 166日目 167日目 168日目
169日目 170日目 171日目 172日目 173日目 174日目 175日目
176日目 177日目 178日目 179日目 180日目 181日目 182日目
183日目 184日目 185日目 186日目 187日目 188日目 189日目
190日目 191日目 192日目 193日目 194日目 195日目 196日目
197日目 198日目 199日目 200日目 201日目 202日目 203日目
204日目 205日目 206日目 207日目 208日目 209日目 210日目
211日目 212日目 213日目 214日目 215日目 216日目 217日目
218日目 219日目 220日目 221日目 222日目 223日目 224日目
225日目 226日目 227日目 228日目 229日目 230日目 231日目
232日目 233日目 234日目 235日目 236日目 237日目 238日目
239日目 240日目 241日目 242日目 243日目 244日目 245日目
246日目 247日目 248日目 249日目 250日目 251日目 252日目
253日目 254日目 255日目 256日目 257日目 258日目 259日目
260日目 261日目 262日目 263日目 264日目 265日目 266日目
267日目 268日目 269日目 270日目 271日目 272日目 273日目
274日目 275日目 276日目 277日目 278日目 279日目 280日目
281日目 282日目 283日目 284日目 285日目 286日目 287日目
288日目 289日目 290日目 291日目 292日目 293日目 294日目
295日目 296日目 297日目 298日目 299日目 300日目 301日目
302日目 303日目 304日目 305日目 306日目 307日目 308日目
309日目 310日目 311日目 312日目 313日目 314日目 315日目
316日目 317日目 318日目 319日目 320日目 321日目 322日目
323日目 324日目 325日目 326日目 327日目 328日目 329日目
330日目 331日目 332日目 333日目 334日目 335日目 336日目
337日目 338日目 339日目 340日目 341日目 342日目 343日目
344日目 345日目 346日目 347日目 348日目 349日目 350日目
351日目 352日目 353日目 354日目 355日目 356日目 357日目
358日目 359日目 360日目 361日目 362日目 363日目 364日目

いま一番お得なページ! 解析
[an error occurred while processing this directive]