Kesiapan Jaringan systemd - Memahami Janji network-online.target

Ditulis oleh Adam Muiz 25 Sep 2026 Diperbarui: 25 Sep 2026 8 menit baca

Sebuah service mulai berjalan saat boot, mencoba menghubungi endpoint remote, lalu gagal karena mesin belum selesai memperoleh alamat. Menambahkan After=network.target tampak seperti perbaikan yang jelas. Namun, kegagalan yang sama kembali muncul ketika respons DHCP berikutnya lambat. Sebenarnya apa yang dijanjikan oleh dependency tersebut?

Pada server Debian yang dikelola systemd, “jaringan sudah aktif” bukanlah satu keadaan universal. Itu bisa berarti network manager telah dimulai, sebuah interface memiliki alamat, route tersedia, DNS berfungsi, atau satu service remote tertentu merespons. Kondisi-kondisi tersebut dapat terjadi pada waktu berbeda, dan konektivitas bisa kembali hilang setelah boot. Karena itu, tugas yang berguna bukan mencari target ajaib. Kita perlu menyatakan kondisi terkecil yang benar-benar dibutuhkan aplikasi dan menentukan apakah boot harus menunggunya.

Tiga target menggambarkan tiga momen berbeda

systemd menyediakan network-pre.target, network.target, dan network-online.target, tetapi nama-namanya mudah dibaca seperti progress bar. Panduan sinkronisasi jaringan upstream memberi ketiganya makna yang lebih sempit.

`network-pre.target`: sebelum konfigurasi dimulai

Target pasif ini terutama tersedia untuk software yang harus berjalan sebelum interface dikonfigurasi, misalnya setup firewall. Service yang membutuhkan urutan ini menarik target tersebut ke dalam transaksi dan menempatkan dirinya sebelum target. Client dan server jaringan biasa umumnya tidak memiliki alasan untuk menggunakannya.

`network.target`: management stack sudah dimulai

network.target tidak menjanjikan bahwa interface fisik telah muncul, DHCP telah selesai, atau alamat IP sudah dapat digunakan. Manual systemd.special(7) Debian menyebut maknanya saat startup didefinisikan secara longgar. Nilainya yang lebih jelas terlihat saat shutdown: service yang diurutkan setelah target ini akan dihentikan sebelum network stack dimatikan sehingga koneksi yang ada dapat ditutup dengan lebih rapi.

Karena itu, fragmen berikut menyatakan urutan terhadap network stack, bukan kesiapan alamat:

[Unit]
After=network.target

Jika sebuah client sama sekali tidak dapat mulai tanpa konfigurasi jaringan awal, baris ini belum cukup.

`network-online.target`: ambang startup yang dikonfigurasi telah tercapai

network-online.target adalah target aktif untuk unit yang benar-benar memerlukan jaringan terkonfigurasi saat startup. Target ini dapat menarik wait service ke dalam transaksi boot dan menunda pekerjaan yang bergantung padanya sampai service tersebut selesai. Ambang persisnya sengaja diserahkan kepada network manager dan konfigurasi lokal. Jadi, target ini adalah titik sinkronisasi, bukan definisi akses Internet yang berlaku untuk semua vendor.

Target ini juga hanya merupakan konsep satu kali saat boot. Manual Debian secara eksplisit menyatakan bahwa target tersebut tidak melacak status online sistem setelah boot. Kabel bisa dicabut, route bisa hilang, atau API remote bisa gagal setelah target aktif. Service yang harus bertahan menghadapi kejadian tersebut tetap memerlukan error handling saat runtime.

`Wants=` dan `After=` menyelesaikan masalah yang berbeda

Untuk service yang benar-benar membutuhkan ambang saat boot, pola yang didokumentasikan systemd adalah:

[Unit]
Wants=network-online.target
After=network-online.target

Kedua baris tersebut tidak berlebihan. Menurut systemd.unit(5), Wants= menarik unit yang disebutkan secara lemah ke dalam transaksi yang sama. Directive itu tidak menentukan urutan. After= menentukan urutan jika kedua unit dijalankan, tetapi tidak menarik unit lain ke dalam transaksi. Menggunakan After= saja dapat mengurutkan service di belakang target yang tidak pernah diminta; menggunakan Wants= saja memungkinkan kedua job berjalan tanpa urutan yang dimaksud.

