Linuxサーバの再起動が必要になるのがほぼ確実なんだけど、1200日以上無停止で稼働しているサーバなので、再起動時にfsckが走ることになる。
そうなると起動が終わるまで長時間サービスを停めることになるので出来ればfsckを走らせたくない。
調べてみると起動時のfsckの実行を抑止する方法があった。
一つ目はfstabの6つ目のパラメータを”0″にする方法で、これだとヴォリュームラベル/デヴァイス単位で設定出来る。
二つ目はshutdownコマンドのオプションで”-f”（fastboot）を指定する方法で、このオプションを付けると”/”にfastbootというファイルを作成し、次回のboot時にbootプロセスがfsckをスキップする（ことを期待する）。
今回は全てのディスクのfsckをスキップさせたいので、”shutdown -f -r”を試してみようかな？
問題は短時間とは言え提供中のサービスを止めるのでタイミングをどうするかだなぁ（汗）。
More from: linux
←クリックしてくれると嬉しいです。
mount解除は出来たものの・・・
仕事場のサーバの更新で、作業担当者がNFSサーバを先に止めてしまい、クライアント側でアクセス出来なくなってしまった。
クライアント側も一度止めて起動しなおせば良かったんだけど、こっちは止める予定が無かったのでそのままになっていた。
このことに気付いたのは作業が終了して運用に入ってから（汗）。
クライアント側でdfコマンドでマウント状況を見ようして途中で帰って来なくなって気付いた。
プロセスがディスク待ちとなってしまってシグナルを受け付けない状態で止められない。
こうなってしまっては一度再起動するしか手段は無いようだけど、すでに運用に入っているうえ、4年近く止めていないので起動時にfsckがかかるのが確実で起動にかかる時間が読めない。
mtabを見るとOS自体はNFSサーバの一部をマウントしたままと認識しているが、実際にはアクセス出来ない状態。
少なくとも、一度マウントを解除して再度マウントし直さなくてはならないんだけど、普通にumountコマンドで解除しようとしてもエラーが出て解除できない。
仕方がないので”umount -f”でやってみても駄目で、最後の手段”umoount -l”で試すとエラーは出たけどmtabからはエントリーが消えたので解除出来、df-kで見ても問題なく解除されていた。
後は再度マウントすれば良いんだけど、昨日の記事に書いたように再マウントできない状態になっている。
やっぱり再起動しないと駄目なんだろうなぁ・・・（汗）。
←クリックしてくれると嬉しいです。
nfsがつながらない・・・
仕事場のサーバ（群）を更新したら、nfsでのマウントが出来なくなった。
元々全てのサーバを仮想環境で動かしていて、その基盤自体を更新したので一部のサーバを除いて再起動となった。
それぞれのサーバの環境そのものは古い基盤からコピーしたので設定そのものに変化は無いが、一部の古い基盤上に残したサーバからnfsでの接続が上手く出来なくなってしまった。
もちろん両サーバの間の疎通確認は取れていて、pingやsshでの接続は問題無い。
ところが”mount -t nfs NFSサーバ:ディレクトリ マウントポイント”コマンドを実行すると,
“mount: RPC: ポートマッパーの失敗です – RPC: 受け取れません”
というエラーが表示されマウントできない。
nfsサーバ側ではnfsデーモンは動作させているのだけど、クライアント側からもチェックしてみようと思って、
”/usr/sbin/rpcinfo -p NFSサーバ”を実行すると、
”rpcinfo: ポートマッパと接続できません: RPC: 遠隔システムエラー – ホストへの経路がありません”
となってしまう。
つまりpingは通るけど、rpcinfoコマンドは通信できないらしい。
NFSサーバ側でrpcinfoコマンドを実行するとnfsもmountdも動作していると出る。
”arp -d NFSサーバ”でarpテーブルのエントリを削除しても変化無いので、今のところはお手上げ状態。
スタックさせたL3スイッチのトラブルがあったので、その影響らしいが再起動するしか無いのかなぁ？
←クリックしてくれると嬉しいです。
ファイルが大きすぎたorz
Linuxサーバーで自動的に作成しているファイルが作られていないとの連絡が来た。
調べてみるとファイルの先頭と最後だけが作られている。
ヘッダとフッタは固定文字列を出力しているため、中身だけが全く無い状態。
試しに手動で同じスクリプトを動かしてみると、中で使っているsortコマンドが/tmp以下に作るファイルがスペースが無くて作れないというエラーを吐いて処理が落ちた。
確かに基にしたファイルはいつになく大きいのでsortするにもいつも以上にディスクを必要としているようだ。
かと言って/tmpを含むファイルシステムを拡張するわけにもいかないので、テンポラリファイルの作成先を変更することにした。
それには環境変数”TMPDIR”を設定するか、sortに”-T”オプションでテンポラリファイル作成用ディレクトリを指定するかのどちらかが必要。
今回は”-T”オプションで容量に余裕のあるファイルシステム上のディレクトリを指定するようにしたら問題無くファイルが作成された。
いや、まさかあんな大容量のファイルを相手にすることになるとは想定外だったなぁ（汗）。
←クリックしてくれると嬉しいです。
telnetで接続できない？
職場のサーバーの設定を確認しようとして普段入り浸っている（笑）サーバーからtelnetで入ろうとした。
ところが何故かtelnetがはじかれてしまって入れない。
滅多にログインしない（＝安定動作している）サーバーなので、入るのも年単位ぶりで細かい設定を忘れていたが、どうもtelnet接続を制限しているようだ。
そこでサーバーを経由しないでPCから直接接続を試みると無事に入れたのでtelnetの設定から見直すことにした。
このサーバーはxinetd経由で各サービスを動作させているので、/etc/xinetd.d以下のファイルで各サービスの設定を行っている。
その中のtelnetファイルを見ると、案の定”only_from”で接続を許可するホストを限定していた。
そこで最初に接続しようとして入れなかったサーバー等を追記してxinetdを再起動。
ついでに不便なので特定のネットワークを許可するために”192.168.xxx.0/24”も追加しておいた。
これで他のサーバーからも接続できるようになって使いやすくなった。
←クリックしてくれると嬉しいです。
squidが重かったのは解消した模様
職場のサーバーにsquidを導入してurlフィルタリングを始めたところ、何らかの理由でネットの速度が落ちてしまっていた。
そこで朝一の混雑時だけフィルタリングして、その後はsquidを通さないように運用していた。
その後調べたところ、cache.logにファイルディスクリプタ不足の警告が出ていたので、キャッシュ用ファイルの数をデフォルトの1024から増やしてsquidを再起動して運用してみた。
そうしたところ、朝一の混雑時でも警告が出なくなり、現場からもネットが遅いという報告が入って来なくなった。
どうやら原因はこのファイルディスクリプタ不足によるsquidの応答遅延だったようだな。
とにかくこれでしばらくは運用できそうだ。
←クリックしてくれると嬉しいです。
squidが重い原因
先日から導入したsquidが重いということで、運用でなんとかカバーしているが、重たい（と言われる）原因を探ってみた。
サーバーのCPU負荷やメモリ使用量を調べてみると、これが実に軽くてサーバーそのものの処理能力が不足しているわけでは無さそう。
となるとこの手のソフトウェアでよくある”同時接続数が足りない”のが原因では無いだろうか？
一体どれだけの同時接続数が許容されているのか？ということでググって見ると、デフォルトでは1024らしい。
その接続数は/etc/squid/squid.confで指定できるらしいことも判明。
ところが、その数値を増やすだけでなく、OSが同時にオープンできるファイル数（キャッシュ用）も増やさなくてはならないらしい。
とにかく、この対策をしてみて経過を見ることにしよう。
←クリックしてくれると嬉しいです。
squidが重い・・・
先だってクライアントから外部への接続を制限するためにsquidを導入した。
ところが、その後各所から「ネットが遅い」という連絡があって聞いてみるとsquidを設定したプロキシを通すと遅いという。
urlフィルタリングは有効なんだけど、外部への接続数が多いためにsquid自体がボトルネックになっている模様（汗）。
使用するキャッシュ容量やメモリ容量を多めに割り当ててみてどうなるかだなぁ？
←クリックしてくれると嬉しいです。
squidを導入してみた
職場の回線から外部へのアクセスが異常に多いので、ゲートウェイサーバーでフィルタリングをしてみることにした。
簡単にするためにLinux標準でインストールされているsquidを使うことにして、アクセス数が多く転送データ量も多いサーバーを含む複数のドメインに対する接続を禁止した。
動作させて数時間経ってからログを見ると、転送量がかなり減っているのが判ったが、曜日によっても異なるので、あと何日かは監視が必要だなぁ。
←クリックしてくれると嬉しいです。
ディスクフル・・・
現場のFAXで受信したFAXが紙で出てくるとの連絡があった。
調べてみると受信データを保存しているファイルサーバーのディスクが一杯になっている（汗）。
先日チェックした際は余裕があったのだけど、このパーティションにはsambaの.recycleディレクトリも置いてあって、その中に大量の削除済みデータが残っていた。
以前にこのディレクトリの中身が増えた際に削除後一定期間が経過したファイルを消すスクリプトを作ってcronで動作するようにしていたが、想定以上のファイルが削除されていたらしい。
中にはオフィスソフト（WORDやExcel）で作られたテンポラリーファイルも大量に残っている。
なので、取り敢えず毎日動作させているスクリプトを修正して削除済みファイルの保存期間を半分（2年->1年）にして動作させると、大量のファイルが削除されている。
さらにテンポラリーファイルに関しては保存期間を1-2日程度にするようにスクリプトを変更する予定。
で、気になるのはそのテンポラリーファイルのファイル名で、~$で始まるファイルが他にもなければ大丈夫なんだけど（汗）。
←クリックしてくれると嬉しいです。