2017年03月15日

このエントリーをはてなブックマークに追加
いままで気づかなかったのが不思議なくらいです。
ずいぶんと前にセットアップした CentOS ですが、最近になって気づきました。

iptables のファイルを編集していたときに、たくさんの行を貼り付けていると貼り付けられたすべての行が、意図せず勝手にコメントアウトされているのです。

このような不便な機能を無効にするには、vi で以下のコマンドをセットすればOKでした。
:set paste

で、この勝手なコメントアウトは不便なため毎回上記コマンドを入力していたのですが、いい加減デフォルトで無効にする方法を調べました。

いろいろな方法が記載されていたのですが、なんだかよくわかりません。
以下の方法で簡単にできました。

# vi /etc/vimrc

いろいろ記載がありましたので、最初の方に以下の行を追加
set paste

※前後行はこんな感じでした
set nocompatible " Use Vim defaults (much better!)
set bs=indent,eol,start " allow backspacing over everything in insert mode
"set ai " always set autoindenting on
"set backup " keep a backup file
set viminfo='20,\"50 " read/write a .viminfo file, don't store more
" than 50 lines of registers
set history=50 " keep 50 lines of command line history
set ruler " show the cursor position all the time

これで自動コメントアウト機能が無効になりました。

※以下のプラグインが理由でしょうか?削除しても効果あるのかもしれません。
/usr/share/vim/vim74/autoload/paste.vim

stock_value at 09:05|この記事のURLComments(0)TrackBack(0)技術 

2017年03月14日

このエントリーをはてなブックマークに追加
現状すべて不明です。以下の症状があったのでメモ。
ps -ef コマンドを実行し、プロセスの稼働状況を確認すると、
php /tmp/phpd.local というプロセスが存在していました。

なんと!

調べても出てこないのですが、きっと何か悪さをするプログラムに違いありません。とりあえずプロセスを終了させ、Apacheの再起動をしました。

しかしなんだったのでしょうか。
stock_value at 12:56|この記事のURLComments(0)TrackBack(0)技術 

2017年03月13日

このエントリーをはてなブックマークに追加
昨日の記事の続きです。
iptables restore を行うとメモリが枯渇するようだということに気づきました。

そしてルールは大量です。
で、気になったのですが iptables は一体どのぐらいのルールをかけるのだろうか、と。

なお僕は数台のサーバーを管理していますが、その中でルール数が多いのは2台。

1台は以下の通り1Gのメモリです。(そしてこちらが今回のトラブルです)
# free -h
total used free shared buffers cached
Mem: 988M 562M 426M 0B 3.7M 20M
-/+ buffers/cache: 538M 450M
Swap: 4.0G 33M 4.0G

# iptables -nvL |wc -l
46796
iptables のルール数は上記の通り約47,000


もう1台は以下の通り
# free -h
total used free shared buffers cached
Mem: 9.6G 7.1G 2.5G 548M 498M 4.4G
-/+ buffers/cache: 2.2G 7.4G
Swap: 4.9G 230M 4.7G

# iptables -nvL |wc -l
54593
iptables のルール数は上記の通り約54,000


これで、ルールをなるべく統一したいので、マージしながら作業していました。
そしてある程度マージが完了し、ルール数を調整しながら iptables のルール再読込行ったところ、問題が発生しました。
ちなみに上記の46796で、やく2,000ルール増やすともうダメです。結構ギリギリのラインみたい。

で、いろいろ確認していると、 iptables がルールを読み込むときには、スワップ領域ではないところにメモリを確保するようです。そしてそれはルール数に依存するようです。

なお iptables の最大のルール数は32bitの場合に 3800万のようです。

1つのルールごとに少しずつ消費するようなのですが、結局1Gでは超過してしまうということのようです。
ということで、メモリを増設して様子を見たいと思います。
stock_value at 13:29|この記事のURLComments(0)TrackBack(0)技術 

2017年03月12日

このエントリーをはてなブックマークに追加
iptables の大量コピーをおこなったのです。

OSの History ログでは以下のようになっていました。
2452 17/XX/XX 11:02:19: vim /etc/sysconfig/iptables
2453 17/XX/XX 11:06:06: service iptables reload

そして message ログは以下の通り
XX 11:05:59 XXX named[60450]: client X.X.X.X#51951: query (cache) 'XXXX' denied
XX 11:36:11 XXX kernel: imklog 5.8.10, log source = /proc/kmsg started.
XX 11:36:11 XXX rsyslogd: [origin software="rsyslogd" swVersion="5.8.10" x-pid="61530" x-info="http://www.rsyslog.com"] start

これは 11:05:59 に oom-killer によって rsyslog のプロセスが落とされ、それに気づいて rsyslog を再起動したのが 11:36 ということです。

で、時間から考えるに、iptables ファイルの編集とiptables ルールの再読み込みが可能性としては一番高いように思います。

そして気になる動作がありました。
このとき僕は poderosa を利用し ssh にて大量のコピーを行ってました。やく55,000行です。そしてこのとき、一度にすべての行を貼り付けたのですが、途中で止まってしまいました。
それでも4万行近くは貼り付けられたので、残りの部分を再度貼り付けました。そしてファイル編集は完了したのです。

iptables の reload を行うと、監視しているサーバーからアラートが上がりました。ping応答がないと。DNS応答がないと。うわ!iptables の内容間違えたかな。そのように考えていたのです。

iptables -F をしてフィルターをクリアしても、回復しません。ということで、ポートのLISTENなどを確認しました。
しかしLISTENしていない・・。これでプロセスが落ちたことはわかりました。

いくつか検証をしているうちに、ログが一切表示されていないことがわかりました。そして service rsyslog start で起動すると、ログが出力され oom-killer が動作していることに気づきました。


で、その後何回かチャレンジしていたところ、 iptables restore で毎回 out of memory が発生していることに気づきました。
iptabbels はメモリを食うのでしょうか・・。
stock_value at 12:43|この記事のURLComments(0)TrackBack(0)技術 

2017年03月11日

このエントリーをはてなブックマークに追加
単なるメモです。
以前、CentOS(たぶん5) をHyper-Vで利用していたとき、CPUの割り当てを変更すると、Kernel Panic になったと記憶しています。
またメモリの割り当ては変更は問題なかったのですが、動的メモリはだめでした。

と、そんな印象を持っていたのですが、今回 Hyper-Vの環境で CentOS6.Xの最新版を動かしている状況で、コアの割り当ておよびメモリーを増設したいという話が上がりました。

以前のように特にCPUコアについては、Kernelパニックになることも考えられ乗り気ではありませんでした。
が、テストで検証したところ問題無く増設することができました。

メモリは大丈夫だと考えていましたが、心配だったコアも増設することができて安心しました。
stock_value at 12:01|この記事のURLComments(0)TrackBack(0)技術 

2017年03月10日

このエントリーをはてなブックマークに追加
新しいサーバーを構築し、既存のサーバーからデータを移動させ、動作確認を行っていました。
そんななか、 perl で書かれた cgi プログラムが動作しません。

こんなエラーでした。
defined(%hash) is deprecated at ./jcode.pl line 684.

# perl -v
This is perl 5, version 22, subversion 1 (v5.22.1)

Perlのバージョンが上がると、このようなエラーがでてしまうようです。
以下のサイトが簡単にできそうだったので、参考にしました。

参考
あらゆるメモ:Perl5.12.xで生じるjcode.plの「defined(%hash) is deprecated」エラー
jcode.plのエラー

ちょっと書き換えただけですが、とりあえず問題無く動作しました。
stock_value at 19:42|この記事のURLComments(0)TrackBack(0)技術