Cara Memperbaiki Jam VPS yang Sering Meleset

Mengapa waktu pada VPS Anda meleset

Waktu pada VPS meleset karena tidak ada mekanisme yang mengoreksinya. Kernel menghitung waktu dari penghitung perangkat keras yang berjalan sedikit lebih cepat atau lebih lambat. Tanpa client sinkronisasi waktu yang berjalan, selisih kecil itu bertambah setiap jam. Di dalam mesin virtual, ada penyebab kedua: guest berbagi CPU fisik dengan guest lain. Saat guest tidak dijadwalkan untuk berjalan, guest tidak dapat menghitung waktu.

Pada guest KVM saat ini, penghitung itu sendiri jarang menjadi masalah sebenarnya. Sumber kvm-clock paravirtual membaca nilai yang dikelola host. Karena itu, guest yang sehat mengikuti waktu host dengan dekat. 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. Kemungkinan lain, UDP port 123 keluar tidak pernah meninggalkan jaringan provider Anda. Guest memperoleh penyesuaian waktunya dari host atau dari NTP (network time protocol), bukan dari osilatornya sendiri.

Hal yang sebenarnya rusak akibat jam yang salah

• Kode autentikasi dua faktor TOTP (time-based one-time password) tidak lagi cocok. Akibatnya, Anda terkunci dari server meskipun password dan key sudah benar.
• Sertifikat yang diterbitkan satu menit lalu ditolak, dan curl menampilkan 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 dijalankan dua kali, sementara pekerjaan lain dilewati.
• Log dari dua server tidak dapat disejajarkan. Akibatnya, kronologi insiden harus disusun berdasarkan perkiraan.

Toleransinya lebih kecil daripada yang diperkirakan kebanyakan orang. Angka di bawah ini adalah nilai 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 penghitung yang bertambah setiap 30 detik, dan sebagian besar pemverifikasi menerima satu interval di kedua sisi. Kesalahan setengah menit ke arah mana pun sudah menghabiskan seluruh toleransi. Kerberos jauh lebih toleran, dengan toleransi skew default sebesar 300 detik. Sertifikat sama sekali tidak toleran: sertifikat diperiksa terhadap waktu tertentu dengan masa kelonggaran 0 detik. Karena itu, jam yang terlambat satu detik dapat menolak sertifikat yang sebenarnya valid.

Tiga jam, dan jam yang penting

Jam sistem adalah jam yang penting. Jam ini merupakan CLOCK_REALTIME kernel: jumlah detik sejak 1 January 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 tetap berjalan saat mesin dimatikan. Pada mesin fisik, jam ini berada pada chip yang ditenagai baterai. Di dalam guest, jam ini diemulasikan oleh hypervisor sehingga sebagian besar hanya merupakan artefak host. Linux membacanya sekali saat boot untuk memperoleh nilai awal, lalu mempertahankan penghitungnya sendiri. timedatectl menampilkannya pada baris RTC time. Jangan melakukan debug berdasarkan baris tersebut pada VPS, karena baris itu menunjukkan waktu menurut host, bukan status sinkronisasi jam sistem Anda. Dalam container, biasanya tidak ada /dev/rtc sama sekali, sehingga hwclock --show gagal dengan hwclock: Cannot access the Hardware Clock via any known method.

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

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

Pada KVM, biasanya Anda akan melihat kvm-clock. Clocksource ini membaca nilai yang dipertahankan oleh host. Karena itu, guest KVM tanpa klien NTP pun biasanya tetap memiliki waktu yang kurang lebih benar untuk sementara. 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 yang 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. Dengan demikian, chrony dapat membaca jam host secara langsung, bukan melalui jaringan. Perangkat ini layak diperiksa, tetapi 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 sehingga NTP melalui jaringan adalah pilihan Anda. Jika clock_name menunjukkan jam virtual KVM, chrony dapat menggunakannya dengan baris refclock PHC /dev/ptp0 poll 2 dalam konfigurasinya.

Baca status waktu pada mesin Anda sendiri

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

timedatectl

Baca baris-baris ini, bukan mengandalkan angka yang Anda ingat:

