Cara Memperbaiki Jam VPS yang Tidak Sinkron

Mengapa jam VPS Anda mengalami drift

Jam VPS mengalami drift karena tidak ada mekanisme yang mengoreksinya. Kernel menghitung waktu dari pencacah perangkat keras yang berjalan sedikit lebih cepat atau sedikit lebih lambat. Jika tidak ada klien sinkronisasi waktu yang berjalan, kesalahan kecil itu akan bertambah setiap jam. Di dalam mesin virtual, ada penyebab kedua: guest berbagi CPU fisik dengan guest lain. Karena itu, saat guest tidak mendapatkan penjadwalan, guest tidak dapat menghitung waktu.

Pada guest KVM saat ini, pencacah itu sendiri jarang menjadi masalah sebenarnya. Sumber kvm-clock paravirtual membaca nilai yang dikelola host, sehingga guest yang sehat dapat mengikuti waktu host dengan baik. Jam yang terlihat salah biasanya bermasalah karena alasan yang lebih sederhana. Tidak ada daemon sinkronisasi yang berjalan, atau ada dua daemon yang berjalan dan saling mengganggu, atau port UDP keluar 123 tidak pernah keluar dari jaringan provider Anda. Guest mendapatkan disiplin waktunya dari host atau dari NTP (network time protocol), bukan dari osilatornya sendiri.

Yang benar-benar rusak akibat jam yang salah

• Kode autentikasi dua faktor TOTP (time-based one-time password) tidak lagi cocok, sehingga Anda terkunci dari server meskipun password dan key sudah benar.
• Sertifikat yang diterbitkan satu menit lalu ditolak, dan curl mencetak SSL certificate problem: certificate is not yet valid.
• apt update menolak repository dengan E: Release file for ... is not valid yet (invalid for another 1d 2h 3min 4s).
• Pekerjaan terjadwal dijalankan pada waktu yang salah. Lompatan waktu pada jam dapat membuat satu pekerjaan berjalan dua kali, sementara pekerjaan lain terlewat.
• Log dari dua server tidak dapat diselaraskan. Akibatnya, kronologi insiden harus disusun berdasarkan perkiraan.

Toleransinya lebih kecil daripada yang diperkirakan kebanyakan orang. Angka di bawah ini adalah default yang didokumentasikan, bukan hasil pengukuran dari pengujian.

[
  {
    "label": "TLS certificate boundary",
    "tolerance_seconds": 0,
    "documented_in": "RFC 5280"
  },
  {
    "label": "chrony steps instead of slewing",
    "tolerance_seconds": 1,
    "documented_in": "Debian and Ubuntu chrony.conf"
  },
  {
    "label": "TOTP code, one time step",
    "tolerance_seconds": 30,
    "documented_in": "RFC 6238"
  },
  {
    "label": "Kerberos clock skew",
    "tolerance_seconds": 300,
    "documented_in": "MIT krb5 default"
  }
]

Kode TOTP dihitung dari counter yang bertambah setiap 30 detik, dan sebagian besar verifier menerima satu langkah sebelum atau sesudahnya. Kesalahan setengah menit ke salah satu arah sudah menghabiskan seluruh toleransi. Kerberos jauh lebih longgar, dengan toleransi skew default sebesar 300 detik. Sertifikat sama sekali tidak memiliki toleransi seperti itu: sertifikat diperiksa terhadap waktu tertentu dengan masa kelonggaran 0 detik. Karena itu, jam yang terlambat satu detik dapat menolak sertifikat yang sebenarnya masih valid.

Tiga jam dan jam yang penting

Jam sistem adalah jam yang penting. Jam ini merupakan CLOCK_REALTIME kernel: jumlah detik sejak 1 Januari 1970 UTC yang disimpan di memori dan dibaca oleh semua komponen yang mencatat waktu. Baris log, pemeriksaan sertifikat, kode TOTP, dan waktu modifikasi file semuanya berasal dari jam ini. Jika seseorang mengatakan waktu server salah, jam inilah yang dimaksud.

