Dasar systemd: Cara Linux Modern Menyalakan, Mematikan, dan Menjaga Service-mu

Masuk ke hampir semua server Linux yang dibangun satu dekade terakhir, ada satu program yang diam-diam berjalan di bawah semuanya: systemd. Dia menyala duluan sebelum shell-mu. Dia yang menjalankan daemon SSH yang kamu pakai untuk masuk tadi. Dia pula alasan kenapa aplikasi web-mu kembali hidup setelah server di-reboot tanpa ada yang menyentuhnya. Tapi anehnya, kebanyakan orang baru tahu namanya di hari sebuah service mogok dan ada yang menyuruh “udah, jalanin aja systemctl restart”.

Sayang banget, karena systemd sebenarnya tidak rumit begitu kamu paham masalah apa yang dia selesaikan. Pada intinya dia menjawab satu pertanyaan yang kelihatannya sepele: saat mesin ini menyala, apa saja yang harus jalan, dengan urutan seperti apa, dan apa yang terjadi kalau ada yang mati? Begitu kamu nyaman dengan ide itu, sebagian besar pekerjaan harian di server berhenti terasa seperti tebak-tebakan.

systemd itu sebenarnya apa

Ketika sebuah mesin Linux menyala, kernel dimuat, melakukan persiapan tingkat rendahnya, lalu menyerahkan kendali ke satu program yang tugasnya menghidupkan sisa sistem. Program pertama itu disebut init system, dan di sebagian besar server Linux modern, init system itu adalah systemd.

Anggap saja dia sebagai pengatur panggung di server. Tidak ada yang berjalan sendiri. systemd yang memutuskan apa yang dijalankan, memastikan hal-hal yang dibutuhkan setiap service sudah siap lebih dulu, menghidupkan kembali apa pun yang crash, dan mematikan semuanya dengan rapi saat kamu shut down. Dia adalah proses nomor 1 — induk dari setiap proses lain di mesin itu, entah langsung maupun tidak.

Bagian-bagian yang dikelola systemd disebut service (atau, dalam istilah systemd sendiri, unit — kita bahas kata itu sebentar lagi). Service itu cuma program yang berjalan lama: web server, database, pekerja latar belakang, daemon SSH. Seluruh alasan systemd ada adalah untuk menjalankan hal-hal itu, menjaganya tetap hidup, dan memberitahu kamu apa yang terjadi kalau mereka tidak.

systemd menggantikan cara lama

Sebelum systemd jadi standar, Linux melakukan boot lewat sekumpulan skrip shell yang dijalankan berurutan (sistem yang sering disebut “SysV init”). Cara itu jalan, tapi menjalankan service satu per satu secara ketat itu lambat, dan tidak ada cara bawaan untuk menghidupkan ulang sesuatu yang crash. systemd menjalankan service yang independen secara paralel, melacak ketergantungan di antaranya, lalu mengawasinya setelah dijalankan. Itulah kenapa dia mengambil alih — bukan karena lagi tren, tapi karena dia menyelesaikan masalah nyata yang bikin kesal. Kamu masih akan dengar orang-orang lama menggerutu soal systemd; perdebatan itu tidak perlu jadi urusanmu.

Unit: hal yang dikelola systemd

systemd tidak cuma mengelola program yang sedang berjalan. Dia mengelola apa pun yang bisa dijalankan, dihentikan, atau diawasi, dan tiap hal itu dia sebut unit. Sebuah unit dijelaskan oleh satu berkas konfigurasi teks biasa yang kecil, dan ekstensi berkasnya memberitahu kamu jenis unit-nya apa.

Jenis yang paling sering kamu sentuh adalah service unit (.service) — itulah program yang berjalan lama seperti web server. Tapi ada jenis lain yang layak kamu kenali:

