パスワードを忘れた? アカウント作成
300824 story

UNIXサーバはリブートすべきでない説 225

ストーリー by hylom
でもリブートせざるを得ない状況ってあるしなぁ 部門より

あるAnonymous Coward 曰く、

「何か問題が発生したり、クリーンな環境にしたかったらリブートしろ」という神話があるそうだが、果たしてこれは本当だろうか?(本家/.記事)。

InfoWorldの記事によると、「Windowsで問題が発生したらリブートする」というのは当たり前のことだが、UNIXではそうすべきでないとのこと。何か問題が起きているのであれば、その原因は現在のシステムにあるのであって、リブート後には再現されない恐れがある。そのためリブートする前に原因を精査すべきであると指摘している。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Anonymous Coward on 2011年02月23日 19時12分 (#1907344)
    (T/O)
  • by Anonymous Coward on 2011年02月23日 18時58分 (#1907333)
    手動でdaemonを起動したことを忘れ、停電やハードウェアのメンテナンスで再起動したらdaemonが自動で上がってこず、なんていうトラブルがありますんで、UNIXであっても設定変更したらリブートして動作確認すべきです。

    いや、今回の話はデバッグしてからリブートしても遅くないぞっていう話だとは思うが。
  • by Anonymous Coward on 2011年02月23日 23時37分 (#1907481)

    その運用状態が「トラブったまま原因究明まで停止して良い物かどうか」で全然意味合いが違う。
    WindowsだUNIXだって前に、それが何をしているのか?どの程度の重要度が有るのか?で違うだろ。
    場合によってはリブートして再現しないならしないでそのまま動かし、他所で再現テストって方が良いことも珍しくない。
    そのサーバー自体がすべてなのか、大きな業務の一部なのかでも変わるね。

  • Linux は、別だよね (スコア:2, おもしろおかしい)

    by reininn (35924) on 2011年02月24日 8時57分 (#1907589)
    Linux は、よく NFS が、おかしくなって再起動しないと
    どうにもならなくなるけど、ここで言う UNIX とは、別だよね。
    また、samba のプロセスが 10000個ぐらいになってしまったりしたときも、
    全部 kill するのは、馬鹿だよね。
  • by Anonymous Coward on 2011年02月23日 19時03分 (#1907337)

    >リブート後には再現されない恐れがある。
    問題は解消され、かつ、二度とその問題が起こらないのであれば、
    リブートするのは極めて合理的な解決策である(キリッ

  • by Anonymous Coward on 2011年02月23日 19時15分 (#1907346)

    ブートシーケンスに食い込んだrootkitがさまざまな痕跡を消してしまうから、的な話かと。
    犯行現場は残しておけって訓話じゃなかったのか。

    # ただ、「Sunのサーバは電源を落とすと上がってこない、だから電源は落とすな。」
    # という言い伝えが社内にあるんだよな。
    # 動き続いて安定しているHDDの不具合が露呈してしまうからだとかいう分析が・・・

  • by Anonymous Coward on 2011年02月23日 19時25分 (#1907357)
    サービスの復旧を優先するか、問題の解決を優先するかの優先度によっても、どちらがいいかという判断は分かれるのではないか?

    システムの動態解析というのは、開発時のテストの時ぐらいしかやらないのでは?
    どちらかというと、メモリダンプを取って、再起動というのが多いかな。死体(メモリダンプイメージ)の解析には時間をかけられるが、システムがまともに動かない時間というのは、外圧が大きすぎて、時間をかけられない為です。下手に動作を継続して、データを破壊でもされたら、余計に、復旧に時間がかかりますからね。

    最近は、テラバイトクラスのメモリを積んでいて、メモリダンプを取るだけで8時間以上かかる大型システムも増えていますので、問題の種類にもよるが、再起動なんかする前に、予備系にさっさと切り替えてしまう方が多いのではないかな?
    • by cm (41778) on 2011年02月23日 21時45分 (#1907426)

      >メモリダンプを取って、再起動というのが多いかな。

      メモリダンプを取らないという判断もあった。
      三回ほどOSがフリーズしたたびに、ベンダーの言う通り、ちょっと時間かけてメモリダンプをとって提出したが「原因不明」と三回とも回答があったので「御社システムにおいて、メモリダンプは意味がないと思われる、メモリダンプ取得によって原因究明という実績がない。実績を出せる様になってから要求せよ」と伝えたら、「次回からはログ提出提出のみを依頼いたします」だとさ。
      そして、メモリ容量がでかくなって、メモリダンプ取っていたら契約上許される時間でのサービス復旧は無理。
      なので、方式設計レベルで「問題発生時は、メモリダンプなどの取得をせず、再起動後に取得できるログファイルなどから解明を行う。解明できる確率は低いが、これまでの実績からメモリダンプにより解明できたケースが皆無であることも考慮した」とか書かれていたりする。

      >再起動なんかする前に、予備系にさっさと切り替えてしまう方が多いのではないかな?

      予備系に切り替えは、デザスタリリカバリとかで、ダウンタイムがそれなりに大きくなると予想されていたりとかね。
      クラスタの切り替え、だめなら再度の全再起動、それでだめなら災害対策用センターにあるシステムに火をいれつつ..とかね。

      親コメント
    • by Anonymous Coward on 2011年02月23日 20時02分 (#1907380)
      で、予備系への切り替えに失敗して、日経あたりのネタになると……
      親コメント
  • のんきだな (スコア:1, 興味深い)

    by Anonymous Coward on 2011年02月23日 22時35分 (#1907455)

    サービスは迅速に復旧させる、原因究明もちゃんとやる
    両方やらなくちゃあいけないのがエンジニアの辛い所だな

  • デバイスがプロセス奪ったままハングしてインタラプトも効かず(シャットダウンすら出来ない)、
    ハードリセットしか手がなくなった私が通りますよ。
  • 何をやってるんだ。UNIXは「障害が起こる前に shutdown -r now するもの」だよ?!
    なんで障害が起こるまで再起動を延期するかな…

    --
    fjの教祖様
  • と思う。 windowsの場合は、ベンダーが「再起動で直ります」って平気で言う。
typodupeerror

あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー

読み込み中...