“firewall-cmd –reload”でDid not receive a replyが起きた
“ns-lab BB”はRHEL系・Debian系・SUSE系の3ディストリビューションを併用し、
基本となるOS設計は合わせつつも導入時期によって微妙に違いがあったりする。
差異があると言ってもインターネットに接続しているサーバは、
セキュリティ対策としてファイアウォールでACLを書いてパケット制御もしている。
このACL設定量がかなりの大きさとなっており、
システムによって差異はあるとしてもACLを6,000～45,000行ほど書いている。
全盛期は60,000～70,000行はあったのでコレでも最適化して登録内容を減らした方だが、
とは言っても多いのは否めない状況になっている (´・ω・｀)
話が変わり、年末年始にSUSE系のOSをアップグレードした所、
firewalldのポリシーを自動更新するスクリプトでエラーが出る様になった。
詳細を調べたら”firewall-cmd –reload”を実行した時に25秒以上の時間を要してしまい、
d-bus応答不能と判断されてプロセス間通信をぶった切ってしまう様だった。
ややこしいのが、SUSE系でのみ問題が発生してRHEL系・Debian系は発生しない所だった。
フォーラムを読むとOS毎にfirewall-cmdとd-busの細かい実装差異がある様で、
今回はSUSE系で問題を踏み抜いた形となった。
また、timeコマンドを使って処理秒数を計測したところ、
ACLを6,000行ほど読み込む段階で約26秒を要しておりコレが原因と言えそうだった。
- firewalld > Error: Did not receive a reply.
- SUSE Support > changing d-bus limits
最終的に次の設定を行い、d-busのservice_start_timeoutを60秒(60000ms)に拡張しつつ、
ACLをipsetでまとめる事にした。
………
ACL処理のipset化とd-bus拡張を同時に実行したので何方が効いたのかわからないが、
テスト段階では正常動作しており丸一日は自動制御含め処理を継続出来た。
$ cat /etc/dbus-1/system.d/system-local.conf
<!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-Bus Bus Configuration 1.0//EN"
"http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
<busconfig>
<limit name="service_start_timeout">60000</limit>
</busconfig>
|
ACLを自動生成するスクリプトの改修も年始に行い日時処理が無事通るのかテストを実施中。
こちらは土日に高負荷の処理が走るので、それを無事にオールクリアしたら記事にしようと思う。
iptablesのACLをipsetでグループ化する方法はググればいくらでも出てくるので省略するが、
今回の改修で地雷ポイントも分かって来たので、こちらも時間があれば書きたい。