• Local time dan Universal time adalah waktu yang sama, masing-masing ditampilkan dalam zona waktu Anda dan 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 menetapkannya setelah mempercayai sumber waktunya, sehingga no berarti belum ada daemon yang mendisiplinkan clock ini sejak boot.
• NTP service secara khusus melaporkan status 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 selisih waktu Anda. Jangan membandingkannya secara kasar dengan ponsel. Jika chrony sedang berjalan:

chronyc tracking
chronyc sources -v

chronyc tracking menampilkan angka yang menjawab pertanyaan tersebut. System time adalah offset saat ini dari waktu NTP, diikuti kata fast atau slow. Last offset adalah besar 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, sehingga Anda tidak perlu mengingat simbol-simbolnya. Dua kolom memuat sebagian besar informasi. Karakter status di awal setiap baris menunjukkan penilaian chrony terhadap sumber tersebut. * menandai sumber yang sedang digunakan, sedangkan ? pada setiap baris berarti tidak ada sumber yang menjawab. Reach adalah riwayat respons dari delapan polling terakhir yang ditampilkan dalam oktal: 377 berarti kedelapan polling mendapat respons, sedangkan 0 berarti tidak ada yang 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, berarti timesyncd bukan daemon yang menangani sinkronisasi pada mesin ini. Itu sendiri sudah menjawab pertanyaan Anda.

Untuk pemeriksaan kasar terhadap waktu di luar sistem tanpa alat tambahan, bandingkan clock Anda dengan header HTTP publik Date, yang disajikan dalam GMT dengan resolusi satu detik:

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

Selisih satu atau dua detik di sini normal dan tidak berarti apa-apa. Selisih satu menit berarti ada masalah pada konfigurasi Anda.

chrony atau systemd-timesyncd pada VPS

Ubuntu dan Debian menyertakan systemd-timesyncd secara default. Ini adalah klien SNTP (simple network time protocol): klien ini meminta waktu dari satu server pada satu waktu dan mengarahkan clock ke waktu tersebut. Pada mesin yang selalu online dan sejak awal memiliki waktu yang kurang lebih benar, ini sudah cukup dan hampir tidak memerlukan biaya saat dijalankan.

chrony adalah implementasi NTP lengkap dan pilihan default yang lebih baik pada mesin virtual, berdasarkan beberapa hal yang dapat Anda lihat dari output-nya. chrony melakukan polling ke beberapa sumber sekaligus dan membuang sumber yang tidak sesuai. chrony mengukur kesalahan laju clock dan menuliskannya ke drift file, sehingga chrony memperbaiki kecenderungan clock, 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 dapat dipindahkan ke host lain saat sedang berjalan. Jika perangkat PTP dari host tersedia, 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 diharapkan. Jangan pernah menjalankan keduanya, karena dua daemon yang mengatur clock yang sama akan saling bertentangan dan offset yang dilaporkan oleh keduanya tidak dapat dipercaya selama keduanya berjalan. Pada Rocky dan AlmaLinux, lakukan instalasi dengan sudo dnf install -y chrony. Pada sistem tersebut, unit ini bernama 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. Dua direktif perlu dipahami:

• Baris pool dan server menentukan sumber waktu. Menambahkan iburst membuat chrony mengirim burst cepat saat startup, sehingga sinkronisasi pertama terjadi dalam hitungan detik, bukan menit.
• makestep menentukan kapan chrony melakukan lompatan pada clock, 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, clock akan dilangkahkan 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 yang lebih baru mendukung NTS (network time security). Konfirmasikan versi Anda terlebih dahulu dengan chronyd -v. Perhatikan bahwa NTS memerlukan port TCP keluar 4460 selain UDP 123 yang terbuka:

server time.cloudflare.com iburst nts

Restart lalu lakukan verifikasi sebelum mempercayai konfigurasinya. Jika konfigurasi gagal diuraikan, Anda tidak akan memiliki daemon waktu sama sekali, dan clock 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 sampai 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 menggerakkan jam mundur. Pergerakan mundur berbahaya bagi apa pun yang mengukur waktu berlalu berdasarkan jam dinding. Karena itu, kedua daemon lebih memilih slewing.