Jam perangkat keras, yang juga disebut RTC (real time clock), adalah penghitung terpisah yang terus berjalan saat mesin dalam keadaan mati. Pada mesin fisik, jam ini berupa chip yang mendapat daya dari baterai. Di dalam guest, jam ini diemulasikan oleh hypervisor sehingga sebagian besar hanya merupakan artefak host. Linux membacanya sekali saat boot untuk mendapatkan nilai awal, lalu mempertahankan penghitungnya sendiri. timedatectl menampilkannya pada baris RTC time. Jangan melakukan debugging berdasarkan baris tersebut pada VPS karena baris itu memberi tahu Anda waktu menurut host, bukan status sinkronisasi jam sistem Anda. Di dalam container biasanya tidak ada /dev/rtc sama sekali sehingga hwclock --show gagal dengan hwclock: Cannot access the Hardware Clock via any known method.

Sumber jam adalah sumber yang digunakan kernel untuk menghitung waktu di antara pembacaan tersebut. Tanyakan kepada kernel sumber yang dipilihnya:

cat /sys/devices/system/clocksource/clocksource0/current_clocksource
cat /sys/devices/system/clocksource/clocksource0/available_clocksource

Pada KVM, Anda biasanya akan melihat kvm-clock. Sumber ini membaca nilai yang dipelihara oleh host. Karena itu, guest KVM tanpa klien NTP pun masih tetap menunjukkan waktu yang kurang lebih benar selama beberapa waktu. tsc adalah penghitung milik CPU. Guest Xen melaporkan xen, sedangkan guest Hyper-V melaporkan sumber hyperv. Biarkan pengaturan ini apa adanya kecuali Anda memiliki alasan terukur untuk mengubahnya karena kernel sudah memilih sumber terbaik yang dipercaya pada perangkat keras tersebut.

Beberapa host juga meneruskan perangkat PTP (precision time protocol) ke guest sehingga chrony dapat membaca jam host secara langsung, bukan melalui jaringan. Perangkat ini patut diperiksa dan sering kali tidak tersedia pada VPS bersama:

sudo modprobe ptp_kvm
ls /dev/ptp*
cat /sys/class/ptp/ptp0/clock_name

Jika modprobe gagal atau tidak ada perangkat yang muncul, host Anda tidak menyediakannya dan NTP melalui jaringan adalah pilihan Anda. Jika clock_name menampilkan nama jam virtual KVM, chrony dapat menggunakannya dengan baris refclock PHC /dev/ptp0 poll 2 dalam konfigurasinya.

Baca status waktu pada mesin Anda sendiri

Mulai dengan satu perintah. Perintah ini menjawab pertanyaan "apakah ada sesuatu yang menjaga ketepatan clock ini" dalam satu layar.

timedatectl

Baca baris-baris ini. Jangan hanya mengandalkan angka yang Anda ingat:

• Local time dan Universal time adalah waktu yang sama, masing-masing ditampilkan dalam zona waktu Anda dan dalam UTC. Jika keduanya identik, mesin sudah menggunakan UTC.
• RTC time adalah hardware clock yang dijelaskan di atas. Pada VPS, abaikan nilai ini.
• Time zone adalah nilai yang digunakan sistem untuk memformat waktu lokal.
• System clock synchronized adalah flag milik kernel. Daemon waktu menetapkan flag ini setelah mempercayai sumber waktunya. Jadi, no berarti belum ada proses yang mengoreksi clock ini sejak boot.
• NTP service memberikan status khusus untuk systemd-timesyncd. n/a normal pada mesin yang menjalankan chrony karena timesyncd tidak terpasang di sana. System clock synchronized: yes bersama NTP service: n/a berarti chrony sedang menangani sinkronisasi dan kernel menyetujuinya.