.service — program untuk dijalankan dan diawasi (yang sehari-hari).
.socket — sebuah socket jaringan atau lokal yang didengarkan systemd, lalu menjalankan service terkait hanya ketika sebuah koneksi benar-benar datang.
.timer — pemicu terjadwal, alternatif modern systemd untuk cron job.
.target — sekumpulan unit yang diberi nama, dipakai untuk menggambarkan satu keadaan utuh dari sistem (misalnya, “semua yang dibutuhkan untuk server multi-user normal”).
.mount — sebuah filesystem yang harus di-mount.

Kamu tidak perlu menghafal semua ini. Model berpikir yang penting: satu unit adalah satu hal yang bisa dikelola, dijelaskan oleh satu berkas, dan unit .service adalah tempatmu sehari-hari. Hampir semua tugas “jalankan aplikasiku di server” pada akhirnya bermuara ke menulis atau mengedit satu berkas .service.

        systemd (PID 1)
              │
   ┌──────────┼───────────────┬─────────────┐
   ▼          ▼               ▼             ▼
 ssh.service  nginx.service   db.service   app.service
 (jalan)      (jalan)         (jalan)      (crash → dihidupkan lagi)

systemctl: satu perintah yang kamu pakai tiap hari

Kamu tidak bicara langsung ke systemd. Kamu bicara lewat sebuah alat command-line bernama systemctl. Kalau kamu tidak mengingat apa pun dari artikel ini, ingat saja systemctl dan segelintir kata kerja yang mengikutinya. Kata-kata itu sama saja, service apa pun yang sedang kamu utak-atik — dan justru itulah yang bikin systemd nyaman begitu nyantol.

Ini yang bakal terus kamu pakai. Ganti app dengan nama service yang sebenarnya:

# Lagi jalan nggak sekarang? Menampilkan status, log terbaru, PID.
systemctl status app

# Jalankan sekarang (tidak ngapa-ngapain soal boot berikutnya).
systemctl start app

# Hentikan sekarang.
systemctl stop app

# Matikan lalu nyalakan — klasik "matiin terus nyalain lagi".
systemctl restart app

# Baca ulang konfigurasi TANPA restart penuh, kalau service-nya mendukung.
systemctl reload app

Jalankan systemctl status app lebih dulu setiap kali ada yang tidak beres. Ini perintah paling berguna di seluruh perangkat: dia memberitahu kamu apakah service-nya active (jalan), inactive (berhenti), atau failed (mencoba jalan lalu mati), dan langsung menampilkan beberapa baris log terakhir di situ juga, yang biasanya sudah cukup untuk menemukan masalahnya.

Kebanyakan perintah ini butuh root

Menjalankan, menghentikan, dan mengubah service memengaruhi seluruh mesin, jadi wajar saja systemd minta hak administrator. Di server biasa kamu bakal menambahkan sudo di depannya — misalnya sudo systemctl restart app. Perintah yang cuma membaca seperti systemctl status umumnya jalan tanpa itu. Kalau sebuah perintah diam saja tanpa efek atau mengeluh soal izin, sudo yang hilang itu hal pertama yang perlu kamu cek.

“Enabled” vs “started”: beda yang bikin semua orang kepleset

Inilah titik kebingungan paling umum soal systemd, dan layak kamu pelan-pelan di sini. Menjalankan service dan meng-enable service itu dua hal yang berbeda.

Start artinya: jalankan dia sekarang, di detik ini. Kalau server di-reboot, dia tidak akan kembali sendiri.
Enable artinya: setel supaya dia jalan otomatis di setiap boot berikutnya. Dengan sendirinya, meng-enable tidak menjalankannya sekarang.

Jadi sebuah service baru yang kamu mau jalan sekarang dan tetap hidup sehabis tiap reboot butuh dua-duanya:

# Jalankan sekarang DAN bikin dia balik setelah reboot — dalam satu perintah.
sudo systemctl enable --now app

# Setara dengan melakukannya dalam dua langkah:
sudo systemctl enable app    # akan jalan di boot berikutnya
sudo systemctl start app     # menjalankannya di detik ini juga

