Saya menjalankan openSuSE Leap 15.6. Saya memiliki bind9 terpasang. Namun, itu terus memuat ulang hampir setiap 30 detik. Apakah itu perilaku yang diharapkan? Saya bahkan menghapusnya, menghapus semua direktori dan menginstalnya kembali tanpa zona yang ditambahkan. Saya juga menghentikan apache, postfix, dan sekunder. Namun, masih memuat ulang dengan semua zona kosong otomatis setiap 30 detik. Hal ini menyebabkan logdigest membengkak menjadi 4-10MB per hari. Dari mana sinyal SIGHUP berasal? Apakah ini berhubungan dengan rndc?
bermula dengan:
Sep 17 20:23:50 server systemd[1]: Memuat ulang Berkeley Internet Name Domain (DNS)...
Sep 17 20:23:50 server named[3644218]: menerima sinyal SIGHUP untuk memuat ulang zona
Sep 17 20:23:50 server named[3644218]: memuat konfigurasi dari '/etc/named.conf'
Sep 17 20:23:50 server named[3644218]: membaca anchor kepercayaan bawaan dari file '/etc/bind.keys'
Sep 17 20:23:50 server systemd[1]: Berhasil memuat ulang Berkeley Internet Name Domain (DNS).
Sep 17 20:23:50 server named[3644218]: menggunakan rentang port UDP/IPv4 default: [32768, 60999]
Sep 17 20:23:50 server named[3644218]: menggunakan rentang port UDP/IPv6 default: [32768, 60999]
Sep 17 20:23:50 server named[3644218]: menentukan ukuran kolam tugas zona berdasarkan 4 zona
Sep 17 20:23:50 server named[3644218]: none:99: 'max-cache-size 90%' - diatur ke 7149MB (dari 7944MB)
Sep 17 20:23:50 server named[3644218]: memperoleh kunci root untuk tampilan _default dari '/etc/bind.keys'
Sep 17 20:23:50 server named[3644218]: zona kosong otomatis: 10.IN-ADDR.ARPA
Sep 17 20:23:50 server named[3644218]: zona kosong otomatis: 8.B.D.0.1.0.0.2.IP6.ARPA
Sep 17 20:23:50 server named[3644218]: zona kosong otomatis: EMPTY.AS112.ARPA
Sep 17 20:23:50 server named[3644218]: zona kosong otomatis: HOME.ARPA
Sep 17 20:23:50 server named[3644218]: zona kosong otomatis: RESOLVER.ARPA
Sep 17 20:23:50 server named[3644218]: mengkonfigurasi saluran perintah dari '/etc/rndc.key'
Sep 17 20:23:50 server named[3644218]: mengkonfigurasi saluran perintah dari '/etc/rndc.key'
Sep 17 20:23:50 server named[3644218]: memuat ulang konfigurasi berhasil
Sep 17 20:23:50 server named[3644218]: memuat ulang zona berhasil
Sep 17 20:23:50 server named[3644218]: zona kunci-terkelola: Kunci 20326 untuk zona . sekarang dipercaya (timer penerimaan selesai)
Sep 17 20:23:50 server named[3644218]: semua zona telah dimuat
Sep 17 20:23:50 server named[3644218]: berjalan
Anda bisa memeriksa apakah ada crontab, systemd.timer yang memuat ulang layanan bind Anda.
Selain itu, beberapa program dapat memuat ulang program lain secara sengaja, misalnya logrotate
Tidak, untuk membantu memberi ide agar menjalankan bind dalam wadah dan bukan di host secara langsung. Saya menjalankan bind sebagai resolver dan authoritative dalam wadah selama bertahun-tahun dalam skala besar. Saya sangat menyarankan itu.
Tebakan saya adalah Anda menggunakan killall, pkill, atau skill di suatu tempat yang cocok dengan substring, misalnya killall nama atau pkill med. Gunakan nama yang tepat jika memungkinkan, misalnya killall -e nama atau pkill -x med, jika tidak, gunakan kriteria pencocokan yang lebih panjang, misalnya pkill -f 'nama.*dengan.argyang.tetap'.
systemd[1]: Memuat ulang
Saya rasa itu petunjuk utama Anda. Sesuatu di dalam atau di bawah systemd, atau dijalankan oleh systemd, mengirim atau menyebabkan SIGHUP dikirim ke situ. Saya tidak yakin ada penyebutan systemd di sana jika sesuatu yang benar-benar tidak terkait dengan systemd yang memberi sinyal. Apakah Anda memiliki sesuatu yang terkait dengan systemd yang mungkin bertentangan dengannya? Apakah ada sesuatu seperti crontab(-seperti) pengganti dari systemd yang mungkin menjalankan pekerjaan terlalu sering yang menyebabkan masalah? Sesuatu yang mungkin menyebabkan systemd berpikir bahwa ia tidak memulai dengan benar, jadi ia terus mengulangi dengan SIGHUP untuk mencoba dan memuat ulang semuanya?
Terima kasih atas wawasan tersebut. Saya baru saja membuat sekunder menjalankan OS yang sama sebagai utama. Tidak ada perilaku seperti itu. Ini tidak pernah terbuka ke Internet. Ketika saya lebih muda dan lebih bodoh, saya menjalankan layanan utama yang melayani beberapa situs wordpress dalam database yang sama ke internet, SEBELUM Cloudflare dan fail2ban. Saya dalam penyangkalan. Terlalu banyak shenanigans dan pembaruan OS. Kadang-kadang Anda harus membersihkan dan melakukan “Crazy Ivan.” Backup sekarang dengan ISO siap. Sekali lagi, terima kasih.
Bisakah ini menjadi semacam peretasan? Tidak ada cara untuk melihat sumber perintah tersebut, bukan?
Mungkin ada kondisi balapan yang Anda muat sesuatu dengan systemd dan hal tersebut membutuhkan named tetapi systemd belum aktif sebagai status sehingga Anda memuat ulang named dan selesai.
Mungkin perlu peningkatan timeout dan restart daemon systemd untuk memanggil Potterang - kita semua menyukai systemd, bukan?
kita semua menyukai systemd, bukan?
Uhm, ya, tentang itu … ketika distro yang saya sukai (sangat) pertama kali beralih ke default systemd … saya ikut serta … awalnya … tetapi itu menyebabkan terlalu banyak masalah, … jadi saya menghilangkan systemd dari host utama saya tersebut. Host lain di mana itu tidak menimbulkan masalah … saya izinkan menggunakan systemd. Bertahun-tahun kemudian, host utama … masalah systemd paling tidak telah diperbaiki (sebagian besar melalui kerja keras orang lain) sehingga akhirnya tidak lagi menyebabkan masalah besar bagi saya. Tetapi sampai hari ini, di beberapa sistem yang saya kelola, systemd tetap diusir dari beberapa … dengan alasan yang baik (s).