Berikutnya, periksa seberapa besar perbedaannya. Jangan membandingkannya dengan melihat ponsel Anda. Jika chrony sedang berjalan:

chronyc tracking
chronyc sources -v

chronyc tracking menampilkan angka yang menjawab pertanyaan tersebut. System time adalah offset saat ini terhadap waktu NTP, diikuti kata fast atau slow. Last offset adalah besarnya koreksi terbaru. Frequency adalah galat laju yang diukur chrony pada clock Anda dan sudah dikompensasi. Leap status seharusnya menampilkan Normal. Jika menampilkan Not synchronised dan Reference ID bernilai 00000000 (), chrony belum menetapkan sumber waktu.

chronyc sources -v menampilkan keterangan di atas daftar. Dengan demikian, Anda tidak perlu mengingat simbol-simbolnya. Dua kolom memiliki sebagian besar informasi penting. Karakter status di awal setiap baris menunjukkan penilaian chrony terhadap sumber tersebut. * menandai sumber yang sedang digunakan. ? pada setiap baris berarti tidak ada sumber yang menjawab. Reach adalah riwayat respons dari 8 polling terakhir yang ditampilkan dalam oktal: 377 berarti semua 8 polling mendapat respons, sedangkan 0 berarti tidak satu pun mendapat respons.

Jika systemd-timesyncd yang menangani sinkronisasi:

timedatectl timesync-status
timedatectl show-timesync --all

timesync-status menampilkan server yang dihubungi, interval polling, dan nilai Offset. Jika perintah mengembalikan error tentang service, bukan menampilkan status, timesyncd bukan daemon yang menangani sinkronisasi pada mesin ini. Itu sendiri sudah menjawab pertanyaan Anda.

Untuk pemeriksaan kasar terhadap waktu eksternal tanpa alat tambahan, bandingkan clock Anda dengan header HTTP publik Date. Header ini disajikan dalam GMT dengan resolusi 1 detik:

date -u
curl -sI https://www.cloudflare.com | grep -i '^date:'

Perbedaan 1 atau 2 detik di sini normal dan tidak berarti apa-apa. Perbedaan 1 menit adalah masalah pada mesin Anda.

chrony atau systemd-timesyncd pada VPS

Ubuntu dan Debian menyediakan systemd-timesyncd secara default. Ini adalah klien SNTP (simple network time protocol): klien ini meminta waktu dari satu server pada satu waktu dan mengarahkan jam sistem ke waktu tersebut. Pada mesin yang selalu online dan sejak awal waktunya kurang lebih benar, ini sudah memadai dan hampir tidak memerlukan sumber daya.

chrony adalah implementasi NTP lengkap dan pilihan default yang lebih baik pada mesin virtual. Alasannya dapat dilihat dari output-nya sendiri. chrony melakukan polling ke beberapa sumber sekaligus dan membuang sumber yang memberikan waktu berbeda. chrony mengukur kesalahan laju jam sistem lalu menuliskannya ke drift file, sehingga chrony memperbaiki kecenderungan jam, bukan mengejar setiap sampel. chrony juga pulih dengan cepat dari dua kondisi yang dapat terjadi pada VM, tetapi tidak pada mesin fisik: VM dapat dijeda oleh host, dan VM dapat dipindahkan ke host lain saat sedang berjalan. Jika host menyediakan perangkat PTP, chrony yang membacanya.

sudo apt update && sudo apt install -y chrony
systemctl status chrony --no-pager
chronyc sources -v
chronyc tracking

Baca output apt saat proses berjalan. Pada Debian dan Ubuntu, paket chrony dan systemd-timesyncd sama-sama menyediakan time-daemon, sehingga apt menghapus timesyncd saat memasang chrony. Ini benar dan memang diinginkan. Jangan menjalankan keduanya, karena dua daemon yang mengatur jam yang sama akan saling bertentangan. Offset yang dilaporkan oleh keduanya juga tidak dapat dipercaya selama keduanya berjalan. Pada Rocky dan AlmaLinux, lakukan instalasi dengan sudo dnf install -y chrony. Pada sistem tersebut, nama unitnya adalah chronyd, bukan chrony.

