Cara Memperbaiki Sinkronisasi Waktu Linux Pakai Chrony dan NTP: Panduan Lengkap

Tolong ya, stop nganggep remeh soal jam di server. Aku udah buka ticket yang keliatannya sepele berkali-kali, dan tiap kali tetep bikin gemas. Gejalanya selalu nyamar jadi masalah lain: SSL certificate error padahal sertifikat barunya baru aja dipasang, cron jalan di jam yang salah, log tiba-tiba kosong di jam-jam tertentu, database replica selisih datanya, sampe error Kerberos yang bikin orang salah fokus ke password padahal password-nya bener-bener bener.

Dan bagian yang paling nyebelin? Waktu debug-nya bisa ngabisin berjam-jam, padahal root cause-nya cuma satu: sinkronisasi waktu nggak jalan. Ini bukan masalah sepele, bro. Nek sampeyan mikir “ah, cuma masalah jam”, sampeyan bakal kaget sendiri pas client nelpon gara-gara timestamp di log nggak nyambung. So, wis, artikel ini kita bikin lengkap — mulai dari cara fix time sync linux pakai chrony dan ntp, proses diagnosis-nya, perbaikannya, sampe langkah biar nggak kejadian dua kali.

Pertama, kita luruskan dulu kenapa ini penting banget buat production. Bayangno lagi: sampeyan baru aja ganti sertifikat SSL kemarin sore, terus jam 7 pagi client nelpon panik karena website-nya error sertifikat expired. Padahal sertifikat barunya masih berlaku setahun ke depan. Cek sana, cek sini, restart nginx, clear cache browser, tetap error. Ujung-ujungnya buka tanggal di server, dan… oalah, jam-nya mundur tiga jam. HTTPS handshake-nya gagal karena perbandingan waktu antara server dan client nggak masuk dalam validity period sertifikat. Nah, dari situ baru keliatan kalau sinkronisasi waktu itu fondasi yang gampang banget disepelekan. Ibarat jam dinding di kantor yang satu cepat lima menit, yang lain telat sepuluh — meeting selalu mulai sembarangan. Di server, yang jadi “meeting”-nya itu cron, log, dan validasi sertifikat.

Lalu kenapa ini bisa kejadian? Ada beberapa penyebab umum yang aku temuin berulang di lapangan. Paling sering: server virtual (VPS/KVM) yang nggak pernah dikonfigurasi NTP-nya sama sekali, karena asumsinya “udah default dari provider”. Kedua, daemon NTP lama (ntpd) yang nggak kompatibel atau nggak bisa jalan normal di lingkungan virtual. Ketiga, systemd-timesyncd yang cuma nyinkronin sekali pas boot terus diem. Keempat, firewall yang nutup port UDP 123 diam-diam. Kelima, makestep yang nggak diset, jadi chrony nggak berani ngoreksi offset yang gede karena takut bikin lompatan waktu yang mendadak.

Gejalanya emang nggak selalu kentara di awal. Selisih satu-dua detik, orang nggak ngerasa, aplikasi masih jalan normal. Tapi drift ini akumulatif — makin lama makin gede. Hardware clock di server murah bisa melenceng 10-30 detik per bulan, dan kalau environment production kamu peka terhadap timestamp (log, cron, database replication, sertifikat, session token), ini bakal jadi bom waktu. Aku pernah nanganin Galera cluster yang nggak mau join cuma karena satu node jam-nya selisih lebih dari 5 detik. Ticket-nya bukan “jam beda”, tapi “node gagal sync”. Nah, mulai kebayang kan kenapa judulnya beneran — fix time sync linux itu hal yang wajib kamu pahami dari sekarang, bukan nanti pas udah kejadian.

Sebelum nyemplung ke command-command, satu hal yang wajib kamu paham: bedanya NTP dan chrony. NTP itu protokol sekaligus nama daemon lamanya (ntpd). Chrony itu implementasi yang lebih modern — protokolnya tetep NTP, tapi cara kerjanya jauh lebih cerdas buat lingkungan virtual. Kenapa? Karena chrony ngerti VM clock bisa melompat-lompat, bisa di-freeze pas live migration, dan bisa diskew-kan sama host. Chrony punya algoritma buat mendeteksi anomali kayak gitu dan nggak gampang panic. Di Ubuntu 22.04 ke atas sama Rocky/Alma 9, chrony udah jadi default. Tapi masih banyak server lama yang nempel di ntpd atau malah nggak punya daemon sama sekali. Kalau kamu lagi berencana migrasi server atau udah pindahan akhir-akhir ini, jangan lupa urusan jam ini — baca juga panduan migrasi VPS KVM zero-downtime kami biar nggak ada step yang kelewat.

