Cara Betulkan Jam VPS Tidak Tepat dan Ralat Masa

Mengapa jam VPS anda tidak tepat

Jam VPS menjadi tidak tepat kerana tiada proses yang membetulkannya. Kernel mengira masa berdasarkan pembilang perkakasan yang berjalan sedikit laju atau sedikit perlahan, dan tanpa klien penyelarasan masa yang berjalan, ralat kecil itu akan terkumpul setiap jam. Di dalam mesin maya, terdapat punca kedua: tetamu anda berkongsi CPU fizikal dengan tetamu lain, jadi detik apabila ia tidak dijadualkan adalah detik ia tidak dapat mengira masa.

Pada tetamu KVM semasa, pembilang itu sendiri jarang menjadi masalah sebenar. Sumber kvm-clock paravirtual membaca nilai yang diselenggara oleh hos, jadi tetamu yang sihat akan menjejaki hosnya dengan rapat. Jam yang jelas salah biasanya disebabkan oleh punca yang lebih mudah. Tiada daemon penyelarasan yang berjalan, atau dua daemon berjalan dan saling bercanggah, atau port UDP 123 keluar tidak pernah melepasi rangkaian penyedia anda. Tetamu mengambil disiplin masanya daripada hos atau daripada NTP (network time protocol), bukan daripada pengayunnya sendiri.

Kesan sebenar jam yang tidak tepat

• Kod pengesahan dua faktor TOTP (time-based one-time password) tidak lagi sepadan, menyebabkan anda terkunci daripada pelayan walaupun kata laluan dan kunci anda adalah betul.
• Sijil yang dikeluarkan seminit yang lalu ditolak, dan curl mencetak SSL certificate problem: certificate is not yet valid.
• apt update menolak repositori dengan E: Release file for ... is not valid yet (invalid for another 1d 2h 3min 4s).
• Tugasan berjadual berjalan pada waktu yang salah, dan jam yang melompat boleh menyebabkan satu tugasan berjalan dua kali manakala tugasan lain dilangkau.
• Log daripada dua pelayan tidak dapat diselaraskan, menyebabkan garis masa insiden terpaksa dibina berdasarkan andaian.

Toleransi masa adalah lebih kecil daripada jangkaan kebanyakan orang. Angka di bawah adalah nilai lalai yang didokumentasikan, bukan ukuran daripada ujian.

[
  {
    "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"
  }
]

Kod TOTP dikira daripada pembilang yang bertambah setiap 30 saat, dan kebanyakan pengesah menerima satu langkah di kedua-dua belah masa. Ralat setengah minit pada setiap arah adalah had keseluruhan. Kerberos jauh lebih bertoleransi, dengan elaun sisihan lalai sebanyak 300 saat. Sijil tidak mempunyai toleransi langsung: ia disemak berdasarkan detik tetap dengan tempoh tangguh selama 0 saat, jadi jam yang mendahului satu saat akan menolak sijil yang sebenarnya sah sepenuhnya.

Tiga jenis jam, dan jam mana yang penting

Jam sistem adalah jam yang penting. Ia merupakan CLOCK_REALTIME kernel: kiraan saat sejak 1 Januari 1970 UTC, yang disimpan dalam memori dan dibaca oleh semua proses yang memerlukan cap masa. Baris log, semakan sijil, kod TOTP dan masa pengubahsuaian fail semuanya bergantung kepadanya. Apabila seseorang menyatakan masa pelayan tidak tepat, jam inilah yang dimaksudkan.

Jam perkakasan, juga dikenali sebagai RTC (real time clock), ialah pembilang berasingan yang terus berjalan semasa mesin dimatikan. Pada mesin fizikal, ia merupakan cip yang disokong oleh bateri. Di dalam tetamu (guest), ia diemulasikan oleh hypervisor, jadi ia sebahagian besarnya adalah artifak hos. Linux membacanya sekali semasa but untuk mendapatkan nilai permulaan, kemudian ia mengekalkan kiraannya sendiri. timedatectl mencetaknya pada baris RTC time. Jangan lakukan penyahpepijatan berdasarkan baris tersebut pada VPS, kerana ia menunjukkan persepsi masa hos dan bukannya status penyelarasan jam sistem anda. Dalam kontena, biasanya tiada /dev/rtc langsung, jadi hwclock --show akan gagal dengan hwclock: Cannot access the Hardware Clock via any known method..