File konfigurasi berada di /etc/chrony/chrony.conf pada Debian dan Ubuntu, serta di /etc/chrony.conf pada Rocky dan Alma. Default distribusi sudah sesuai untuk VPS, jadi ubah hanya jika ada alasan. Berikut dua direktif yang perlu dipahami:

• Baris pool dan server menentukan sumber waktu. Menambahkan iburst akan memerintahkan chrony mengirim burst cepat saat startup, sehingga sinkronisasi pertama selesai dalam hitungan detik, bukan menit.
• makestep menentukan kapan chrony mengubah jam secara langsung, bukan menyesuaikannya secara bertahap. Periksa nilainya dengan grep -n makestep /etc/chrony/chrony.conf. Default Debian dan Ubuntu, yaitu makestep 1 3, berarti sebagai berikut: selama tiga pembaruan pertama setelah chronyd dimulai, jam akan diubah langsung jika selisihnya lebih dari satu detik. Setelah itu, koreksi hanya dilakukan dengan slewing.

Jika Anda ingin trafik waktu diautentikasi untuk mencegah manipulasi di jalur jaringan, chrony 4 dan versi setelahnya mendukung NTS (network time security). Konfirmasikan versi Anda terlebih dahulu dengan chronyd -v. Perhatikan bahwa NTS memerlukan port TCP keluar 4460 yang terbuka selain UDP 123:

server time.cloudflare.com iburst nts

Lakukan restart dan verifikasi sebelum mempercayai konfigurasinya. Konfigurasi yang gagal diuraikan dapat membuat Anda tidak memiliki daemon waktu sama sekali, dan jam sistem tidak akan memberi tahu Anda tentang kondisi tersebut.

sudo systemctl restart chrony
chronyc sources -v
chronyc tracking

Mengapa jam yang meleset beberapa menit tetap meleset

Daemon waktu memiliki dua cara untuk memperbaiki offset. Slewing mempercepat atau memperlambat jam hingga kesalahan hilang. Cara ini membuat waktu terus bergerak maju dan tidak pernah mengulang atau melewati timestamp. Stepping langsung mengubah jam ke nilai yang benar. Cara ini cepat, tetapi dapat membuat jam bergerak mundur. Pergerakan mundur berbahaya bagi apa pun yang mengukur waktu berlalu dari jam dinding. Karena itu, kedua daemon lebih memilih slewing.

Preferensi tersebut menyebabkan jam yang sangat meleset dapat tetap salah dalam waktu lama. chrony hanya melakukan stepping dalam jendela yang diizinkan oleh makestep. Secara default, jendela ini hanya berlaku pada beberapa pembaruan pertama setelah daemon dimulai. Jika chronyd telah berjalan selama seminggu lalu menemukan kesalahan empat puluh detik, daemon akan melakukan slewing. Proses slewing selama empat puluh detik membutuhkan waktu jauh lebih lama daripada yang ingin Anda tunggu. Paksa koreksi satu kali pada waktu yang sengaja dipilih saat sistem sedang tidak sibuk:

sudo chronyc makestep
chronyc tracking

chronyc tracking sekarang seharusnya melaporkan offset System time yang mendekati nol. Last offset seharusnya menampilkan ukuran koreksi yang baru saja dilakukan. Pertimbangkan dampaknya sebelum menjalankan ini pada host database yang sedang sibuk. Perubahan jam ke waktu sebelumnya dapat membingungkan perangkat lunak yang mengasumsikan bahwa waktu hanya bergerak maju. Me-restart daemon adalah versi yang lebih aman dari perbaikan yang sama, karena jendela makestep kembali terbuka saat daemon dimulai.

Container berbagi jam host

