Startup dan Shutdown

Menekan tombol power dan mendapat layar login dua puluh detik kemudian terasa seperti satu aksi tunggal, padahal di antaranya ada empat pelari yang saling menyerahkan estafet: firmware, bootloader, kernel, dan systemd. Masing-masing punya tugas sempit namun kritis, dan masing-masing punya cara gagalnya sendiri — boot yang lambat, pesan error di layar hitam, atau shutdown yang menggantung semuanya menunjuk pelari yang berbeda. Chapter ini menelusuri alur boot lengkap dari tombol power sampai prompt login, membedah waktu bootnya, lalu membahas proses shutdown beserta empat perintahnya.

Empat Etape dari Tombol Power ke Login #

Etape pertama: firmware. Saat daya menyala, firmware — UEFI pada mesin modern, BIOS pada mesin lama — menjalankan POST (Power-On Self Test) untuk memastikan RAM dan perangkat inti hidup, lalu mencari media boot: UEFI membaca daftar entri boot dari memorinya (NVRAM) dan memuat file .efi dari partisi khusus FAT32 yang lazim dipasang di /boot/efi, sedangkan BIOS klasik membaca sektor pertama disk. Fitur Secure Boot milik UEFI memeriksa tanda tangan kriptografi rantai program sebelum memperbolehkan eksekusi, sehingga bootloader dan kernel yang dimodifikasi tanpa kunci sah akan ditolak.

Etape kedua: bootloader. GRUB, bootloader paling umum di Linux, memuat dua file ke memori: kernel vmlinuz dan initramfs. GRUB juga menyediakan menu saat boot — kita bisa menekan tombol panah untuk memilih kernel lama atau menambahkan parameter kernel (misalnya single untuk masuk mode darurat) di baris perintahnya. Parameter kernel yang tersedia didokumentasikan panjang lebar di bootparam(7) .

Etape ketiga: kernel dan initramfs. Kernel ter-dekompresi dan menyala sebagai raja baru di memori, mendeteksi hardware, lalu menghadapi masalah ayam-dan-telur: untuk memasang filesystem root, kernel butuh driver storage — padahal driver itu tersimpan di dalam filesystem root. Solusinya adalah initramfs: arsip kecil berisi filesystem sementara di RAM yang diisi driver, skrip, dan utilitas. initramfs memuat driver, membuka partisi terenkripsi atau LVM bila ada, memasang root asli, lalu membuang dirinya dengan switch_root dan menyerahkan kendali pada program pertama: systemd, yang sejak detik itu menjadi PID 1.

Etape keempat: systemd. Sesuai bab-bab sebelumnya, systemd mengaktifkan default.target (Chapter systemd Targets ), menarik graf dependensi, dan menyalakan unit secara paralel. Rutenya kira-kira: local-fs.target untuk memasang filesystem, basic.target untuk service dasar, lalu multi-user.target atau graphical.target — hingga akhirnya getty menampilkan prompt login atau display manager menyambut kita. Empat file utama hasil etape kedua dan ketiga tersimpan di /boot; berikut contoh tampilan isinya di instalasi desktop Debian:

config-6.12.12-amd64
grub
initrd.img-6.12.12-amd64
System.map-6.12.12-amd64
vmlinuz-6.12.12-amd64

vmlinuz adalah kernel terkompresi, initrd.img adalah initramfs, System.map berisi tabel simbol kernel untuk debugging, config adalah konfigurasi build kernel, dan folder grub menyimpan konfigurasi bootloader. Nomor versi di nama file menjelaskan mengapa banyak pasangannya: setiap kernel terpasang menyimpan salinannya sendiri, sehingga boot ke versi lama tetap mungkin.

Berapa Lama Boot Kita? #

Perintah systemd-analyze menjawabnya dengan satu baris ringkasan — misalnya Startup finished in 2.1s (firmware) + 4.2s (loader) + 2.3s (kernel) + 9.8s (userspace) = 18.4s — yang persis terbagi per etape di atas. Dua subperintahnya membedah bagian userspace. systemd-analyze blame mencetak daftar unit diurutkan dari yang paling lama dinyalakan, misalnya 5.1s NetworkManager-wait-online.service di puncaknya. systemd-analyze critical-chain menelusuri rantai unit serial yang benar-benar menentukan total waktu boot.

Shutdown: Empat Nama, Satu Tujuan #

Mematikan sistem jauh lebih sederhana daripada menyalakannya, dan kini semua perintah klasik bermuara ke satu program. Kita bisa membuktikannya dari isi symlink-nya:

readlink /usr/sbin/poweroff /usr/sbin/reboot /usr/sbin/halt

Output yang Dihasilkan:

../bin/systemctl
../bin/systemctl
../bin/systemctl

Ketiganya menunjuk ../bin/systemctl — symlink relatif yang bila diurai berarti /usr/bin/systemctl. systemctl memeriksa nama yang dipakai untuk memanggilnya lalu berperilaku seperti perintah klasik tersebut. Perbedaan semantik di antara para perintah ini perlu dihafal:

Mengapa Shutdown Kadang Menggantung #

Shutdown yang sehat berjalan cepat dan senyap: systemd menghentikan unit di graf terbalik — service lebih dulu, target penyusun belakangan — mengirim SIGTERM ke tiap proses lalu SIGKILL bila proses itu menolak mati, dan terakhir me-remount semua filesystem read-only supaya datanya konsisten. Layar pun digantikan pesan singkat. Masalah muncul saat ada proses yang tidak mau pergi, dan inilah wujudnya:

A stop job is running for nginx.service (1min 10s / 1min 30s)

systemd sedang menunggu nginx.service berhenti; angka pertama adalah waktu yang sudah berlalu, angka kedua adalah sisa anggaran. Anggaran itu disebut stop timeout dan nilainya bisa kita baca dari konfigurasi bawaan:

grep 'DefaultTimeoutStopSec' /etc/systemd/system.conf

Output yang Dihasilkan:

#DefaultTimeoutStopSec=90s

Tanda # di awal baris berarti nilai bawaan sedang dipakai: 90 detik per unit. Bila satu-satunya service yang bandel butuh anggaran penuh, shutdown kita tertunda satu setengah menit — dan bila beberapa service lambat berurutan, penundaannya menumpuk. Dua jalan keluarnya: set TimeoutStopSec=30 pada unit yang bandel, atau turunkan globalnya lewat drop-in /etc/systemd/system.conf.d/timeout.conf berisi [Manager] dan DefaultTimeoutStopSec=30s. Kebalikannya juga sah — service database yang butuh waktu tutup rapi justru layak diberi anggaran lebih besar. Untuk keadaan darurat saat layar sudah beku, systemctl poweroff --force --force memotong semua proses seketika, dan menahan tombol power fisik selama lima detik selalu menjadi jalan terakhir yang tidak mengenal sistem operasi apa pun.

Estafet boot dan ritme shutdown kini utuh kita pahami. Tetapi di dunia nyata, yang paling sering kita hadapi bukan alurnya yang sehat — melainkan service yang menolak hidup. Kerangka diagnosa untuk itulah isi chapter pamungkas section ini.

Untuk rujukan lebih jauh: parameter kernel di bootparam(7) , perilaku shutdown dan kawan-kawannya di shutdown(8) , serta bedah alur boot yang lebih rinci di wiki Arch tentang proses boot .