Bagaimana Linux menggunakan jam waktu nyata?

Saya dapat menanggapi beberapa poin ini, termasuk judulnya.

[...] yang selalu berkorelasi dengan systemd-timesyncd memperbarui jam sistem. Maksud saya, pesan syslog pertama setelah lompatan waktu adalah Time has been changed pesan syslog:

grep 'Time has been changed' /var/log/syslog
Oct  2 23:53:33 hostname systemd[1]: Time has been changed

Sebenarnya, pesan ini tidak memberi tahu Anda program apa yang menyebabkan lompatan waktu. Itu hanyalah gejala dari lompatan waktu.

Itu terjadi ketika kernel memberi tahu systemd jam telah diubah.[*] systemd merespons dengan menulis pesan ini ke log sistem, lalu menghitung ulang bila ada .timer unit perlu dipicu.

Pesan tersebut dicetak oleh program systemd , bukan dengan systemd-timesyncd .

Lebih khusus lagi, awalan pesan "systemd[1]:" berarti berasal dari ID proses 1. PID 1 adalah proses "init" khusus. Proyek systemd juga menyebutnya "manajer sistem", untuk membedakannya dari contoh systemd yang mengelola layanan pengguna.

Program tersebut bernama systemd tidak mengubah jam setelah sistem selesai booting.

Di pohon sumber systemd saat ini yang Anda tautkan, satu-satunya program yang membaca RTC / hardware clock / hwclock adalah timedated , dan hanya jika Anda memintanya menggunakan timedatectl .

Seingat saya, versi systemd yang lebih lama program membaca hwclock satu kali saat boot, sebelum menjalankan program lain, dan mengatur jam sistem yang sesuai. Di versi terbaru, systemd tidak melakukan ini. Hanya ada beberapa peretasan yang memberi tahu kernel zona waktu mana digunakan untuk jam perangkat keras. (Dan menghindari memicu sesuatu yang sangat spesifik yang disebut "time warp").

Dengan kata lain, systemd saat ini tampaknya secara implisit berasumsi bahwa sesuatu yang lain menginisialisasi jam sistem. Dalam kebanyakan kasus, ini akan menjadi kernel.

Cari opsi kernel build "Set system time from RTC on startup and resume" - CONFIG_RTC_HCTOSYS .

Untuk pemahaman menyeluruh, perhatikan ada juga opsi "Setel waktu RTC berdasarkan sinkronisasi NTP" - CONFIG_RTC_SYSTOHC .

[*] Perubahan jam sistem terdeteksi menggunakan fitur khusus Linux. Lihat TFD_TIMER_CANCEL_ON_SET .

Terima kasih banyak kepada sourcejedi untuk jawaban ini. Ini benar-benar membuat saya menemukan jawaban yang tepat.

Jawaban atas pertanyaan

Bagaimana cara Linux menggunakan jam waktu nyata untuk mempertahankan jam sistem?

Ia melakukannya hanya sekali, saat boot. Itu tidak akan meminta RTC lagi sampai reboot berikutnya. Ini dapat dikonfigurasi, tetapi akan melakukannya secara default pada kebanyakan kernel build.

Saya ingin tahu apakah kesalahan dengan jam waktu nyata hanya akan muncul dengan sendirinya di jam sistem saat agen sinkronisasi waktu (ntpd atau systemd-timesyncd) diperbarui.

Kecuali jika sistem di-boot ulang, waktu di RTC kemungkinan besar tidak akan masuk ke jam sistem sama sekali. Beberapa agen menyukai ntpd dapat dikonfigurasi untuk menggunakan RTC sebagai sumber waktu tetapi ini biasanya tidak diaktifkan secara default. Tidak disarankan untuk mengaktifkannya kecuali Anda tahu bahwa RTC adalah sumber waktu yang sangat baik.

Apakah ada hubungan langsung antara jam sistem?

Tampaknya waktu disalin dengan cara lain. RTC diperbarui secara berkala dengan waktu sistem. Sesuai jawaban sourcejedi, ini dilakukan oleh kernel jika CONFIG_RTC_HCTOSYS disetel.

Ini dapat diuji:

• Tetapkan RTC

  # hwclock --set --date='18:28'
  

• Kemudian periksa waktu RTC setiap beberapa menit dengan:

  # hwclock
  

Hasilnya adalah waktu sistem tidak akan berubah sama sekali, dan RTC pada akhirnya akan kembali ke waktu sistem.

Penyebab waktu melompat pada BBB

Seperti yang ditunjukkan oleh sourcejedi, pesan tidak dipicu oleh systemd-timesyncd . Mereka dipicu oleh connman . Buktinya adalah (seharusnya) pesan log palsu di /var/log/syslog :

Oct  3 00:10:37 hostname connmand[1040]: ntp: adjust (jump): -27302612.028018 sec
...
Nov 21 00:07:05 hostname systemd[1]: Time has been changed

sebelum versi 1.37, connman diberi kode keras untuk memilih gateway default untuk saat itu. Tidak perlu dikonfigurasikan DHCP untuk melakukan ini dan jika klien NTP connman diaktifkan (secara default) maka itu akan melakukan ini terlepas dari konfigurasi lainnya.

Dalam kasus kami, beberapa router rumah benar-benar merespons permintaan NTP ini, tetapi hasilnya sangat tidak dapat diandalkan. Terutama saat router di-boot ulang, router terus membagikan waktu tanpa benar-benar mengetahui waktu yang tepat .

Misalnya kita tahu bahwa setidaknya satu versi BT Home Hub 5 akan, ketika di-reboot, default ke 21 November 2018 dan memberikan tanggal ini melalui NTP. Klien NTP-nya sendiri kemudian akan memperbaiki masalah tetapi ada jendela yang dibagikan pada 21 November 2018.

Yaitu, masalah ini pada akhirnya disebabkan oleh pelanggan kami yang me-reboot router mereka dan penipu baru saja menerima kali ini.

Saya akan mengungkapkan kekesalan saya di sini, tampaknya agresi beberapa orang telah terlalu lama meninggalkan "fitur" ini di penipu. Itu dilaporkan sebagai masalah sejak 2015. Dan itu adalah "fitur" yang sangat tersembunyi. Tidak ada server waktu yang dikonfigurasi dan tidak ada pesan log untuk menjelaskan apa yang dilakukan connman atau dokumentasi mengapa. Jika rig pengujian Anda tidak memiliki server NTP di gateway default, Anda tidak akan pernah melihat ini dalam pengujian.

Cara Memperbaiki

Kami melihat dua opsi yang tampaknya berfungsi:

1. Hapus penipu sepenuhnya. Tampaknya jaringan berfungsi dengan baik tanpanya; kami belum menemukan alasan keberadaannya sejak awal.

   apt-get remove connman
   

2. Nonaktifkan NTP di connman dengan mengedit /var/lib/connman untuk menyertakan:

   [global]
   TimeUpdates=manual