Kebalikannya adalah disable (jangan jalan di boot berikutnya) versus stop (hentikan sekarang). Orang sering kena batunya di sini: mereka start sebuah service, semuanya berjalan, lalu mereka reboot server berminggu-minggu kemudian, dan service-nya hilang secara misterius — karena dia tadi di-start tapi tidak pernah di-enable. Setiap kali kamu menyiapkan sesuatu yang harus bertahan melewati reboot, flag --now adalah temanmu.

                jalan sekarang?   auto-jalan saat boot?
 start            ya                    tidak
 enable           tidak                 ya
 enable --now     ya                    ya

Seperti apa berkas service unit itu

Cepat atau lambat kamu bakal mau menjalankan program buatanmu sendiri sebagai service yang dikelola — aplikasimu, pekerja latar belakang, sesuatu yang kamu tulis. Caranya dengan membuat sebuah berkas .service kecil. Kamu tidak perlu paham setiap opsi untuk bisa membacanya, jadi ini contoh realistis dan minimal untuk sebuah aplikasi web fiktif milik ACY Partner Indonesia:

[Unit]
Description=Aplikasi web ACY Partner Indonesia
After=network.target

[Service]
ExecStart=/usr/bin/node /srv/app/server.js
WorkingDirectory=/srv/app
User=appuser
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

Dibaca dari atas ke bawah:

[Unit] menjelaskan unit-nya sendiri. Description adalah teks yang bisa dibaca manusia, yang bakal kamu lihat di status. After=network.target memberitahu systemd untuk tidak menjalankan ini sampai jaringan sudah siap.
[Service] adalah jantungnya. ExecStart adalah perintah persis yang menjalankan program. WorkingDirectory adalah folder tempat dia berjalan. User menyatakan service ini jalan sebagai user yang mana (kebiasaan bagus — jangan jalankan kode aplikasi sebagai root). Restart=on-failure menyuruh systemd menghidupkan kembali service secara otomatis kalau dia crash, dan RestartSec=5 menunggu lima detik sebelum tiap percobaan ulang supaya kamu tidak menggebuk service yang lagi rusak.
[Install] mengatur apa yang terjadi saat kamu enable. WantedBy=multi-user.target adalah pilihan biasa untuk service server normal — dia mengikat service ini ke keadaan standar “sudah boot penuh, multi-user”.

Baris Restart=on-failure itu, buat banyak orang, justru jadi alasan utama repot-repot pakai systemd. Proses-mu mati jam 3 pagi dan systemd diam-diam menghidupkannya lagi lima detik kemudian, tanpa butuh manusia. Perilaku menyembuhkan diri sendiri seperti itulah yang diberikan init system yang baik secara cuma-cuma.

Edit dulu, lalu muat ulang konfigurasi systemd

Setelah kamu membuat atau mengubah sebuah berkas .service, systemd tidak otomatis sadar — versi lamanya masih tersimpan di memori. Jalankan sudo systemctl daemon-reload supaya dia membaca ulang berkas-berkas unit, lalu start atau restart service-mu. Lupa daemon-reload sehabis mengedit adalah salah satu kesalahan “tapi kan udah aku ubah dan nggak ada yang berubah” yang paling sering terjadi. Edit berkas → daemon-reload → restart. Urutan itu, tiap kali.

Berkas-berkas ini tinggal di mana? Unit yang dikelola sistem (yang dipasang oleh paket) ada di /usr/lib/systemd/system/ atau /lib/systemd/system/. Unit yang kamu buat atau timpa ditaruh di /etc/systemd/system/. Patokannya: jangan ganggu folder paket dan taruh berkasmu sendiri di /etc/systemd/system/, karena itulah direktori yang memang diperuntukkan bagi administrator — yaitu kamu.

Membaca log dengan journalctl