Clocksource ialah apa yang digunakan oleh kernel untuk mengira antara bacaan tersebut. Tanya kernel anda yang mana satu telah 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. Ia membaca nilai yang diselenggara oleh hos, itulah sebabnya tetamu KVM tanpa klien NTP masih kekal tepat untuk tempoh tertentu. tsc ialah pembilang CPU itu sendiri. Tetamu Xen melaporkan xen, dan tetamu Hyper-V melaporkan sumber hyperv. Jangan ubah tetapan ini melainkan anda mempunyai alasan yang terukur untuk berbuat demikian, kerana kernel sudah memilih sumber terbaik yang dipercayainya pada perkakasan tersebut.

Sesetengah hos juga memberikan peranti PTP (precision time protocol) kepada tetamu, yang membolehkan chrony membaca jam hos secara terus dan bukannya melalui rangkaian. Ia berbaloi untuk disemak, namun ia sering tidak tersedia pada VPS kongsi:

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

Jika modprobe gagal atau tiada peranti muncul, hos anda tidak menawarkannya dan NTP rangkaian adalah penyelesaian anda. Jika clock_name menamakan jam maya KVM, chrony boleh menggunakannya dengan baris refclock PHC /dev/ptp0 poll 2 dalam konfigurasinya.

Membaca status masa pada mesin anda sendiri

Mulakan dengan satu arahan. Ia menjawab soalan "adakah sesuatu yang memastikan jam ini tepat" dalam satu skrin.

timedatectl

Baca baris-baris ini dan jangan hanya mempercayai nombor yang anda ingat:

• Local time dan Universal time adalah detik yang sama yang dicetak dalam zon anda dan dalam UTC. Jika ia serupa, mesin tersebut sudah berada pada waktu UTC.
• RTC time ialah jam perkakasan yang diterangkan di atas. Pada VPS, abaikan perkara ini.
• Time zone ialah apa yang digunakan oleh sistem untuk memformat waktu tempatan.
• System clock synchronized ialah flag kernel itu sendiri. Daemon masa menetapkannya sebaik sahaja ia mempercayai sumbernya, jadi no bermakna tiada apa yang telah menyelaraskan jam ini sejak but.
• NTP service melaporkan tentang systemd-timesyncd secara khusus. n/a adalah normal pada mesin yang menjalankan chrony, kerana timesyncd tidak dipasang di sana. System clock synchronized: yes bersama-sama dengan NTP service: n/a bermakna chrony sedang melakukan tugasnya dan kernel bersetuju dengannya.

Seterusnya, tanya sejauh mana perbezaan masa anda. Jangan hanya menganggarkannya dengan telefon anda. Jika chrony sedang berjalan:

chronyc tracking
chronyc sources -v

chronyc tracking mencetak nombor yang menjawab soalan tersebut. System time ialah offset semasa daripada waktu NTP, diikuti dengan perkataan fast atau slow. Last offset ialah saiz pembetulan terkini. Frequency ialah ralat kadar yang telah diukur oleh chrony dalam jam anda dan sedang dikompensasikan. Leap status sepatutnya memaparkan Normal. Jika ia memaparkan Not synchronised dan Reference ID ialah 00000000 (), chrony masih belum menetapkan sumber.

chronyc sources -v mencetak legenda di atas senarai, supaya anda tidak perlu mengingati simbol-simbol tersebut. Dua lajur membawa kebanyakan maksud. Aksara status pada permulaan setiap baris ialah cara chrony menilai sumber tersebut, di mana * menandakan sumber yang sedang digunakan dan ? pada setiap baris bermakna tiada apa yang menjawab. Reach ialah sejarah balasan bagi lapan poll terakhir yang dicetak dalam oktal: 377 bermakna kesemua lapan telah dijawab, 0 bermakna tiada satu pun yang dijawab.

Jika systemd-timesyncd yang bertanggungjawab:

timedatectl timesync-status
timedatectl show-timesync --all

timesync-status mencetak pelayan yang dihubungi, selang poll dan nilai Offset. Jika arahan tersebut mengembalikan ralat tentang servis dan bukannya mencetak status, timesyncd bukanlah daemon yang bertanggungjawab pada kotak ini, yang dengan sendirinya merupakan jawapan kepada soalan anda.

Untuk pemeriksaan kasar terhadap dunia luar tanpa alat tambahan, bandingkan jam anda dengan header HTTP Date awam, yang dihidangkan dalam GMT dengan resolusi satu saat:

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