Requires=network-online.target bukan sekadar ejaan yang “lebih aman”. Requires= menciptakan keterikatan lifecycle yang lebih kuat, sedangkan online target tetap tidak mewakili konektivitas secara terus-menerus. Pola Wants= yang umum tetap mengizinkan service mulai jika wait unit gagal atau timeout, lalu aplikasi dapat melaporkan atau mencoba kembali operasi sebenarnya. Aplikasi tertentu mungkin memerlukan perilaku yang lebih ketat, tetapi keputusan itu seharusnya berasal dari kontrak kegagalannya, bukan dari kata “online”.

Implementasi wait menentukan arti “online”

Target itu sendiri tidak memeriksa interface. Service khusus network manager berjalan sebelumnya. Pada instalasi Debian yang umum, service tersebut bisa berupa NetworkManager-wait-online.service atau systemd-networkd-wait-online.service. Mengaktifkan service yang salah tidak membuat network manager lainnya selesai lebih cepat.

Dengan systemd-networkd, wait service default menunggu managed link selesai dikonfigurasi atau gagal, serta setidaknya satu link berstatus online. Manual systemd-networkd-wait-online(8) Debian menetapkan ambang online default sebagai operational state minimal degraded. Instance khusus interface dan opsi seperti --any, --ipv4, serta --ipv6 dapat mengubah kondisinya. Network file juga dapat memengaruhi apakah sebuah link diwajibkan untuk status online.

NetworkManager memakai model berbeda. Dokumentasi wait-online-nya menyatakan bahwa target ditunda sampai NetworkManager melaporkan startup selesai melalui D-Bus. Connection profile, pengaturan address family, percobaan aktivasi ulang, pemindaian Wi-Fi, dan penantian carrier Ethernet ikut menentukan titik tersebut. Untuk profile dengan IPv4 dan IPv6 aktif, perilaku default dapat menganggap perangkat sudah aktif ketika salah satu family siap. Ini adalah semantik NetworkManager, bukan aturan operational state systemd-networkd.

Kedua implementasi tersebut tidak dapat menebak kontrak setiap aplikasi. Route yang sudah dikonfigurasi tidak membuktikan bahwa sync.example.net dapat di-resolve atau merespons. Sebaliknya, kegagalan sementara endpoint tersebut tidak selalu berarti interface lokal salah konfigurasi.

Periksa sebelum menambahkan dependency

Mulailah dengan mengenali network manager dan wait unit yang sudah ada. Command berikut bersifat read-only:

systemctl is-active NetworkManager.service systemd-networkd.service
systemctl is-enabled NetworkManager-wait-online.service \
  systemd-networkd-wait-online.service
systemctl status network-online.target
systemctl list-dependencies --reverse network-online.target

Wait service yang enabled hanyalah satu bukti. Status itu tidak menunjukkan bahwa transaksi boot tertentu menarik network-online.target, dan juga tidak membuktikan bahwa definisinya sesuai dengan aplikasi. Periksa pula consumer dan wait service:

systemctl cat example-sync.service
systemctl cat NetworkManager-wait-online.service
systemd-analyze critical-chain network-online.target
journalctl --boot --unit=NetworkManager-wait-online.service

example-sync.service adalah placeholder. Ganti dengan unit sebenarnya dan wait service yang digunakan host tersebut. Critical chain dan journal dapat memperlihatkan bagian boot yang menunggu, tetapi keduanya tidak membuktikan kesiapan DNS atau aplikasi remote.

Tambahkan penantian saat boot hanya untuk pekerjaan yang benar-benar ketat

Anggap sebuah job sinkronisasi one-shot tidak berguna tanpa konfigurasi jaringan awal dan dapat melaporkan kegagalan dengan aman jika operasi remotenya tetap tidak berhasil. Drop-in lokal dapat menyatakan startup dependency tanpa menyalin seluruh unit milik package:

sudo systemctl edit example-sync.service

[Unit]
Wants=network-online.target
After=network-online.target

Setelah menyimpan, periksa unit gabungan dan verifikasi sintaksnya sebelum menjadwalkan pengujian nyata:

systemctl cat example-sync.service
systemd-analyze verify example-sync.service

Menguji jalur startup dapat mengganggu atau mengulang pekerjaan, sehingga waktunya perlu direncanakan berdasarkan efek samping aplikasi. Start yang berhasil hanya membuktikan bahwa percobaan tersebut selesai menurut perilaku exit unit itu sendiri. Hasil itu tidak mengubah target menjadi monitor konektivitas permanen.

Jangan mengganti readiness dengan sleep tetap

Menambahkan ExecStartPre=/usr/bin/sleep 30 mungkin menyembunyikan race pada satu boot dan membuang 30 detik pada boot lainnya. Command itu mengamati waktu yang berlalu, bukan kondisi yang dibutuhkan. Loop yang melakukan ping ke alamat publik memiliki ketidakcocokan serupa: keterjangkauan ICMP ke host tersebut tidak membuktikan DNS, TLS, credential, atau API yang dituju berfungsi, dan sebagian jaringan memblokir ICMP ketika service yang berguna tetap dapat dijangkau.

Jika satu endpoint adalah prasyarat sebenarnya, aplikasi biasanya menjadi tempat terbaik untuk menafsirkan kegagalannya. Aplikasi dapat membedakan error name resolution, connection refusal, kegagalan autentikasi, dan respons yang tidak valid. Service manager dapat menjadwalkan retry atau me-restart client yang gagal, tetapi batas percobaan, jeda, idempotency, dan alerting tetap perlu dirancang dengan sengaja. Menunggu selamanya hanya memindahkan outage ke urutan boot.

Pilih perilaku berdasarkan workload

Network server yang listen pada alamat wildcard atau lokal: umumnya mulai tanpa menarik network-online.target. Panduan systemd upstream secara khusus tidak menyarankan pemakaian luas target tersebut untuk software server yang dapat menerima koneksi lokal sebelum interface routable tersedia.
Client atau worker jangka panjang: mulai service lalu tangani kegagalan sementara dengan retry terbatas atau penanganan perubahan jaringan secara dinamis. Pendekatan ini juga mencakup outage yang terjadi beberapa jam setelah boot.
Client one-shot yang ketat: penggunaan Wants= dan After=network-online.target dapat menghindari race saat boot yang langsung dan dapat diperkirakan. Operasinya tetap membutuhkan timeout dan hasil kegagalan yang jujur.
Mount filesystem remote: biarkan mount tooling menyatakan network dependency miliknya. systemd sudah mengatur dependency online target untuk remote mount sehingga application service yang tidak terkait tidak perlu menciptakannya kembali.

Tetap ada pengecualian. Server yang dikonfigurasi untuk bind hanya ke satu alamat yang muncul belakangan dapat gagal ketika wildcard listener tidak gagal. Laptop dengan Wi-Fi opsional seharusnya tidak menahan seluruh jalur boot demi background sync yang tidak penting. Server dengan banyak interface mungkin hanya memedulikan satu management link, bukan port sekunder yang kabelnya terlepas. Kasus-kasus ini adalah alasan untuk memperjelas kontrak readiness, bukan untuk sekadar memberi label online atau offline pada seluruh mesin.

Kesimpulan

network.target menandai keberadaan network-management stack, sedangkan network-online.target dapat menunggu ambang startup terkonfigurasi yang ditentukan oleh network manager aktif. Memasangkan Wants= dengan After= sekaligus meminta ambang tersebut dan mengurutkan consumer setelahnya. Tidak satu pun pernyataan itu membuktikan bahwa DNS, Internet, atau service tertentu akan terus dapat dijangkau.

Service yang paling tangguh biasanya dapat mulai sebelum konektivitas sempurna, menjelaskan operasi yang gagal, dan pulih ketika jaringan berubah. Penantian saat boot tetap memiliki peran sah untuk client yang ketat dan resource remote, tetapi sebaiknya dipakai sebagai alat sinkronisasi yang sempit. Sebelum menambahkannya, ajukan pertanyaan yang lebih tepat daripada “apakah jaringan sudah aktif?”: kondisi persis apa yang dibutuhkan workload ini, dan apa yang harus terjadi ketika kondisi tersebut kemudian menghilang?