Preferensi tersebut menjelaskan mengapa jam yang sangat meleset dapat tetap salah dalam waktu lama. chrony hanya melakukan stepping dalam window yang diizinkan oleh makestep. Secara default, window 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 memerlukan waktu jauh lebih lama daripada yang ingin Anda tunggu. Lakukan koreksi satu kali secara sengaja pada saat sistem tidak sibuk:

sudo chronyc makestep
chronyc tracking

chronyc tracking kini seharusnya melaporkan offset System time yang mendekati nol. Last offset seharusnya menampilkan ukuran koreksi yang baru saja dilakukan. Pertimbangkan dampaknya sebelum menjalankan perintah ini pada host database yang sibuk. Jam yang bergerak mundur dapat membingungkan software yang mengasumsikan waktu hanya bergerak maju. Me-restart daemon adalah versi yang lebih aman dari perbaikan yang sama, karena window makestep terbuka kembali 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 setiap container di host tersebut akan diperbaiki pada saat yang sama.

Beberapa konsekuensi muncul dari hal ini. Jangan memasang chrony atau ntpd dalam image, karena paling baik pun pemasangan tersebut tidak melakukan apa-apa. 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 memberi container jam privat. Kemampuan itu memungkinkan container mengubah jam host, dan dengan demikian juga jam setiap container lainnya.

Zona waktu yang berbeda di dalam container bukan masalah jam. Image yang menyertakan /etc/localtime akan mencetak 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 di server, waktu lokal untuk pengguna

Atur mesin ke UTC dan biarkan tetap demikian.

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

UTC tidak memiliki daylight saving time, dan itu menjadi alasan utamanya. Tugas harian pada pukul 02:30 di zona yang menerapkan daylight saving time 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: tugas yang terlewat karena lompatan maju akan dijalankan segera setelah perubahan, sedangkan tugas yang berada dalam satu jam yang berulang karena lompatan mundur tidak akan dijalankan untuk kedua kalinya. Perilaku tersebut wajar, tetapi Anda seharusnya tidak perlu menganalisisnya pada pukul 03:00. Dengan UTC, tugas berjalan sekali sehari, setiap hari sepanjang tahun. Jika tugas Anda sama sekali tidak berjalan, bukan hanya berjalan pada jam yang tidak biasa, alasan tugas cron diam-diam tidak pernah berjalan lebih mungkin menjadi penyebabnya.

Argumen yang sama berlaku saat membaca log. journalctl memformat timestamp menggunakan zona waktu sistem, sedangkan journalctl --utc memaksa penggunaan UTC. Dua server di dua zona waktu membuat setiap insiden menjadi proses konversi, dan konversi yang dilakukan dalam tekanan dapat menyebabkan orang salah membaca urutan waktu. Gunakan UTC pada sistem, simpan timestamp dalam UTC, lalu lakukan konversi sekali ketika manusia membacanya. Siapa pun yang memerlukan waktu lokal untuk satu perintah dapat memintanya tanpa mengubah mesin:

TZ=Europe/Berlin date

Satu baris lain dalam output timedatectl termasuk dalam bagian ini. RTC in local TZ harus membaca no. Mengaturnya ke yes merupakan solusi sementara untuk dual-boot Windows pada laptop, sedangkan pada server pengaturan ini hanya menambahkan offset yang dapat menimbulkan masalah di kemudian hari. Jika pengaturan tersebut 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 waktu sebelum memeriksa hal lain. Kode tersebut berasal dari penghitung yang bertambah setiap 30 detik, sehingga server yang tertinggal 90 detik akan menghitung kode dari interval yang sudah dilewati ponsel Anda. timedatectl akan menampilkan System clock synchronized: no, atau chronyc tracking akan melaporkan offset System time yang besar. Ini merupakan kegagalan yang berbeda dari key yang langsung ditolak, yang 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). Waktu pada sistem Anda tertinggal dari tanggal di dalam file Release repository, dan durasi tersebut mengukur langsung seberapa jauh keterlambatannya. Perbaiki waktu sistem. Jangan menonaktifkan pemeriksaan tanggal apt untuk melewati masalah ini, karena pemeriksaan tersebut mencegah seseorang memberikan indeks paket yang sudah kedaluwarsa kepada Anda.