Step 1: Diagnosa Sinkronisasi Waktu Dulu, Jangan Asal Ganti

Ini kesalahan yang paling sering aku lihat: orang langsung uninstall chrony, ganti pake ntp, padahal masalahnya bukan di daemon-nya. Diagnosa dulu. Buka SSH ke server kamu, terus jalanin:

date
timedatectl status

Lihat output-nya. Yang perlu kamu perhatiin: baris Time zone, System clock synchronized, dan NTP service. Kalau NTP service-nya inactive dan system clock-nya nggak synchronized, di situ masalahnya mulai keliatan. Ini contoh output yang sehat:

               Local time: Mon 2026-08-03 09:15:22 WIB
           Universal time: Mon 2026-08-03 02:15:22 UTC
                 RTC time: Mon 2026-08-03 02:15:22
                Time zone: Asia/Jakarta (WIB, +0700)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Poin penting dari output di atas:

• System clock synchronized: yes — berarti ada daemon yang nyinkronin jam dan berhasil.
• NTP service: active — systemd udah ditugasi ngatur NTP.
• RTC in local TZ: no — hardware clock (RTC) dalam UTC. Ini yang disaranin buat Linux, jangan pernah diset ke zona lokal.

Nah, kalau output kamu beda dari ini — misalnya synchronized-nya no — kita lanjut cek daemon mana yang lagi jalan. Jalanin:

systemctl list-units --type=service | grep -E "chronyd|ntpd|ntp|systemd-timesyncd"

Atau kalau mau lebih jelas, cek satu-satu:

systemctl status chronyd
systemctl status systemd-timesyncd
systemctl status ntpd

Biasanya kamu bakal dapet salah satu dari tiga skenario:

• chronyd active — tinggal cek konfigurasi dan sumber waktunya.
• systemd-timesyncd active — ini bisa kerja, tapi buat production aku saranin pindah ke chrony.
• Semua inactive — nah ini baru masalah. Artinya server kamu nggak punya daemon sinkronisasi waktu sama sekali.

Kadang ada juga kasus dua daemon jalan bareng — misal chronyd dan systemd-timesyncd — yang saling rebutan ngatur jam. Ini bikin clock-nya jittery dan harus dibenerin dengan mastiin cuma satu yang aktif. Oke, dari sini kita tau mau ke mana. Kalau daemon-nya udah ada tapi nggak sinkron, lanjut ke Step 2 buat cek konfigurasinya.

Step 2: Pastikan Cuma Satu Daemon yang Jalan

Kalau ternyata systemd-timesyncd yang lagi jalan dan kamu mau pindah ke chrony — rekomendasi buat production — matiin dulu yang lama. Tapi inget: setiap aksi yang stop service itu punya risiko di environment production. Makanya backup dan verifikasi dulu sebelum lanjut.

Kalau systemd-timesyncd yang jalan, matiin dan disable (disable itu biar nggak nyala lagi pas boot):

sudo systemctl stop systemd-timesyncd
sudo systemctl disable systemd-timesyncd

Buat yang masih pakai ntpd (CentOS 7 / Ubuntu lama), matiin juga:

sudo systemctl stop ntpd
sudo systemctl disable ntpd

Setelah itu pastikan nggak ada daemon lain yang nyala: systemctl status chronyd harusnya nunjukin inactive karena kita belum nyalain chronyd-nya. Titik fokusnya satu: nggak boleh ada daemon NTP lain yang nyala. Lanjut install chrony di step berikut.

Step 3: Install Chrony

Cara install-nya beda-beda tergantung distro. Pilih yang cocok sama server kamu:

Ubuntu / Debian:

sudo apt update
sudo apt install chrony -y

Rocky / AlmaLinux / CentOS 8 ke atas:

sudo dnf install chrony -y

CentOS 7 / RHEL 7:

sudo yum install chrony -y

