Ketika Anda mem-boot komputer, banyak pesan bergulir pada layar konsol yang menampilkan banyak inisialisasi dan konfigurasi otomatis yang sedang dieksekusi. Kadang-kadang Anda mungkin ingin mengubah sedikit bagaimana tahap ini bekerja, yang berarti bahwa Anda perlu untuk memahaminya dengan baik. Itulah tujuan dari bagian ini.
Pada sistem dengan BIOS, pertama, BIOS mengambil kendali atas komputer, menginisialisasi pengontrol dan perangkat keras, mendeteksi disk, dan menjembatani semuanya bersama-sama. Kemudian mencari Master Boot Record (MBR) dari disk pertama dalam urutan boot dan memuat kode yang disimpan di sana (tahap pertama). Kode ini kemudian meluncurkan tahap kedua dan akhirnya mengeksekusi bootloader.
Berbeda dengan BIOS, UEFI lebih canggih, ia tahu sistem berkas dan dapat membaca tabel partisi. Antarmuka mencari penyimpanan sistem untuk partisi berlabel pengidentifikasi unik global (
GUID) tertentu yang menandainya sebagai
EFI System Partition (
ESP), tempat bootloader, boot manager, UEFI shell, dll., berada, dan meluncurkan bootloader yang diinginkan. Jika Boot Aman diaktifkan, proses boot akan memverifikasi keaslian biner EFI di sana dengan tanda tangan (sehingga
grub-efi-arch-signed diperlukan dalam kasus ini). Spesifikasi UEFI juga mendefinisikan dukungan untuk boot dalam mode BIOS lama. Ini disebut
Compatibility Support Module (
CSM/Modul Dukungan Kompatibilitas). Jika CSM diaktifkan, CSM akan mencoba boot dari MBR drive. Namun, banyak sistem baru tidak lagi mendukung mode CSM.
Dalam kedua kasus kemudian bootloader yang sebenarnya mengambil alih, menemukan bootloader berantai atau kernel pada disk, memuat, dan mengeksekusinya. Kernel kemudian diinisialisasi, dan mulai mencari dan memasang partisi yang berisi sistem berkas root, dan akhirnya menjalankan program pertama — init. Sering kali, "partisi root" ini dan ini init pada kenyataannya, terletak di sistem berkas virtual yang hanya ada di RAM (karena itu namanya, "initramfs", sebelumnya disebut "initrd" untuk "initialization RAM disk"). Sistem berkas ini dimuat dalam memori oleh bootloader, seringkali dari berkas pada hard drive atau dari jaringan. Ini berisi minimum yang diperlukan oleh kernel untuk memuat sistem berkas root "sebenarnya": ini mungkin modul driver untuk hard drive, atau perangkat lain yang tanpanya sistem tidak dapat boot, atau, lebih sering, skrip inisialisasi dan modul untuk merakit larik RAID, membuka partisi terenkripsi, mengaktifkan volume LVM, dll. Setelah partisi root dipasang, initramfs menyerahkan kontrol ke init yang sebenarnya, dan mesin kembali ke proses boot standar.
9.1.1. Sistem init systemd
”init sejati” saat ini disediakan oleh systemd dan seksi ini mendokumentasikan sistem init ini.
Systemd mengeksekusi beberapa proses, yang bertanggung jawab menyiapkan sistem: papan ketik, driver, sistem berkas, jaringan, layanan. Itu melakukan hal ini sambil menyimpan pandangan global sistem secara keseluruhan, serta kebutuhan komponen-komponen. Masing-masing komponen digambarkan oleh ”berkas unit” (kadang-kadang lebih); sintaks yang umum diturunkan dari sintaks ”berkas *.ini” yang banyak digunakan, dengan pasangan-pasangan kunci = nilai dikelompokkan antara header-header [section]. Berkas unit disimpan di bawah /lib/systemd/sistem/ dan /etc/systemd/system/; mereka datang dalam beberapa rasa, tapi kami akan fokus pada ”layanan” dan ”target” di sini.
Suatu ”berkas .service” systemd menggambarkan proses yang dikelola oleh systemd. Itu kurang lebih berisi informasi yang sama seperti init-script gaya lama, tetapi dinyatakan dalam cara yang deklaratif (dan jauh lebih ringkas). Systemd menangani sebagian besar tugas-tugas yang berulang (memulai dan menghentikan proses, memeriksa status, mencatat log, menurunkan hak, dan sebagainya), dan berkas layanan hanya perlu mengisi spesifik dari proses. Sebagai contoh, berikut adalah berkas layanan untuk SSH:
[Unit]
Description=OpenBSD Secure Shell server
Documentation=man:sshd(8) man:sshd_config(5)
After=network.target auditd.service
ConditionPathExists=!/etc/ssh/sshd_not_to_be_run
[Service]
EnvironmentFile=-/etc/default/ssh
ExecStartPre=/usr/sbin/sshd -t
ExecStart=/usr/sbin/sshd -D $SSHD_OPTS
ExecReload=/usr/sbin/sshd -t
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure
RestartPreventExitStatus=255
Type=notify
RuntimeDirectory=sshd
RuntimeDirectoryMode=0755
[Install]
WantedBy=multi-user.target
Alias=sshd.service
Bagian [Unit] berisi informasi umum tentang layanan, seperti deskripsi dan sumber daya halaman manualnya, serta hubungan (ketergantungan dan urutan) ke layanan lain. Bagian [Service] berisi deklarasi yang terkait dengan eksekusi layanan (memulai, menghentikan, mematikan, memulai ulang), direktori, dan berkas konfigurasi yang digunakan. Bagian terakhir, [Install], sekali lagi membawa informasi umum ke mana target untuk memasang layanan dan, dalam hal ini, alias yang dapat digunakan sebagai pengganti nama layanan. Seperti yang Anda lihat, hanya ada sedikit kode di sana, hanya deklarasi. Systemd menangani menampilkan laporan kemajuan, melacak proses, dan bahkan memulai ulang saat diperlukan. Sintaks berkas-berkas ini sepenuhnya dijelaskan dalam beberapa halaman manual (misalnya systemd.service(5), systemd.unit(5), systemd.exec(5), dsb.).
Suatu "berkas .target" Systemd menggambarkan keadaan sistem, dimana satu set layanan diketahui beroperasi. Ini dapat dianggap sebagai setara runlevel gaya lama. Salah satu target adalah local-fs.target; ketika itu dicapai, sisa sistem bisa berasumsi bahwa seluruh sistem berkas lokal dikait dan dapat diakses. Target lain termasuk network-online.target dan sound.target (untuk daftar lengkap target khusus lihat systemd.special(7)). Dependensi target dapat dicantumkan baik dalam berkas target (di baris Requires=), atau menggunakan tautan simbolis ke berkas layanan di direktori /lib/systemd/system/nama_target.target.wants/. Misalnya, /etc/systemd/system/printer.target.wants/ berisi tautan ke /lib/systemd/system/cups.service; oleh karena itu systemd akan memastikan CUPS berjalan untuk mencapai printer.target.
Karena berkas unit deklaratif, bukan skrip atau program, mereka tidak dapat dijalankan secara langsung, dan mereka hanya ditafsirkan oleh systemd; beberapa utilitas karena itu memungkinkan administrator untuk berinteraksi dengan systemd dan mengendalikan keadaan sistem dan setiap komponen.
Utilitas pertama yang seperti itu adalah systemctl. Ketika dijalankan tanpa argumen, itu menampilkan semua berkas unit yang dikenal systemd (kecuali yang dinonaktifkan), maupun status mereka. systemctl status memberikan pandangan yang lebih baik atas layanan, maupun proses-proses terkait. Bila nama yang diberikan pada suatu layanan (seperti dalam systemctl status ntp.service), itu bahkan mengembalikan lebih banyak rincian, maupun beberapa baris log terakhir yang terkait dengan layanan (lebih jauh tentang ini nanti).
Memulai suatu layanan secara manual hanya sekedar masalah menjalankan systemctl start namalayanan.service. Seperti dapat diduga, menghentikan layanan dilakukan dengan systemctl stop namalayanan.service; sub perintah lain termasuk reload dan restart.
Untuk mengendalikan apakah suatu layanan aktif (yaitu apakah itu akan secara otomatis dijalankan saat boot), gunakan systemctl enable namalayanan.service (atau disable). is-enabled memungkinkan memeriksa status layanan.
Fitur menarik dari systemd adalah bahwa itu menyertakan komponen log bernama journald. Datang sebagai pelengkap untuk sistem log yang lebih tradisional seperti syslogd, tetapi itu menambahkan fitur-fitur menarik seperti kaitan formal antara suatu layanan dan pesan-pesan yang dihasilkannya, dan kemampuan untuk menangkap pesan kesalahan yang dihasilkan oleh urutan inisialisasi. Pesan dapat ditampilkan kemudian, dengan sedikit bantuan dari perintah journalctl. Tanpa argumen, itu hanya memunculkan semua pesan log yang terjadi sejak boot sistem; itu akan jarang digunakan dengan cara demikian. Kebanyakan, itu akan digunakan dengan suatu tanda pengenal layanan:
# journalctl -u ssh.service
-- Logs begin at Tue 2015-03-31 10:08:49 CEST, end at Tue 2015-03-31 17:06:02 CEST. --
Mar 31 10:08:55 mirtuel sshd[430]: Server listening on 0.0.0.0 port 22.
Mar 31 10:08:55 mirtuel sshd[430]: Server listening on :: port 22.
Mar 31 10:09:00 mirtuel sshd[430]: Received SIGHUP; restarting.
Mar 31 10:09:00 mirtuel sshd[430]: Server listening on 0.0.0.0 port 22.
Mar 31 10:09:00 mirtuel sshd[430]: Server listening on :: port 22.
Mar 31 10:09:32 mirtuel sshd[1151]: Accepted password for roland from 192.168.1.129 port 53394 ssh2
Mar 31 10:09:32 mirtuel sshd[1151]: pam_unix(sshd:session): session opened for user roland by (uid=0)
Bendera baris perintah lain yang berguna adalah -f, yang memerintahkan journalctl untuk tetap menampilkan pesan baru seperti saat mereka dikeluarkan (seperti gaya tail -f berkas).
Jika suatu layanan tampaknya tidak bekerja seperti yang diharapkan, langkah pertama untuk memecahkan masalah adalah memeriksa apakah layanan memang sedang berjalan dengan systemctl status; jika tidak, dan pesan yang diberikan oleh perintah pertama tidak cukup untuk mendiagnosa masalah, periksa log yang dikumpulkan oleh journald tentang layanan tersebut. Sebagai contoh, asumsikan SSH server tidak bekerja:
# systemctl status ssh.service
● ssh.service - OpenBSD Secure Shell server
Loaded: loaded (/lib/systemd/system/ssh.service; enabled)
Active: failed (Result: start-limit) since Tue 2015-03-31 17:30:36 CEST; 1s ago
Process: 1023 ExecReload=/bin/kill -HUP $MAINPID (code=exited, status=0/SUCCESS)
Process: 1188 ExecStart=/usr/sbin/sshd -D $SSHD_OPTS (code=exited, status=255)
Main PID: 1188 (code=exited, status=255)
Mar 31 17:30:36 mirtuel systemd[1]: ssh.service: main process exited, code=exited, status=255/n/a
Mar 31 17:30:36 mirtuel systemd[1]: Unit ssh.service entered failed state.
Mar 31 17:30:36 mirtuel systemd[1]: ssh.service start request repeated too quickly, refusing to start.
Mar 31 17:30:36 mirtuel systemd[1]: Failed to start OpenBSD Secure Shell server.
Mar 31 17:30:36 mirtuel systemd[1]: Unit ssh.service entered failed state.
# journalctl -u ssh.service
-- Logs begin at Tue 2015-03-31 17:29:27 CEST, end at Tue 2015-03-31 17:30:36 CEST. --
Mar 31 17:29:27 mirtuel sshd[424]: Server listening on 0.0.0.0 port 22.
Mar 31 17:29:27 mirtuel sshd[424]: Server listening on :: port 22.
Mar 31 17:29:29 mirtuel sshd[424]: Received SIGHUP; restarting.
Mar 31 17:29:29 mirtuel sshd[424]: Server listening on 0.0.0.0 port 22.
Mar 31 17:29:29 mirtuel sshd[424]: Server listening on :: port 22.
Mar 31 17:30:10 mirtuel sshd[1147]: Accepted password for roland from 192.168.1.129 port 38742 ssh2
Mar 31 17:30:10 mirtuel sshd[1147]: pam_unix(sshd:session): session opened for user roland by (uid=0)
Mar 31 17:30:35 mirtuel sshd[1180]: /etc/ssh/sshd_config line 28: unsupported option "yess".
Mar 31 17:30:35 mirtuel systemd[1]: ssh.service: main process exited, code=exited, status=255/n/a
Mar 31 17:30:35 mirtuel systemd[1]: Unit ssh.service entered failed state.
Mar 31 17:30:35 mirtuel sshd[1182]: /etc/ssh/sshd_config line 28: unsupported option "yess".
Mar 31 17:30:35 mirtuel systemd[1]: ssh.service: main process exited, code=exited, status=255/n/a
Mar 31 17:30:35 mirtuel systemd[1]: Unit ssh.service entered failed state.
Mar 31 17:30:35 mirtuel sshd[1184]: /etc/ssh/sshd_config line 28: unsupported option "yess".
Mar 31 17:30:35 mirtuel systemd[1]: ssh.service: main process exited, code=exited, status=255/n/a
Mar 31 17:30:35 mirtuel systemd[1]: Unit ssh.service entered failed state.
Mar 31 17:30:36 mirtuel sshd[1186]: /etc/ssh/sshd_config line 28: unsupported option "yess".
Mar 31 17:30:36 mirtuel systemd[1]: ssh.service: main process exited, code=exited, status=255/n/a
Mar 31 17:30:36 mirtuel systemd[1]: Unit ssh.service entered failed state.
Mar 31 17:30:36 mirtuel sshd[1188]: /etc/ssh/sshd_config line 28: unsupported option "yess".
Mar 31 17:30:36 mirtuel systemd[1]: ssh.service: main process exited, code=exited, status=255/n/a
Mar 31 17:30:36 mirtuel systemd[1]: Unit ssh.service entered failed state.
Mar 31 17:30:36 mirtuel systemd[1]: ssh.service start request repeated too quickly, refusing to start.
Mar 31 17:30:36 mirtuel systemd[1]: Failed to start OpenBSD Secure Shell server.
Mar 31 17:30:36 mirtuel systemd[1]: Unit ssh.service entered failed state.
# vi /etc/ssh/sshd_config
# systemctl start ssh.service
# systemctl status ssh.service
● ssh.service - OpenBSD Secure Shell server
Loaded: loaded (/lib/systemd/system/ssh.service; enabled)
Active: active (running) since Tue 2015-03-31 17:31:09 CEST; 2s ago
Process: 1023 ExecReload=/bin/kill -HUP $MAINPID (code=exited, status=0/SUCCESS)
Main PID: 1222 (sshd)
CGroup: /system.slice/ssh.service
└─1222 /usr/sbin/sshd -D
#
Setelah memeriksa status layanan (gagal), kita melanjutkan memeriksa log; mereka menunjukkan satu kesalahan di berkas konfigurasi. Setelah menyunting berkas konfigurasi dan memperbaiki kesalahan, kita jalankan ulang layanan, kemudian memastikan bahwa itu memang berjalan.
9.1.2. Sistem init System V
Sistem init Sistem V (yang akan kita panggil init untuk singkatnya) menjalankan beberapa proses, mengikuti instruksi dari berkas /etc/inittab. Program pertama yang dijalankan (yang sesuai dengan langkah sysinit) adalah /etc/init.d/rcS, skrip yang mengeksekusi semua program di direktori /etc/rcS.d/.
Di antara ini, Anda akan menemukan berturut-turut program-program yang bertanggung jawab atas:
mengkonfigurasi papan ketik konsol;
memuat driver: sebagian besar modul kernel yang dimuat oleh kernel sendiri saat perangkat keras terdeteksi; driver tambahan kemudian dimuat secara otomatis ketika modul sesuai dicantumkan dalam /etc/modules;
memeriksa integritas sistem berkas;
mengait partisi lokal;
mengkonfigurasi jaringan;
mengait network filesystems (NFS).
Setelah tahap ini, init mengambil alih dan memulai program-program yang diaktifkan pada runlevel default (yang biasanya runlevel 2). Itu mengeksekusi /etc/init.d/rc 2, skrip yang memulai semua layanan yang tercantum dalam /etc/rc2.d/ dan nama-nama yang mulai dengan huruf "S". Nomor dua-angka yang mengikuti secara historis digunakan untuk menentukan urutan dimulainya layanan, tetapi saat ini sistem boot default menggunakan insserv, yang menjadwalkan semuanya secara otomatis berdasarkan dependensi skrip. Setiap skrip boot dengan demikian menyatakan kondisi yang harus dipenuhi untuk memulai atau menghentikan layanan (misalnya, jika itu harus dimulai sebelum atau setelah layanan lain); init kemudian meluncurkan mereka dalam urutan yang memenuhi kondisi ini. Penomoran statis skrip karena itu tidak lagi dipertimbangkan (tapi mereka selalu harus mempunyai awal nama dengan "S" diikuti oleh dua digit dan nama sebenarnya dari skrip yang digunakan untuk dependensi). Umumnya, layanan dasar (seperti log dengan rsyslog), atau penugasan port dengan portmap yang mulai pertama, diikuti oleh layanan-layanan standar dan antarmuka grafis (gdm3).
Sistem boot berbasis ketergantungan ini memungkinkan mengotomatisasi penomoran ulang, yang bisa menjadi membosankan jika itu harus dilakukan secara manual, dan itu jadi membatasi resiko kesalahan manusia, karena penjadwalan dilakukan berdasarkan parameter yang ditunjukkan. Manfaat lain adalah bahwa layanan dapat dimulai secara paralel ketika mereka independen dari yang lain, yang dapat mempercepat proses boot.
init membedakan beberapa runlevel, sehingga ia dapat beralih dari satu ke yang lain dengan perintah telinit level-baru. Seketika, init mengeksekusi /etc/init.d/rc lagi dengan runlevel baru. Skrip ini kemudian akan memulai pelayanan yang kurang dan menghentikan yang tidak diinginkan. Untuk melakukan ini, mengacu pada isi /etc/rc X .d (dimana X mewakili runlevel baru). Skrip yang dimulai dengan "S" (seperti dalam "Start") adalah layanan yang akan dijalankan; yang dimulai dengan "K" (seperti "Kill") adalah layanan yang harus dihentikan. Skrip tidak memulai layanan apapun yang sudah aktif pada runlevel sebelumnya.
Secara default, init System V dalam Debian menggunakan empat runlevels yang berbeda:
Level 0 hanya digunakan sementara, ketika komputer menuju mati. Dengan demikian, itu hanya berisi banyak skrip "K".
Level 1, juga dikenal sebagai mode pengguna tunggal, berkaitan dengan sistem dalam mode terdegradasi; itu termasuk hanya layanan dasar, dan ditujukan untuk operasi pemeliharaan dimana interaksi dengan pengguna biasa tidak diinginkan.
Level 2 adalah tingkat untuk operasi normal, yang mencakup layanan jaringan, antarmuka grafis, pengguna login, dll.
Level 6 ini mirip dengan tingkat 0, kecuali bahwa itu digunakan selama fase shutdown yang mendahului reboot.
Ada tingkat lain, terutama 3-5. Secara default mereka telah dikonfigurasi untuk beroperasi dengan cara yang sama sebagai tingkat 2, namun administrator dapat memodifikasi mereka (dengan menambahkan atau menghapus skrip di direktori /etc/rcX.d yang sesuai) untuk beradaptasi atas kebutuhan tertentu.
Semua skrip yang terkandung dalam berbagai direktori /etc/rcX.d benar-benar hanya taut simbolik — dibuat saat instalasi paket oleh program update-rc.d — menunjuk ke skrip sebenarnya yang disimpan dalam /etc/init.d/. Administrator dapat menala layanan yang tersedia pada masing-masing runlevel dengan kembali menjalankan update-rc.d dengan parameter yang disesuaikan. Halaman manual update-rc.d(1) menjelaskan sintaks secara rinci. Harap dicatat bahwa menghapus semua taut simbolik (dengan parameter remove) bukanlah metode yang baik untuk menonaktifkan layanan yang ada. Sebaliknya Anda hanya harus mengonfigurasi itu untuk tidak mulai berjalan pada runlevel yang diinginkan (sambil mempertahankan panggilan yang sesuai untuk menghentikannya apabila layanan berjalan pada runlevel sebelumnya). Karena update-rc.d memiliki antarmuka yang agak rumit, Anda mungkin lebih suka menggunakan rcconf (dari paket rcconf) yang menyediakan antar muka yang lebih mudah dipakai.
Akhirnya, init memulai program kontrol untuk berbagai konsol virtual (getty). Menampilkan sebuah prompt, menunggu nama pengguna, kemudian mengeksekusi login pengguna untuk memulai sesi.