Setiap baris source menampilkan status unreachable dan Reach bernilai 0. Tidak ada yang merespons, jadi periksa trafik 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 nol berarti paket Anda keluar, tetapi tidak ada paket yang kembali. Ini mengarah pada firewall di antara Anda dan source tersebut.

Waktu sistem awalnya benar, lalu berubah mendadak. Peristiwa pada host dapat menyebabkan hal ini. Snapshot yang dipulihkan, guest yang dijeda, atau live migration ke host lain dapat membuat waktu yang dipahami guest tertinggal dari waktu sebenarnya. chrony mendeteksinya pada polling berikutnya dan melakukan koreksi; systemd-timesyncd mungkin terlebih dahulu menunggu interval polling yang panjang. Pastikan daemon dijalankan 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, sehingga offset berubah-ubah dan tidak mencapai konvergensi. top menampilkan kondisi ini sebagai angka st pada baris CPU. Cara 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 serupa. Sertifikatnya benar; clock yang memeriksanya tertinggal. Mesin yang bermasalah dapat berupa client atau server, jadi periksa keduanya. Jika server yang menerbitkan sertifikat adalah mesin dengan clock yang salah, panduan sertifikat certbot dan nginx membahas proses renewal pada setup 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 ditangani oleh rutinitas, bukan diandalkan pada ingatan. timedatectl dan chronyc tracking hanya membutuhkan 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 memberikan peringatan saat offset membesar, menulis service dan timer systemd menjelaskan pola untuk unit kecil yang mengirimkan laporan sesuai jadwal. Pemeriksaan seperti ini adalah skrip singkat, bukan daemon, sehingga memerlukan Type=oneshot, bukan nilai default. Uraian tentang jenis service systemd menjelaskan mengapa penggunaan jenis yang salah membuat Anda memiliki unit yang melaporkan keberhasilan yang sebenarnya tidak pernah dicapainya.

FAQ

Bagaimana cara memeriksa apakah waktu VPS saya tersinkronisasi?

Jalankan timedatectl dan baca baris System clock synchronized. Baris tersebut adalah flag milik kernel yang ditetapkan oleh daemon yang melakukan sinkronisasi waktu. Karena itu, yes bersama NTP service: n/a merupakan kondisi normal dan sehat pada mesin yang menggunakan chrony. Untuk melihat besarnya selisih, jalankan chronyc tracking lalu baca System time. Jika systemd-timesyncd yang menangani sinkronisasi, jalankan timedatectl timesync-status lalu baca Offset. 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. Layanan ini cukup 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 laju penyimpangan jam, dan pulih dengan cepat setelah host mengalami jeda atau live migration. Instalasi chrony pada Debian atau Ubuntu otomatis menghapus systemd-timesyncd karena kedua paket tersebut menyediakan time-daemon. Jangan 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 penghitung yang bertambah setiap 30 detik. Karena itu, server dan ponsel Anda harus menyepakati interval waktu yang sedang berlaku. Sebagian besar verifikator menerima satu interval sebelum atau sesudah interval saat ini. Toleransinya kira-kira setengah menit ke setiap arah. Periksa timedatectl pada server tersebut. Jika System clock synchronized membaca no, perbaiki sinkronisasi waktu. Kode akan kembali cocok tanpa mengubah secret bersama.

Dapatkah saya mengatur waktu di dalam container Docker?

Tidak, dan Anda tidak perlu melakukannya. Container menggunakan CLOCK_REALTIME milik host karena namespace waktu Linux hanya memvirtualisasi jam monotonic dan jam sejak boot. Container tanpa hak istimewa memperoleh date: cannot set date: Operation not permitted. Menambahkan CAP_SYS_TIME memungkinkan container mengubah jam host, bukan memberinya jam sendiri. Sinkronkan host sebagai gantinya. Waktu lokal yang berbeda di dalam container merupakan pengaturan zona waktu. Atur TZ di lingkungan container.

Sebaiknya server menggunakan UTC atau waktu lokal?

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