Setelah install, aktifkan dan start:

sudo systemctl enable --now chronyd
sudo systemctl restart chronyd

Restart di sini aman karena kita baru aja install, dan konfigurasi masih default bawaan package. Tapi kalau kamu udah pernah edit konfigurasi sebelumnya, selalu backup dulu sebelum restart (lihat warning box di Step 2).

Step 4: Konfigurasi chrony.conf

File konfigurasi chrony ada di /etc/chrony/chrony.conf. Buka pake editor favorit kamu:

sudo nano /etc/chrony/chrony.conf

Contoh minimal yang aku rekomendasikan buat server production, lengkap dengan penjelasannya:

# Sumber waktu — pool NTP terdekat, pake iburst biar cepat sinkron pas boot
pool 0.id.pool.ntp.org iburst
pool 1.id.pool.ntp.org iburst
pool 2.id.pool.ntp.org iburst

# Step otomatis kalau offset gede. makestep 1 3 artinya step kalo offset > 1 detik,
# maksimal 3x di 3 update pertama. Penting buat VM yang jam-nya jauh meleset.
makestep 1 3

# Kalau offset rata-rata naik terus, 1 detik udah termasuk gede buat production.
maxdistance 16.0

# Opsional: jadikan server ini sumber waktu buat LAN
# allow 10.10.10.0/24
# local stratum 10

# Logging biar gampang di-audit
logdir /var/log/chrony
log measurements statistics tracking

Penjelasan singkat beberapa directive penting:

• pool ... iburst — sumber waktu. Buat Indonesia, pool lokal id.pool.ntp.org; buat server global, pool ntp.org bawaan udah cukup. iburst itu biar sinkronisasi cepat di awal (burst request di beberapa detik pertama).
• makestep 1 3 — ini paling penting buat VM. Tanpa ini chrony cuma nylewskan jam pelan-pelan, dan kalau offset-nya 30 detik, butuh waktu lama banget. Dengan makestep, kalau offset di atas 1 detik di 3 update pertama, jam langsung di-step (lompat) ke waktu yang bener.
• maxdistance 16.0 — chrony bakal nolak sumber waktu yang terlalu jauh alias lagging. Nilai default 16 detik udah oke buat mayoritas kasus.

Setelah edit, simpan file. Verifikasi dulu konfigurasinya — jangan langsung restart buta:

sudo chronyd -f /etc/chrony/chrony.conf -q
sudo systemctl restart chronyd
sudo systemctl status chronyd

Command chronyd -f -q itu nge-load config dalam mode non-daemon, ngecek baris yang salah (muncul warning Unknown directive), terus keluar sendiri. Setelah restart, status harusnya active (running).

Step 5: Verifikasi Sinkronisasi

Bagian ini yang paling sering dilewatin orang. Padahal verifikasi itu yang bikin kamu yakin fix-nya bener-bener jalan. Dua command paling penting: chronyc tracking dan chronyc sources -v.

Pertama, cek tracking:

chronyc tracking

Contoh output yang sehat:

Reference ID    : 203.0.113.10 (ntp1.id.pool.ntp.org)
Stratum         : 2
Ref time (UTC)  : Mon Aug 03 02:15:22 2026
System time     : 0.000034 seconds slow of NTP time
Last offset     : +0.000021 seconds
RMS offset      : 0.000031 seconds
Frequency       : -0.415 ppm slow
Residual freq   : +0.001 ppm
Skew            : 0.002 ppm
Root delay      : 0.021012 seconds
Root dispersion : 0.002456 seconds
Update interval : 1024.3 seconds
Leap status     : Normal

Mari kita baca baris per baris, karena banyak orang cuma liat Reference ID terus langsung tutup:

• Reference ID — sumber waktu yang lagi dipake. Kalau ini nunjukin nama pool (di contoh di atas IP-nya udah aku samarin), berarti chrony udah dapet sumber.
• Stratum: 2 — server kamu dua hop dari jam atomik. Ini normal dan sehat. Nilai di atas 5-6 biasanya sinyal jaringan jelek atau sumber nggak akurat.
• System time: 0.000034 seconds slow — selisih jam kamu vs sumber NTP cuma 34 mikrodetik. Bagus banget.
• Leap status: Normal — nggak ada leap second pending. Kalau muncul Insert second atau Delete second, biasanya cuma di bulan Juni/Desember, nggak perlu panik.