Container tidak memiliki jam dinding sendiri, sehingga tidak ada yang perlu disinkronkan di dalamnya. Namespace waktu Linux hanya memvirtualisasi jam monotonik dan jam waktu boot. CLOCK_REALTIME tidak divirtualisasi, sehingga container membaca jam sistem yang sama dengan host tempat container tersebut berjalan. Perbaiki jam pada host, dan semua container pada host tersebut akan diperbaiki pada saat yang sama.

Beberapa konsekuensi muncul dari hal ini. Jangan menginstal chrony atau ntpd dalam image karena, paling baik, instalasi tersebut tidak melakukan apa pun. Pengaturan tanggal di dalam container tanpa hak istimewa gagal dengan date: cannot set date: Operation not permitted karena kernel memerlukan CAP_SYS_TIME untuk pemanggilan tersebut. Pemberian CAP_SYS_TIME tidak membuat container memiliki jam privat. Pemberian tersebut memungkinkan container mengubah jam host dan, akibatnya, jam semua container lain.

Zona waktu yang berbeda di dalam container bukan masalah jam. Image yang menyertakan /etc/localtime menampilkan waktu yang sama dengan format untuk zona lain, sehingga date tampak salah meskipun jamnya benar. Atur TZ=UTC di lingkungan container agar kebingungan tersebut hilang. Runtime yang Anda pilih tidak mengubah hal ini, dan perbandingan rootless Podman dan Docker menjelaskan hal-hal yang memang diubahnya.

Zona waktu: UTC pada server, waktu lokal untuk pengguna

Atur mesin ke UTC dan pertahankan pengaturan tersebut.

timedatectl list-timezones | grep -i utc
sudo timedatectl set-timezone UTC
timedatectl

UTC tidak memiliki daylight saving, dan itu sudah cukup menjadi alasannya. Job harian pada pukul 02:30 di zona yang menerapkan daylight saving akan berjalan dua kali pada hari ketika jam dimundurkan, dan tidak berjalan sama sekali pada hari ketika jam dimajukan. man 8 cron mendokumentasikan penanganan khusus untuk perubahan kurang dari tiga jam: job yang terlewat akibat lompatan maju akan dijalankan segera setelah perubahan, sedangkan job yang berada dalam jam berulang akibat lompatan mundur tidak dijalankan untuk kedua kalinya. Perilaku ini masuk akal, tetapi Anda tetap tidak perlu mempertimbangkannya pada pukul 03:00. Dengan UTC, job berjalan sekali sehari, setiap hari sepanjang tahun. Jika job Anda benar-benar tidak berjalan sama sekali, bukan hanya berjalan pada jam yang tidak biasa, alasan cron job tidak pernah berjalan secara diam-diam lebih mungkin menjadi penyebabnya.

Alasan yang sama berlaku saat membaca log. journalctl memformat timestamp berdasarkan zona waktu sistem, sedangkan journalctl --utc memaksa penggunaan UTC. Dua server di dua zona waktu mengubah setiap insiden menjadi pekerjaan konversi, dan konversi yang dilakukan dalam tekanan dapat menyebabkan orang salah membaca urutan waktu. Pertahankan sistem pada UTC, simpan timestamp dalam UTC, lalu lakukan konversi satu kali saat timestamp dibaca oleh manusia. Siapa pun yang memerlukan waktu lokal untuk satu perintah dapat memintanya tanpa mengubah waktu mesin:

TZ=Europe/Berlin date

Ada satu baris lagi dalam output timedatectl yang termasuk dalam bagian ini. RTC in local TZ seharusnya bernilai no. Menetapkan nilainya ke yes merupakan solusi sementara untuk dual-boot Windows pada laptop. Pada server, pengaturan tersebut hanya menambahkan offset yang dapat menimbulkan masalah di kemudian hari. Jika pengaturan itu aktif, timedatectl menampilkan peringatan bahwa sistem dikonfigurasi untuk membaca waktu RTC dalam zona waktu lokal.

