CentOS 7上で2018年12月頃にincronでバグが発生した。
psコマンドを叩いてみると、「defunct」で示されるゾンビプロセスが大量に発生している!
当然のことながら放置すればシステムは暴走しかねない状況にある。
さて、どうしたものか?と思いながら、ゾンビプロセスを殺そうと試みるもkillコマンドでプロセスを殺すことが出来ない。
何故だろう?とその親プロセスを見てみると「incron」が親になっている。
そうこうしている間にもゾンビは増え続けているではないか!?
incronを殺す・・・と言ってkillする必要はないので、以下のコマンドを実行してincronを再起動させてみる
1 |
# systemctl restart incrond.service |
ここでプロセスを確認してみる。
1 |
# ps -ef |
発生していた「defunct」は一掃されゾンビプロセスは綺麗にその姿を消していた。
原因はどうやら「incrond」にあるらしいことまでは、これで特定出来たのだがどうにかならないかと思いながらインターネットを検索するもそれらしき情報がヒットしない。。。しばらくして辿り着いたのが以下のRedHat Bugzillaだった。
https://bugzilla.redhat.com/show_bug.cgi?id=1656939
どうやらincrondのバグが確認されているらしい。
対処方法は、古いソースを入手してリコンパイル&インストールすることになる様だ。当然、現在のincrondを削除しなければならない・・・ということは、設定をメモして云々・・・・(嫌だ!)
そうこうしている間にも、defunctは増え続けていた。
以下のコマンドを実行すると、その数が解る。
1 |
# ps -ef | grep defunct | wc |
出力された数値の左端がその数です。
考えたこと
幾つか対策を考えた
- ソースからビルドしてインストールし直す。
- 古いバージョンに戻す。
- 定期的にincrondを再起動してその場凌ぎをする。
1.ソースからビルドしてインストールし直す
この方法、一見確実な方法である様だが、後にincrondが更新された時にyumで出来要することが出来なくなってしまう。セキュリティホールなどの対応が疎かになってしまう可能性もある。
メンテナンス性が悪いんだよね。出来ればバグ修正が成されたバージョンが提供されるまで待ちたいところなのだが、私の環境下では緊急を要する状況にある。
だめだぁ~( ゚Д゚)
2.古いバージョンに戻す。
では、古いバージョンでは問題が発生していなかったので、バージョンを戻してやろう!
ということで、以下のコマンドで戻せるかチェックしてみる。
1 2 3 4 5 |
# yum --showduplicate list incron.x86_64 インストール済みパッケージ incron.x86_64 0.5.12-6.el7 @epel 利用可能なパッケージ incron.x86_64 0.5.12-6.el7 epel |
残念ながら、古いバージョンのincronは使えそうにない。
もし存在してくれていれば、こんな感じで対応が出来る。
1 |
# yum downgrade incron.x86_64 |
実際やってみると解るが、今回の場合は古いバージョンが存在せず、結果「なにもしませんでした」という寂しいコメントが最後に記されるだけです。
3.定期的にincrondを再起動してその場凌ぎをする。
結局この方法に辿り着きました。
incrondにより生成されたゾンビプロセスは、incrondを再起動することにより削除されていましたので、crondでincrondを定期的に再起動してやることにしました。
まずはcrontabを起動して、定期的にコマンドを実行します。
1 2 3 |
# crontab -e 0 0 * * * /usr/bin/systemctl restart incrond.service |
これで、深夜0時00分にincrondが再起動します。
最後に
この現象は、CentOS7でしか発生していないみたいで、CentOS 6では古いバージョンが使えわれており問題は発生しない感じです。
また、incrondという特殊なパッケージを使っているので、この件に関して悩んでいる人は少ないでしょう
次のバージョンアップで更新されるでしょうし、需要は少ないと思っています。
とは言え、私の備忘録代わりに残しておきます。