Terus cek daftar sumber:

chronyc sources -v

  .-- Source mode  '^' = server, '=' = peer, '#' = local clock.
 / .- Source state '*' = current synced, '+' = combined , '-' = not combined,
|/   '?' = unreachable, 'x' = time may be in error, '~' = time too variable.
||                                                 .-+-+-+-+-+-+-+-+-+-+-+-
||  MS Name/IP address          Stratum Poll Reach LastRx Last sample
==============================================================================
^* ntp1.id.pool.ntp.org              2   6   377    35  +111us[ +164us] +/- 11ms
^+ ntp2.id.pool.ntp.org              2   6   377    35  +202us[ +254us] +/- 12ms
^+ ntp3.id.pool.ntp.org              2   6   377    35  -156us[ -150us] +/- 13ms

Baca kolom-kolomnya:

• Simbol ^ di kolom mode — baris yang diawali ^* itu sumber yang lagi dipake utama. Tanda * di kolom state artinya dia yang lagi jadi referensi. Kalau nggak ada * sama sekali, artinya belum sinkron.
• Reach: 377 — nilai octal ini bagus banget, artinya 8 dari 8 polling terakhir sukses. Kalau nilainya menurun kayak 7, 3, 1, atau 0, berarti ada paket yang hilang — kemungkinan firewall atau routing.
• Last sample — selisih waktu terakhir. Angka dengan tanda +/- di range milidetik itu sehat. Kalau konsisten +500ms ke atas, mulai curiga.

Kalau output-nya kayak gitu, berarti sinkronisasi jalan. Cek sekali lagi pake timedatectl:

timedatectl status

Sekarang System clock synchronized: yes dan NTP service: active. Selamat, bagian tersulit udah lewat.

Step 6: Set Zona Waktu dan Hardware Clock

Time sync baru tuntas kalau zona waktunya juga bener. Ini yang sering bikin bingung: jam UTC-nya udah sinkron, tapi aplikasi kelihatan jalan di jam yang salah karena timezone-nya kacau. Set zona waktu sesuai lokasi server kamu:

sudo timedatectl set-timezone Asia/Jakarta
# atau Asia/Makassar, Asia/Pontianak, dst sesuai lokasi
timedatectl status

List zona waktu: timedatectl list-timezones. Jangan lupa pastikan RTC jalan di UTC, bukan lokal:

sudo timedatectl set-local-rtc 0
sudo hwclock --systohc

hwclock --systohc itu nyimpen waktu sistem ke hardware clock. Penting buat server fisik; buat VM, hardware clock biasanya virtual dan lebih baik di-manage host, tapi command ini nggak ada salahnya dijalanin.

Step 7: Buka Firewall untuk NTP

Kalau chrony udah install, konfigurasi udah bener, tapi chronyc sources tetap keluar tanda tanya di state, hampir bisa dipastiin firewall yang nutup port. NTP jalan di UDP port 123, dan banyak server baru — terutama yang pake UFW atau firewalld default deny — nutup port ini.

UFW (Ubuntu/Debian):

sudo ufw allow out 123/udp comment 'ntp client'
sudo ufw allow 123/udp comment 'ntp server'

firewalld (Rocky/Alma/CentOS):

sudo firewall-cmd --add-service=ntp --permanent
sudo firewall-cmd --reload

CSF (kalau pakai cPanel/WHM):

# Edit /etc/csf/csf.conf, tambahkan port 123 ke UDP_IN dan UDP_OUT,
# lalu jalankan:
csf -r

Perhatiin: kalau server kamu cuma jadi client NTP (paling umum), sebenarnya cuma butuh outbound UDP 123. Inbound cuma perlu kalau server kamu jadi sumber waktu buat server lain. Tapi banyak tutorial nulis dua-duanya, biar aman dan fleksibel.

Step 8: Tabel Troubleshooting

Ini tabel yang aku harap ada waktu aku masih junior dulu. Tandain page ini atau save, karena 80% kasus time sync ada di tabel ini:

Kalau kamu udah lewatin semua step di atas dan masih ada yang aneh, cek log chrony. Log-nya ada di /var/log/chrony/chronyd.log. Ini contoh potongan log yang harusnya kamu perhatiin:

2026-08-03 02:14:01Z chronyd version 4.3 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS +NTS +LEAPSECMOM +SUNWARN)
2026-08-03 02:14:01Z chronyd using configuration from /etc/chrony/chrony.conf
2026-08-03 02:14:01Z Listening on UDP port 123
2026-08-03 02:14:01Z Initial frequency -415.300 ppm
2026-08-03 02:14:06Z System clock wrong by 42.3 seconds, adjustment started
2026-08-03 02:14:06Z System clock was stepped by 42.3 seconds
2026-08-03 02:14:36Z Selected source 203.0.113.10 (ntp1.id.pool.ntp.org)
2026-08-03 02:15:06Z Source 203.0.113.10 (ntp1.id.pool.ntp.org) is reachable
2026-08-03 02:15:07Z System clock wrong by 0.0003 seconds, adjustment started
2026-08-03 02:15:07Z System clock was slewed by 0.0003 seconds
2026-08-03 02:15:10Z Source 203.0.113.11 (ntp2.id.pool.ntp.org) is reachable

Baca alurnya dari atas ke bawah — ini pola yang sehat:

• Baris 5-6: System clock wrong by 42.3 seconds terus System clock was stepped — ini kerja-nya makestep. Jam meleset 42 detik, langsung dilompatin. Kalau nggak ada baris stepped, artinya makestep nggak ke-trigger dan jam cuma di-slew pelan-pelan.
• Baris 7: Selected source — chrony udah milih sumber terbaik.
• Baris 8 & 10: is reachable — sumber-sumber udah bisa dijangkau. Kalau di baris ini malah ada unreachable, itu firewall atau routing.

Kenapa Virtual Machine Paling Sering Kena

Satu topik lagi yang sayang dilewatkan: kenapa VM selalu jadi korban utama masalah ini. Di hypervisor KVM, mesin virtual itu menjalankan software clock sendiri yang diemulasi dari host. Pas host-nya sibuk (high CPU steal), guest clock-nya bisa berjalan lebih lambat dari real time. Pas live migration, clock-nya bisa di-pause atau malah maju mundur sesaat. Pas snapshot-restore, guest langsung dikembalikan ke masa lalu — dan kalau nggak ada daemon yang ngoreksi, dia bakal jalan terus dengan waktu yang salah. Chrony menangani semua skenario ini jauh lebih baik daripada ntpd atau systemd-timesyncd. Kalau kamu ngerasa server VPS kamu sering telat-maju sendiri, ini jawabannya. Dan kalau load-nya lagi tinggi-tingginya pas kejadian, cek juga troubleshooting high load server VPS — karena CPU steal dan time drift sering jalan barengan.

Pro Tips & Warnings dari Lapangan

Beberapa pelajaran yang aku dapet mahal — semoga kamu nggak perlu bayar semahal itu:

Satu lagi: kalau server kamu ada di belakang NTP server internal kantor (bukan langsung ke internet), samakan aja pool-nya dengan server internal itu dan pastikan port UDP 123 ke server internal nggak diblokir. Masalah reach = ? di network kantor biasanya cuma karena ada firewall aplikasi yang nutup NTP. Oh ya, kalau kamu suka ngulik log buat debugging, sekalian baca panduan analisa log Linux pakai journalctl dan artikel monitoring server VPS kami biar makin lengkap toolkit-nya.

Kesimpulannya sederhana: fix time sync linux chrony ntp itu bukan cuma soal bikin jam akurat, tapi soal konsistensi seluruh sistem kamu — log, sertifikat, cron, database, semuanya bergantung pada timestamp yang bisa dipercaya. Kalau udah pernah kena sekali, kamu bakal paham kenapa engineer senior selalu ngecek timedatectl duluan sebelum nge-debug apa pun.

Gimana, masih ngerasa soal jam server itu sepele? Pelajarin lagi step di atas, save artikel ini, dan sebelum kamu close ticket atau mulai debugging, cek dulu tiga hal: (1) timedatectl status, (2) chronyc sources -v, (3) chronyc tracking. Tiga command ini udah cukup buat mastiin sync-nya sehat. Tolong jangan sampe server production kamu jadi korban berikutnya gara-gara hal yang sebenarnya cuma butuh satu baris konfigurasi. Take it seriously, ya.