Perbezaan satu atau dua saat di sini adalah normal dan tidak bermakna apa-apa. Perbezaan selama seminit adalah ralat anda.

chrony atau systemd-timesyncd pada VPS

Ubuntu dan Debian menyertakan systemd-timesyncd secara lalai. Ia merupakan klien SNTP (simple network time protocol): ia menanyakan satu pelayan pada satu masa dan melaraskan jam ke arah pelayan tersebut. Bagi mesin yang sentiasa dalam talian dan bermula dengan masa yang hampir tepat, ini sudah memadai dan kos sumbernya hampir sifar.

chrony ialah implementasi NTP penuh dan merupakan pilihan lalai yang lebih baik pada mesin maya, atas sebab-sebab yang boleh dilihat pada outputnya sendiri. Ia meninjau beberapa sumber serentak dan membuang sumber yang tidak konsisten. Ia mengukur ralat kadar jam anda dan menulisnya ke dalam fail drift, supaya ia membetulkan kecenderungan jam tersebut dan bukannya mengejar setiap sampel. Ia juga pulih dengan pantas daripada dua perkara yang dilakukan oleh VM tetapi tidak oleh mesin fizikal: ia boleh dihentikan sementara (pause) oleh hosnya, dan ia boleh dipindahkan ke hos lain semasa sedang berjalan. Apabila peranti PTP hos ditawarkan, chrony adalah perisian yang membacanya.

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

Baca output apt semasa ia berjalan. Pada Debian dan Ubuntu, pakej chrony dan systemd-timesyncd kedua-duanya menyediakan time-daemon, jadi apt akan membuang timesyncd apabila ia memasang chrony. Ini adalah betul dan diingini. Jangan jalankan kedua-duanya serentak, kerana dua daemon yang menetapkan jam yang sama akan bercanggah dan offset yang dilaporkan oleh mana-mana satu daripadanya tidak boleh dipercayai semasa ia berlaku. Pada Rocky dan AlmaLinux, pasang dengan sudo dnf install -y chrony, di mana unitnya dipanggil chronyd dan bukannya chrony.

Fail konfigurasi ialah /etc/chrony/chrony.conf pada Debian dan Ubuntu, dan /etc/chrony.conf pada Rocky dan Alma. Lalai pengedaran sudah memadai untuk VPS, jadi ubah ia hanya jika perlu. Dua arahan yang perlu difahami:

• Baris pool dan server menamakan sumber masa. Menambah iburst memberitahu chrony untuk menghantar burst pantas semasa permulaan, supaya penyelarasan pertama berlaku dalam beberapa saat dan bukannya minit.
• makestep menentukan bila chrony melompatkan jam dan bukannya melaraskannya secara perlahan. Semak tetapan anda dengan grep -n makestep /etc/chrony/chrony.conf. Lalai Debian dan Ubuntu, makestep 1 3, bermaksud: semasa tiga kemas kini pertama selepas chronyd bermula, lompatkan jam jika ia tersasar lebih daripada satu saat, dan selepas itu betulkan dengan cara slewing sahaja.

Jika anda mahukan trafik masa disahkan bagi mengelakkan gangguan pada laluan, chrony 4 dan versi lebih baharu menyokong NTS (network time security). Sahkan versi anda dengan chronyd -v terlebih dahulu, dan ambil perhatian bahawa NTS memerlukan port TCP keluar 4460 dibuka selain daripada UDP 123:

server time.cloudflare.com iburst nts

Mulakan semula dan sahkan sebelum anda mempercayainya. Konfigurasi yang gagal diurai akan menyebabkan anda tidak mempunyai daemon masa langsung, dan jam tidak akan memberitahu anda tentang perkara itu.

sudo systemctl restart chrony
chronyc sources -v
chronyc tracking

Mengapa jam yang tersalah beberapa minit kekal salah

Daemon masa mempunyai dua cara untuk membetulkan offset. Slewing mempercepatkan atau memperlahankan jam sehingga ralat hilang, yang memastikan masa terus bergerak ke hadapan dan tidak pernah mengulang atau melangkau cap masa. Stepping melompat terus ke nilai yang betul, yang pantas dan boleh menggerakkan jam ke belakang. Pergerakan ke belakang adalah berbahaya bagi apa-apa yang mengukur masa berlalu daripada jam dinding, jadi kedua-dua daemon lebih memilih untuk melakukan slewing.