systemd bukan cuma menjalankan service-mu; dia juga menangkap segala yang mereka cetak. Apa pun yang ditulis sebuah service ke output-nya dikumpulkan ke sebuah log sistem terpusat bernama journal, dan kamu membacanya dengan perintah pendamping, journalctl. Ini sangat memudahkan: kamu tidak perlu berkeliaran di filesystem mencari berkas log, karena systemd sudah menangkap output-nya untukmu.

Beberapa pola ini mencakup hampir semuanya:

# Log untuk satu service, yang terbaru di bawah.
journalctl -u app

# Ikuti secara langsung — seperti tail -f — untuk memantau saat hal terjadi.
journalctl -u app -f

# Cuma baris paling baru (di sini, 50 baris terakhir).
journalctl -u app -n 50

# Semua sejak boot terakhir saja.
journalctl -u app -b

Flag -u adalah yang penting: dia menyaring journal jadi tinggal satu unit, jadi alih-alih semua pesan dari seluruh mesin, kamu hanya melihat service yang kamu pedulikan. Ketika status sebuah service bilang failed, langkah berikutnya persis adalah journalctl -u app -n 50 untuk membaca alasannya. Sembilan dari sepuluh kali, error-nya ada di situ — salah ketik di sebuah path, sebuah port yang sudah dipakai, sebuah berkas yang hilang.

Kenapa ini penting buat menjalankan apa pun secara online

Mundur sebentar, intinya systemd itu sederhana: dia adalah pembeda antara program yang harus kamu jaga terus dan service yang mengurus dirinya sendiri. Tanpa init system, kamu bakal menjalankan aplikasimu manual di sebuah terminal, dan begitu terminal itu ditutup, server di-reboot, atau program-nya crash, situsmu padam dan tetap padam sampai ada manusia yang sadar. systemd mengeluarkan manusia dari putaran itu. Dia menjalankan service-mu saat mesin boot, menghidupkannya lagi saat mereka tumbang, menjalankannya di bawah user yang benar, dan menyimpan log rapi yang bisa kamu baca belakangan.

Hampir setiap deployment nyata di server Linux, dari proyek sampingan mungil sampai infrastruktur produksi yang serius, bersandar pada systemd untuk menjaga semuanya tetap hidup. Kamu tidak perlu jadi ahli soal semuanya. Tahu apa itu service unit, beda antara start dan enable, serta cara mengecek status dan log saja sudah mencakup mayoritas besar dari yang bakal benar-benar kamu kerjakan. Kalau kamu masih samar soal apa itu “service” atau “proses” yang berjalan lama di balik semua ini, ada baiknya kamu nyaman dulu di command line, karena setiap perintah systemd hidup di sana — dan gambaran lebih luas soal kenapa Linux menguasai server adalah sebagian dari alasan kenapa systemd memang layak dipelajari.

Penutup

Intinya, dirangkum dalam satu tempat:

systemd adalah init system di sebagian besar server Linux modern — proses 1, program yang melakukan boot pada mesin dan mengawasi segala yang berjalan di atasnya.
Dia mengelola unit; jenis sehari-harinya adalah unit .service, sebuah program yang berjalan lama dan dijelaskan oleh satu berkas teks biasa.
Kamu mengendalikannya dengan systemctl: status, start, stop, restart, dan reload. Jalankan status lebih dulu setiap kali ada yang rusak.
enable ≠ start. Start menjalankannya sekarang; enable membuatnya kembali setelah reboot. Pakai enable --now untuk dua-duanya.
Baris Restart=on-failure pada berkas .service memberimu penyembuhan otomatis — systemd diam-diam menghidupkan kembali service yang crash.
Setelah mengedit berkas unit, jalankan daemon-reload sebelum restart, dan baca apa yang terjadi dengan journalctl -u <service>.

Begitu service bisa jalan, tetap hidup, dan bertahan melewati reboot dengan sendirinya, pertanyaan berikutnya yang wajar adalah soal dunia di sekitar proses itu — variabel tempat dia membaca konfigurasinya, dan cara kamu menjangkau mesin itu sejak awal untuk mengelola semua ini dari jarak jauh.