Petunjuk dan ruang lingkup
Core dump adalah snapshot dari ruang alamat proses. Ini mungkin berisi kunci, isi permintaan, data pengguna, dan buffer yang belum dibersihkan. Pertanyaan ini menguji diagnosis Linux dan tata kelola data produksi: memisahkan apakah dump dapat dikumpulkan dari siapa yang dapat melihatnya, berapa lama dump tersebut disimpan, dan bagaimana pembersihannya dibuktikan.
Apa yang dievaluasi oleh pewawancara
- Bukti dari sinyal keluar, journal, pesan kernel, versi, dan metadata core.
- Pemahaman tentang pengumpulan, kompresi, penyimpanan, dan batas
coredumpctlpada systemd-coredump. - Simbolisasi dengan biner, pustaka, simbol debug, dan build ID yang tepat.
- Kontrol lengkap untuk konten, izin, enkripsi, retensi, kapasitas, dan privasi.
- Pembuktian setelah perbaikan melalui reproduksi, metrik crash, pemeriksaan penghapusan, dan tinjauan akses.
Struktur jawaban yang direkomendasikan
Mulailah dengan bukti berisiko rendah: status layanan, sinyal, journal, pesan kernel, versi, dan metrik sumber daya. Jika core dump dapat dibenarkan, aktifkan penangkapan terkontrol secara singkat pada instans yang terisolasi, batasi ukuran dan jumlahnya, serta gunakan penyimpanan terenkripsi khusus. Analisis dan hancurkan segera atau biarkan tugas retensi yang terdokumentasi menghapusnya saat kedaluwarsa.
Pembahasan mendalam: dari crash hingga remediasi
Identifikasi penyebab keluar terlebih dahulu
Periksa systemctl status, journal, catatan kernel OOM, sinyal keluar, dan jumlah restart. SIGSEGV, SIGABRT, dan SIGBUS memberikan petunjuk yang berbeda; exit 137 seharusnya pertama-tama memicu pemeriksaan OOM cgroup. File core saja bukanlah bukti terjadinya segmentation fault.
Perbaiki input simbolisasi
Simpan biner, pustaka bersama, simbol debug, dan build ID yang tepat untuk instans yang mengalami crash. Ambil semuanya dari penyimpanan artefak tepercaya. Baca thread, sinyal, dan stack terlebih dahulu; periksa heap dan register hanya jika diperlukan untuk mengurangi paparan.
Bangun pengumpulan yang terkontrol
systemd-coredump dapat menyerahkan dump ke layanan khusus dan menyimpannya di journal atau direktori eksternal. Tetapkan kuota per file dan total, kompresi, konkurensi, dan peringatan. Untuk layanan yang sangat sensitif, atur LimitCORE=0 atau kumpulkan hanya metadata dan stack terkontrol, dengan rollback yang tercatat.
Tetapkan batasan akses dan retensi
Enkripsi penyimpanan core, berikan hak istimewa paling rendah (least privilege), dan audit setiap akses. Jangan izinkan akun operasional biasa mengunduh dump. Tetapkan retensi dari jendela diagnostik dan kebijakan, dengan kedaluwarsa otomatis dan alarm kapasitas. Perintah, jalur file, dan tiket tidak boleh berisi token.
Selesaikan siklus dengan bukti
Reproduksi crash sebelum perbaikan, verifikasi build baru di bawah input yang sama, dan amati tingkat crash serta restart. Verifikasi kedaluwarsa dump, cache, dan cadangan, lalu lakukan tinjauan akses. Jika penghapusan data sensitif tidak dapat dibuktikan, risiko tetap ada.
Contoh jawaban
“Saya akan mengonfirmasi sinyal, journal, catatan kernel OOM, versi deployment, dan metrik cgroup, membedakan SIGSEGV dari exit 137. Jika ini adalah crash aplikasi, saya akan mengaktifkan systemd-coredump secara singkat pada node yang terisolasi, membatasi ukuran per file dan total, serta menggunakan simbol yang cocok dengan build ID untuk memeriksa stack sebelum heap. Direktori terenkripsi hanya akan mengizinkan akses berdurasi singkat untuk tim insiden; token tidak akan pernah dimasukkan ke dalam tiket. Saya akan melakukan uji regresi terhadap input asli, mengamati tingkat crash, menghapus dump, dan meninjau journal, cadangan, serta izin. Jika batasan tidak dapat dibuat tepercaya, saya akan menonaktifkan dump penuh dan hanya menyimpan metadata dan stack yang terkontrol.”
Pola kegagalan umum dan perbaikannya
- Mengasumsikan core berarti SIGSEGV → Verifikasi bukti sinyal, OOM, cgroup, dan deployment.
- Menginstal alat langsung di produksi → Gunakan artefak yang cocok dan lingkungan analisis yang terisolasi.
- Hanya membahas ruang disk → Sertakan kuota, retensi, enkripsi, dan pembersihan.
- Memperlakukan dump seperti log biasa → Gunakan least privilege, akses sementara, dan audit independen.
- Berhenti setelah layanan pulih → Verifikasi reproduksi, tingkat crash, penghapusan, cadangan, dan akses.
Rubrik penilaian dan pemeriksaan mandiri
Jawaban yang kuat mencakup bukti keluar, build ID dan simbol, batasan systemd-coredump, sakelar pengumpulan, kuota, enkripsi, kontrol akses, retensi dan penghapusan, minimalisasi data, rollback, dan metrik pascaperbaikan.
Tanyakan: Dapatkah saya membuktikan penyebabnya? Apakah file analisis cocok dengan build? Siapa yang dapat mengaksesnya? Berapa lama file tersebut disimpan? Bagaimana token dicegah masuk ke dalam log? Apa yang membuktikan remediasi dan pembersihan?
Tindak lanjut dan ekstensi
Kapan Anda harus menonaktifkan core dump sepenuhnya?
Nonaktifkan dump penuh ketika ruang alamat sangat sensitif dan isolasi, enkripsi, akses, serta pembersihan yang tepercaya tidak dapat dibangun. Pertahankan sinyal, thread-stack, atau bukti diagnostik minimal dan catat hilangnya kemampuan diagnostik tersebut.
Bagaimana cara Anda mengurangi risiko ketika hanya satu mesin yang mengalami crash?
Kumpulkan metadata dan stack terkontrol terlebih dahulu, terbatas pada instans tersebut dan jendela waktu yang singkat. Jika dump penuh diperlukan, gunakan kedaluwarsa otomatis, otorisasi sekali pakai, dan penghapusan segera salinan lokal setelah diunggah.
Bagaimana cara menghindari simbolisasi yang menyesatkan?
Verifikasi build ID, checksum, dan manifes artefak untuk biner, pustaka, dan simbol. Tandai stack sebagai tidak pasti jika tidak cocok; jangan pernah menyimpulkan dari rilis yang serupa.
Bagaimana jika dump sudah ada dalam cadangan (backup)?
Perlakukan cadangan sebagai domain data terpisah. Lacak versi objek dan kedaluwarsa, batasi akses pemulihan, dan pastikan proses penghapusan mencakup indeks cadangan serta tugas rotasi. Catat setiap pengecualian yang disetujui dan waktu pembersihan terbaru.