Keutamaan tersebut adalah sebab mengapa jam yang sangat salah boleh kekal salah untuk tempoh yang lama. chrony hanya melakukan stepping dalam tetingkap yang dibenarkan oleh makestep, yang secara lalai adalah beberapa kemas kini pertama selepas daemon bermula. chronyd yang telah berjalan selama seminggu dan kemudian menemui ralat empat puluh saat akan melakukan slewing, dan slewing selama empat puluh saat mengambil masa yang jauh lebih lama daripada yang anda mahukan. Paksa ia sekali, secara sengaja, pada waktu yang tenang:

sudo chronyc makestep
chronyc tracking

chronyc tracking kini sepatutnya melaporkan offset System time yang hampir kepada sifar, dan Last offset sepatutnya menunjukkan saiz apa yang baru sahaja dibetulkan. Fikirkan dahulu sebelum menjalankan ini pada hos pangkalan data yang sibuk, kerana jam yang melompat ke belakang boleh mengelirukan perisian yang menganggap masa hanya bergerak ke hadapan. Memulakan semula daemon adalah versi yang lebih lembut bagi pembetulan yang sama, kerana tetingkap makestep dibuka semula semasa permulaan.

Kontena berkongsi jam hos

Kontena tidak mempunyai jam dinding sendiri, jadi tiada apa yang perlu diselaraskan di dalamnya. Namespace masa Linux hanya memvirtualisasikan jam monotonik dan jam masa but. CLOCK_REALTIME tidak divirtualisasikan, yang bermaksud kontena membaca jam sistem yang sama dengan hos tempat ia dijalankan. Betulkan jam pada hos dan setiap kontena pada hos tersebut akan dibetulkan pada saat yang sama.

Beberapa akibat timbul daripada perkara ini. Jangan pasang chrony atau ntpd dalam imej, kerana paling baik pun ia tidak melakukan apa-apa. Menetapkan tarikh di dalam kontena tanpa keistimewaan akan gagal dengan date: cannot set date: Operation not permitted, kerana kernel memerlukan CAP_SYS_TIME untuk panggilan tersebut. Memberikan CAP_SYS_TIME tidak memberikan kontena jam peribadi, ia memberikan kontena keupayaan untuk menukar jam hos dan oleh itu jam setiap kontena lain juga.

Zon masa yang berbeza di dalam kontena bukanlah masalah jam. Imej yang membawa /etc/localtime sendiri mencetak detik yang sama yang diformatkan untuk zon lain, jadi date kelihatan salah sedangkan jamnya adalah betul. Tetapkan TZ=UTC dalam persekitaran kontena dan kekeliruan tersebut akan hilang. Runtime yang anda pilih tidak mengubah apa-apa di sini, dan perbandingan rootless Podman dan Docker merangkumi perkara yang ia ubah.

Zon masa: UTC pada pelayan, waktu tempatan untuk pengguna

Tetapkan mesin kepada UTC dan kekalkan tetapan tersebut.

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

UTC tidak mempunyai waktu jimat siang (daylight saving), dan itulah hujah utamanya. Tugasan harian pada jam 02:30 di zon yang mematuhi waktu jimat siang akan berjalan dua kali pada hari jam dianjak ke belakang, dan tidak berjalan langsung pada hari jam dianjak ke hadapan. man 8 cron mendokumentasikan pengendalian khas untuk anjakan kurang daripada tiga jam: tugasan yang dilangkau akibat anjakan ke hadapan akan dijalankan sejurus selepas perubahan, dan tugasan yang terperangkap dalam jam yang berulang akibat anjakan ke belakang tidak akan dijalankan buat kali kedua. Perlakuan tersebut adalah munasabah, namun ia tetap perlakuan yang tidak sepatutnya anda fikirkan pada jam 03:00. Di bawah UTC, tugasan berjalan sekali sehari, setiap hari sepanjang tahun. Jika tugasan anda hilang sepenuhnya dan bukannya berjalan pada jam yang ganjil, sebab-sebab tugasan cron tidak berjalan secara senyap adalah penjelasan yang lebih berkemungkinan.