Pemecahan masalah berdasarkan gejala

Kode autentikasi dua faktor Anda ditolak pada satu server. Periksa jam sebelum memeriksa hal lain. Kode tersebut berasal dari penghitung yang bertambah setiap 30 detik. Karena itu, server yang tertinggal 90 detik akan menghitung kode dari interval waktu yang sudah dilewati ponsel Anda. timedatectl akan menampilkan System clock synchronized: no, atau chronyc tracking akan melaporkan offset System time yang besar. Ini berbeda dari kegagalan ketika key ditolak secara langsung. Kegagalan tersebut menampilkan pesannya sendiri dan dibahas dalam panduan kegagalan autentikasi publickey.

apt update menyatakan bahwa file Release belum valid. Pesan lengkap mencantumkan repository dan durasi file tersebut tetap tidak valid, misalnya is not valid yet (invalid for another 1d 2h 3min 4s). Jam Anda tertinggal dari tanggal di dalam file Release repository. Durasi tersebut mengukur secara langsung seberapa jauh jam Anda tertinggal. Perbaiki jamnya. Jangan menonaktifkan pemeriksaan tanggal apt untuk melewati masalah ini, karena pemeriksaan tersebut mencegah seseorang menyajikan indeks paket yang sudah usang kepada Anda.

Setiap baris source menampilkan status tidak dapat dijangkau dan Reach bernilai 0. Tidak ada respons, jadi periksa koneksi keluar, bukan konfigurasi Anda. NTP menggunakan UDP port 123 untuk trafik keluar, dan beberapa jaringan memfilter atau mengalihkannya. sudo chronyc ntpdata menampilkan penghitung per-source, termasuk Total TX dan Total RX. Jumlah TX yang terus bertambah sementara RX tetap 0 berarti paket Anda keluar, tetapi tidak ada paket yang kembali. Ini mengarah pada firewall di antara Anda dan source tersebut.

Jam awalnya benar, lalu berubah secara tiba-tiba. Peristiwa pada host dapat menyebabkan hal ini. Snapshot yang dipulihkan, guest yang dijeda, atau live migration ke host lain dapat membuat waktu yang diketahui guest tertinggal dari waktu sebenarnya. chrony mendeteksinya pada polling berikutnya dan melakukan koreksi. systemd-timesyncd mungkin terlebih dahulu menunggu interval polling yang panjang berakhir. Pastikan daemon berjalan saat boot dengan systemctl is-enabled chrony, karena daemon yang dijalankan secara manual akan berhenti setelah reboot berikutnya.

Offset kecil, tetapi tidak pernah stabil. Periksa CPU steal. Guest yang tidak dijadwalkan saat interupsi timer seharusnya terjadi akan menerima sampel secara terlambat. Akibatnya, offset berubah-ubah dan tidak konvergen. top menampilkan kondisi ini sebagai angka st pada baris CPU. Membaca waktu CPU steal pada host bersama menjelaskan arti angka tersebut dan tindakan yang dapat dilakukan.

Sertifikat yang baru saja Anda terbitkan ditolak karena belum valid. curl menampilkan SSL certificate problem: certificate is not yet valid, dan browser menampilkan pesan yang serupa. Sertifikatnya tidak bermasalah. Jam yang digunakan untuk memeriksanya tertinggal. Mesin klien maupun server dapat menjadi penyebabnya, jadi periksa keduanya. Jika server yang menerbitkan sertifikat adalah mesin dengan jam yang salah, panduan sertifikat certbot dan nginx membahas proses renewal pada konfigurasi yang sama.

Tambahkan ke pemeriksaan yang sudah Anda jalankan

