Q&A
VMが再起動した可能性はないですか？
お世話になります。
現在CentOS7にbind9をインストールして自前のDNSサーバーを立てています。GCP上のVMインスタンスに作成しているのですが、時々きまぐれに4:10分きっかりに停止してしまいます。
前後の状況を整理すると
- dnsサーバー自体は普段は正常に動いている。
- 半月に一度ぐらい気まぐれにAM4:10に停止する。（きまぐれではないのかもしれません。）
- named.confやzoneファイルに問題はなし。（チェックコマンドでは正常）
- 運用開始して２ヶ月程度しかたっていない。
- Google cloud Platform CentOS7で稼働。
- yumでインストールしたもの。
となります。
停止のステータスを見ると、
# systemctl status named-chroot ● named-chroot.service - Berkeley Internet Name Domain (DNS) Loaded: loaded (/usr/lib/systemd/system/named-chroot.service; enabled; vendor preset: disabled) Active: failed (Result: exit-code) since 金 2020-02-28 04:10:13 JST; 5h 54min ago Process: 27962 ExecStop=/bin/sh -c /usr/sbin/rndc stop > /dev/null 2>&1 || /bin/kill -TERM $MAINPID (code=exited, status=1/FAILURE) Main PID: 20812 (code=killed, signal=KILL) 2月 28 04:10:13 foo-dns1 sh[29962]: -p, --pid print pids without signaling them 2月 28 04:10:13 foo-dns1 sh[29962]: -l, --list [=<signal>] list signal names, or convert one to a name 2月 28 04:10:13 foo-dns1 sh[29962]: -L, --table list signal names and numbers 2月 28 04:10:13 foo-dns1 sh[29962]: -h, --help display this help and exit 2月 28 04:10:13 foo-dns1 sh[29962]: -V, --version output version information and exit 2月 28 04:10:13 foo-dns1 sh[29962]: For more details see kill(1). 2月 28 04:10:13 foo-dns1 systemd[1]: named-chroot.service: control process exited, code=exited status=1 2月 28 04:10:13 foo-dns1 systemd[1]: Stopped Berkeley Internet Name Domain (DNS). 2月 28 04:10:13 foo-dns1 systemd[1]: Unit named-chroot.service entered failed state. 2月 28 04:10:13 foo-dns1 systemd[1]: named-chroot.service failed.
となっており、/usr/sbin/rndc stopで意図的に停止しているように見えました。
デバックのやり方もままならないので、どういう風に解決してよいのかという感じなのです。停止は半月に一回ぐらいの割合でほんとうに恣意的に行われているようです。
バージジョンはBIND 9.11.4でchrootで運用中です。named.confやzoneファイルに問題はありませんでした。また手動で起動コマンドを実行すると問題なく起動します。
意図的に再起動コマンドをなどをcronで書いておけば問題なさそうですが、それだと運用上気持ちが悪いかなと思っております。
これが何によって実行され（停止され）ているのか、また、これは何の目的によってなされていることなのか、これを修正する方法（永続的にサービスを起動させる方法）が知りたいと思っております。
よろしくお願いします。
/var/namaed/data/named.runログでは停止した同日の4:35分の更新で以下が記録されていました。
reloading configuration succeeded reloading zones succeeded all zones loaded running managed-keys-zone: Key 20326 for zone . acceptance timer complete: key now trusted managed-keys-zone: Key 20326 for zone . acceptance timer complete: key now trusted managed-keys-zone: Key 20326 for zone . acceptance timer complete: key now trusted managed-keys-zone: Key 20326 for zone . acceptance timer complete: key now trusted managed-keys-zone: Key 20326 for zone . acceptance timer complete: key now trusted
停止に関連するログがいくつか散見されていて、
managed-keys-zone: Key 20326 for zone . acceptance timer complete: key now trusted client @0x7f9a66eb49c0 192.168.100.12#41194 (example.work): transfer of 'example.work/IN': AXFR started (serial 2019122008) client @0x7f9a66eb49c0 192.168.100.12#41194 (example.work): transfer of 'example.work/IN': AXFR ended client @0x7f9a640f79d0 192.168.100.12#48590 (example.com): transfer of 'example.com/IN': AXFR started (serial 2019122004) client @0x7f9a640f79d0 192.168.100.12#48590 (example.com): transfer of 'example.com/IN': AXFR ended client @0x7f9a66ea6390 192.168.100.12#52621 (100.168.192.in-addr.arpa): transfer of '100.168.192.in-addr.arpa/IN': AXFR started (serial 2019122003) client @0x7f9a66ea6390 192.168.100.12#52621 (100.168.192.in-addr.arpa): transfer of '100.168.192.in-addr.arpa/IN': AXFR ended client @0x7f9a66eb49c0 192.168.100.12#49041 (100.168.192.in-addr.arpa): transfer of '100.168.192.in-addr.arpa/IN': AXFR started (serial 2019122003) client @0x7f9a66eb49c0 192.168.100.12#49041 (100.168.192.in-addr.arpa): transfer of '100.168.192.in-addr.arpa/IN': AXFR ended client @0x7f9a66ec2ff0 192.168.100.12#42082 (example.work): transfer of 'example.work/IN': AXFR started (serial 2019122008) client @0x7f9a66ec2ff0 192.168.100.12#42082 (example.work): transfer of 'example.work/IN': AXFR ended client @0x7f9a640e93a0 192.168.100.12#44015 (example.com): transfer of 'example.com/IN': AXFR started (serial 2019122004) client @0x7f9a640e93a0 192.168.100.12#44015 (example.com): transfer of 'example.com/IN': AXFR ended received control channel command 'stop' shutting down: flushing changes stopping command channel on 127.0.0.1#953 stopping command channel on ::1#953 no longer listening on ::#53 no longer listening on 127.0.0.1#53 no longer listening on 192.168.100.11#53 exiting managed-keys-zone: journal file is out of date: removing journal file managed-keys-zone: loaded serial 58 zone 0.in-addr.arpa/IN: loaded serial 0 zone 1.0.0.127.in-addr.arpa/IN: loaded serial 0 zone 100.168.192.in-addr.arpa/IN: loaded serial 2019122003 zone example.work/IN: loaded serial 2019122008 zone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN: loaded serial 0 zone example.com/IN: loaded serial 2019122004 zone localhost.localdomain/IN: loaded serial 0 zone localhost/IN: loaded serial 0 all zones loaded running
このようなログがでていました。shutting down: flushing changesのところから意図的に停止させているように見えました。
バージョンは以下です。
# named -v BIND 9.11.4-P2-RedHat-9.11.4-9.P2.el7 (Extended Support Version) <id:7107deb>
OSは、
# cat /etc/redhat-release CentOS Linux release 7.7.1908 (Core)
よろしくお願いいたします。
uptime コマンドを実行したら下記のような表示になると思いますが、起動後何日ぐらいでしょうか？
下記の場合は、 2日11:52分 前に起動されています。
BIND 9 が再起動した日時と関連はありそうでしょうか？
22:44:14 up 2 days, 11:52, 3 users, load average: 0.09, 0.10, 0.17
投稿した日の朝にbind9が起動していないことに気がついたので、再起動の形跡はなさそうでした。
21daysでした。
13:21:44 up 21 days, 12:31, 2 users, load average: 0.00, 0.01, 0.05
BIND の設定で、ログは取得する設定になっていますか？ 取得している場合は、終了した時間の前後に何が記録されていますか？
CHERRYさん、何かわかったっぽいです。
Active: failed (Result: exit-code) since 日 2020-03-01 02:13:59 JST; 11h ago
というsystemctl statusからの同時刻のmessageログを見ると、
Mar 1 02:13:58 apw-dns1 kernel: named invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0
でoom-killerが呼ばれていました。メモリ不足でnamaed-chrootが起動できなくなっているっぽいです。（この解釈が正しいのかちょっとまだ不明です。）
Linux が意図的にnamedをシャットダウンしているのは当たっていたかもです。
あなたの回答
tips
プレビュー