Hujah yang sama terpakai untuk membaca log. journalctl memformat cap waktu dalam zon masa sistem, dan journalctl --utc memaksa penggunaan UTC. Dua pelayan dalam dua zon masa menjadikan setiap insiden sebagai latihan penukaran, dan penukaran yang dilakukan di bawah tekanan adalah punca manusia tersalah baca garis masa. Kekalkan sistem pada UTC, simpan cap waktu dalam UTC, dan lakukan penukaran hanya pada titik di mana manusia membacanya. Sesiapa yang mahukan bacaan waktu tempatan untuk satu arahan boleh memintanya tanpa perlu mengubah tetapan mesin:

TZ=Europe/Berlin date

Satu lagi baris dalam output timedatectl tergolong dalam bahagian ini. RTC in local TZ sepatutnya berbunyi no. Menetapkannya kepada yes adalah penyelesaian sementara untuk dual-boot Windows pada komputer riba, dan pada pelayan ia hanya menambah offset yang akan menyusahkan seseorang di kemudian hari. Apabila ia ditetapkan, timedatectl mencetak amaran bahawa sistem dikonfigurasikan untuk membaca masa RTC dalam zon masa tempatan.

Penyelesaian masalah mengikut simptom

Kod dua faktor anda ditolak pada satu pelayan. Periksa jam sistem sebelum anda memeriksa perkara lain. Kod tersebut dijana daripada pembilang yang berubah setiap 30 saat, jadi pelayan yang lewat 90 saat akan mengira kod daripada langkah yang telah pun berlalu pada telefon anda. timedatectl akan menunjukkan System clock synchronized: no, atau chronyc tracking akan melaporkan System time offset yang besar. Ini adalah kegagalan yang berbeza daripada kunci yang ditolak secara terus, yang mencetak mesejnya sendiri dan dibincangkan dalam panduan kegagalan pengesahan publickey.

apt update menyatakan fail Release belum sah lagi. Mesej penuh tersebut menamakan repositori dan tempoh masa ia akan kekal tidak sah, contohnya is not valid yet (invalid for another 1d 2h 3min 4s). Jam anda lewat daripada tarikh di dalam fail Release repositori tersebut, dan tempoh masa itu adalah ukuran tepat sejauh mana jam anda ketinggalan. Betulkan jam tersebut. Jangan nyahdayakan semakan tarikh apt untuk melangkauinya, kerana semakan itulah yang menghalang seseorang daripada memberikan anda indeks pakej yang lapuk.

Setiap baris sumber menunjukkan status tidak boleh dicapai dan Reach adalah 0. Tiada apa-apa yang memberi respons, jadi perhatikan trafik keluar (egress) dan bukannya konfigurasi anda. NTP menggunakan port UDP 123 untuk trafik keluar, dan sesetengah rangkaian menapis atau mengubah hala trafik ini. sudo chronyc ntpdata mencetak pembilang bagi setiap sumber termasuk Total TX dan Total RX. Kiraan TX yang meningkat sementara RX kekal pada sifar bermakna paket anda keluar tetapi tiada apa-apa yang kembali, yang menunjukkan adanya firewall antara anda dan sumber tersebut.

Jam adalah tepat, kemudian melompat. Peristiwa hos menyebabkan perkara ini berlaku. Snapshot yang dipulihkan, guest yang dijeda, atau migrasi langsung (live migration) ke hos lain boleh menyebabkan waktu pada guest ketinggalan berbanding waktu sebenar. chrony akan menyedarinya pada poll seterusnya dan membetulkannya; systemd-timesyncd mungkin menunggu selang poll yang lama terlebih dahulu. Sahkan daemon bermula semasa but dengan systemctl is-enabled chrony, kerana daemon yang dimulakan secara manual akan hilang selepas but semula yang seterusnya.

Offset adalah kecil tetapi tidak pernah stabil. Perhatikan CPU steal. Guest yang tidak dijadualkan apabila interrupt pemasa sepatutnya berlaku akan mengalami kelewatan sampel, jadi offset akan berubah-ubah dan bukannya stabil. top menunjukkan ini sebagai angka st pada baris CPU. Membaca masa CPU steal pada hos kongsi menjelaskan maksud angka tersebut dan perkara yang boleh anda lakukan mengenainya.

Sijil yang baru anda keluarkan ditolak kerana belum sah. curl mencetak SSL certificate problem: certificate is not yet valid, dan pelayar web memaparkan mesej yang serupa. Sijil tersebut tiada masalah; jam yang menyemaknya adalah lewat. Mana-mana mesin boleh menjadi punca, jadi periksa pelanggan dan pelayan. Jika pelayan yang mengeluarkan sijil tersebut adalah mesin yang mempunyai jam yang salah, panduan sijil certbot dan nginx merangkumi bahagian pembaharuan bagi persediaan yang sama.