Sinkronisasi waktu adalah pengaturan saat boot yang dapat gagal tanpa pesan berbulan-bulan kemudian. Hal ini tepat untuk ditangani oleh pemeriksaan rutin, bukan diandalkan pada ingatan. timedatectl dan chronyc tracking hanya memerlukan waktu dua detik untuk dibaca secara berurutan. Jalankan keduanya sebagai bagian dari sepuluh menit pertama pada VPS baru, lalu jalankan kembali saat Anda mengikuti checklist pemeliharaan server Linux rutin. Jika Anda ingin pemeriksaan berjalan otomatis dan memberi peringatan saat offset membesar, menulis service dan timer systemd menjelaskan pola untuk unit kecil yang membuat laporan sesuai jadwal.

FAQ

Bagaimana cara memeriksa apakah waktu VPS saya tersinkronisasi?

Jalankan timedatectl dan baca baris System clock synchronized. Baris tersebut adalah flag milik kernel, yang diatur oleh daemon yang mendisiplinkan clock. Karena itu, yes bersama NTP service: n/a merupakan kondisi normal dan sehat pada mesin yang menggunakan chrony. Untuk mengetahui besar kesalahannya, jalankan chronyc tracking lalu baca System time. Anda juga dapat menjalankan timedatectl timesync-status lalu membaca Offset jika systemd-timesyncd yang mengelola sinkronisasi. Untuk memeriksa waktu terhadap sumber di luar mesin, bandingkan date -u dengan header Date yang dikembalikan oleh situs HTTPS mana pun.

Sebaiknya saya menggunakan chrony atau systemd-timesyncd pada VPS?

Gunakan chrony untuk server yang penting. systemd-timesyncd adalah klien SNTP yang mengikuti satu server. Komponen ini memadai untuk mesin yang selalu online dan sejak awal memiliki waktu yang hampir benar. chrony melakukan polling terhadap beberapa sumber, menolak sumber yang tidak sesuai, mempelajari kesalahan laju clock, dan pulih dengan cepat setelah host berhenti sementara atau menjalani live migration. Menginstal chrony pada Debian atau Ubuntu otomatis menghapus systemd-timesyncd karena kedua paket tersebut menyediakan time-daemon. Jangan pernah menjalankan dua daemon waktu secara bersamaan.

Mengapa kode TOTP saya gagal pada satu server, tetapi berfungsi di tempat lain?

Karena kode TOTP merupakan fungsi dari waktu saat ini. Kode tersebut berasal dari counter yang bertambah setiap 30 detik. Karena itu, server dan ponsel Anda harus menyepakati langkah waktu yang sama. Sebagian besar verifier menerima satu langkah sebelum atau sesudah langkah saat ini. Toleransinya kira-kira setengah menit ke setiap arah. Periksa timedatectl pada server tersebut. Jika System clock synchronized membaca no, perbaiki sinkronisasinya. Kode akan kembali cocok tanpa mengubah shared secret.

Dapatkah saya mengatur waktu di dalam container Docker?

Tidak, dan Anda tidak perlu melakukannya. Container menggunakan CLOCK_REALTIME milik host karena Linux hanya memvirtualisasi clock monotonic dan boot-time. Container tanpa hak istimewa mendapatkan date: cannot set date: Operation not permitted. Menambahkan CAP_SYS_TIME memungkinkan container mengubah clock host, bukan memberinya clock sendiri. Sinkronkan host sebagai gantinya. Waktu lokal yang berbeda di dalam container merupakan pengaturan zona waktu. Karena itu, atur TZ di environment container.

Sebaiknya server menggunakan UTC atau waktu lokal?

Gunakan UTC, lalu terapkan waktu lokal saat seseorang membaca output. UTC tidak berubah akibat daylight saving time. Dengan demikian, job harian berjalan sekali sehari sepanjang tahun, dan timestamp dari server yang berbeda dapat dicocokkan tanpa konversi. Atur dengan sudo timedatectl set-timezone UTC. Siapa pun yang ingin melihat waktu lokal dapat menambahkan prefix pada satu command, misalnya TZ=America/New_York date. Command tersebut tidak mengubah clock sistem.