Tambahkannya ke dalam pemeriksaan yang anda jalankan

Penyelarasan masa merupakan tetapan waktu but yang gagal secara senyap berbulan-bulan kemudian, iaitu jenis masalah yang dapat dikesan oleh rutin tetapi tidak oleh ingatan. timedatectl dan chronyc tracking hanya mengambil masa dua saat untuk dibaca bersama. Jalankannya sebagai sebahagian daripada sepuluh minit pertama pada VPS baharu, dan sekali lagi apabila anda menyemak senarai semak penyelenggaraan pelayan Linux berkala. Jika anda lebih suka pemeriksaan tersebut berjalan sendiri dan memberi amaran apabila offset meningkat, menulis perkhidmatan dan pemasa systemd merangkumi corak untuk unit kecil yang melaporkan mengikut jadual.

FAQ

Bagaimanakah cara untuk menyemak sama ada jam VPS saya selari?

Jalankan timedatectl dan baca baris System clock synchronized. Itu adalah flag kernel sendiri, yang ditetapkan oleh mana-mana daemon yang mengawal jam tersebut, jadi yes bersama-sama NTP service: n/a adalah normal dan sihat pada mesin yang menggunakan chrony. Untuk saiz ralat, jalankan chronyc tracking dan baca System time, atau jalankan timedatectl timesync-status dan baca Offset jika systemd-timesyncd yang mengawal. Untuk semakan terhadap sesuatu di luar mesin, bandingkan date -u dengan header Date yang dikembalikan oleh mana-mana laman HTTPS.

Patutkah saya menggunakan chrony atau systemd-timesyncd pada VPS?

Gunakan chrony pada apa-apa sahaja yang penting. systemd-timesyncd ialah klien SNTP yang mengikuti satu pelayan, dan ia memadai pada mesin yang sentiasa dalam talian dan bermula dengan masa yang hampir tepat. chrony meninjau beberapa sumber, menolak sumber yang tidak bersetuju, mempelajari ralat kadar jam anda, dan pulih dengan cepat selepas jeda hos atau migrasi langsung. Memasang chrony pada Debian atau Ubuntu akan membuang systemd-timesyncd secara automatik, kerana kedua-dua pakej menyediakan time-daemon. Jangan sekali-kali menjalankan dua daemon masa serentak.

Mengapakah kod TOTP saya gagal pada satu pelayan tetapi berfungsi di tempat lain?

Kerana kod TOTP adalah fungsi masa semasa. Kod tersebut datang daripada pembilang yang bertambah setiap 30 saat, jadi pelayan dan telefon anda perlu bersetuju tentang langkah yang sedang berjalan. Kebanyakan pengesah menerima satu langkah di kedua-dua belah, yang memberikan kira-kira setengah minit kelonggaran ke setiap arah. Semak timedatectl pada pelayan tersebut. Jika System clock synchronized membaca no, betulkan penyelarasan tersebut dan kod akan sepadan semula tanpa menukar rahsia dikongsi (shared secret).

Bolehkah saya menetapkan masa di dalam bekas Docker?

Tidak, dan anda tidak perlu berbuat demikian. Bekas berkongsi CLOCK_REALTIME hos, kerana namespace masa Linux hanya memvirtualisasikan jam monotonik dan jam masa but. Bekas tanpa keistimewaan mendapat date: cannot set date: Operation not permitted, dan menambah CAP_SYS_TIME membolehkannya menukar jam hos dan bukannya memberikan jam sendiri. Selaraskan hos sebaliknya. Masa tempatan yang berbeza di dalam bekas adalah tetapan zon masa, jadi tetapkan TZ dalam persekitaran bekas.

Patutkah pelayan menggunakan UTC atau waktu tempatan?

UTC, dengan waktu tempatan digunakan pada titik seseorang membaca output. UTC tidak pernah berubah untuk penjimatan waktu siang (daylight saving), jadi kerja harian berjalan sekali sehari sepanjang tahun dan cap masa daripada pelayan yang berbeza akan selari tanpa penukaran. Tetapkannya dengan sudo timedatectl set-timezone UTC. Sesiapa yang mahukan bacaan tempatan boleh meletakkan awalan pada satu arahan, contohnya TZ=America/New_York date, yang tidak mengubah apa-apa pada jam sistem.