Mengapa ntpd tidak memperbarui waktu di server saya?


20

Saya memiliki ntpd berjalan di server saya. Ini semua pengaturan default, kecuali saya berkomentar kemampuannya menjadi server ke komputer lain:

# restrict -4 default kod notrap nomodify nopeer noquery                                                                    
# restrict -6 default kod notrap nomodify nopeer noquery   
restrict default ignore

Jika saya menjalankan ntpdate -q ntp.ubuntu.com, saya diberitahu bahwa jam mesin saya mati 7 detik.

Apa yang sedang terjadi? Bagaimana saya bisa mendiagnosis apa yang terjadi, apakah ada log yang bisa saya nyalakan?

info lebih lanjut # 1

# ntpq -np
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 91.189.94.4     193.79.237.14    2 u   30   64    7  108.518   -0.136   0.361

info lebih lanjut # 2

Inilah yang tampak ketika saya mengajukan pertanyaan:

# ntpdate -q ntp.ubuntu.com
server 91.189.94.4, stratum 2, offset 7.191308, delay 0.13310
10 Jan 20:38:09 ntpdate[31055]: step time server 91.189.94.4 offset 7.191308 sec

Dan inilah yang terlihat seperti sekarang, setelah memulai ulang ntpd beberapa kali (saya berasumsi itulah yang memperbaikinya):

# ntpdate -q ntp.ubuntu.com
server 91.189.94.4, stratum 2, offset 0.000112, delay 0.13164
10 Jan 20:47:03 ntpdate[31419]: adjust time server 91.189.94.4 offset 0.000112 sec

info lebih lanjut # 3

Saya uninstall ntp dan menginstal openntpd dan berlari /usr/sbin/ntpd -d, dan saya melihat output seperti ini:

reply from 64.73.32.134: offset 6.715003 delay 0.041152, next query 30s
reply from 208.53.158.34: offset 6.700224 delay 0.036263, next query 31s
adjusting local clock by 6.734120s
reply from 72.18.205.156: offset 6.708575 delay 0.035885, next query 30s
reply from 64.73.32.134: offset 6.701463 delay 0.044199, next query 33s

Yang bagi saya cukup jelas menunjukkan bahwa saya tidak dapat mengatur waktu di server saya (walaupun, dengan ntp reguler, kadang-kadang tampaknya memperbarui ...).

info lebih lanjut # 4

Penyedia VPS saya mengatakan:

Kernel terbaru seharusnya tidak mengunci sistem Anda ke jam dom0 kami, untuk berada di sisi aman Anda dapat mengatur xen.independent_wallclock = 1 di sysctl.conf Anda.

Yang saya kira masih belum membahas masalah VPS yang membutuhkan CPU yang tersedia untuk melakukan perhitungan waktu yang benar.


Apakah itu seluruh file konfigurasi Anda? Jika Anda menjalankan ntpq -np, apa outputnya?
David Mackintosh

Di mana sisa konfigurasi? Tidak ada server upstream untuk host Anda mendapatkan waktu.
Aaron Copley

6
Oke. Sepertinya ntpd berfungsi normal. NTPd akan "memperlambat" jam Anda kembali ke sinkronisasi secara bertahap. Perubahan waktu yang tiba-tiba dapat menyebabkan masalah besar untuk proses yang berjalan tertentu sehingga NTP bekerja dengan mempercepat atau memperlambat waktu satu detik untuk secara bertahap melakukan penyesuaian.
Aaron Copley

1
Ya, kernel akan mulai dengan jam perangkat keras saat boot karena saat boot itu hanya referensi. Jika sudah berjalan berbulan-bulan, seperti yang Anda katakan, maka itu bukan. Anda dapat memberitahu NTP untuk melakukan sinkronisasi ke jam perangkat keras Anda. Saya tidak yakin tentang Ubuntu tetapi pada sistem berbasis Red Hat yang ada di / etc / sysconfig / ntpd. Anda dapat melihat di sana atau merujuk ke dokumentasi perangkat keras Anda.
Aaron Copley

1
Saya juga tidak berpikir Anda mengerti bahwa ntpdate adalah aplikasi mandiri. Itu tidak ada hubungannya dengan ntpd dan tidak seharusnya digunakan untuk memecahkan masalah itu. Alasan ntpq disarankan dengan opsi -p untuk menunjukkan peering. Jika ntpd melihat rekan Anda, maka itu harus membuat sistem kembali sinkron. Sepertinya semuanya baik-baik saja sekarang. Saya hanya berharap bisa memberikan wawasan tambahan. Semoga ini bisa membantu di masa depan!
Aaron Copley

Jawaban:


10

Anda dapat mengaktifkan masuk ntpd dengan menambahkan ini ke ntp.conf:

logfile /var/log/ntpd.log

Sumber: ntp manual

Jika Anda mematikan ntpd, dapatkah Anda memperbarui jam dengan baris perintah? Jika Anda menjalankan perintah ntpdate dan menerima kesalahan seperti:

# ntpdate ntp.ubuntu.com
10 Jan 23:47:57 ntpdate[26284]: Can't adjust the time of day: Operation not permitted

Ini berarti bahwa Anda mungkin menggunakan VPS, dan dalam hal ini Anda tidak dapat memodifikasi jam sistem - ini hanya dapat dilakukan pada mesin host.


ntpdate senang melakukan hal itu - Tapi saya ingin tahu apakah ketika server saya reboot jam akan diatur ulang ke jam perangkat keras atau hal semacam itu?
John Bachir

Setelah Anda menggunakan ntpdate untuk mengatur jam, gunakan 'hwclock --systohc' untuk menyinkronkan waktu "running" ke jam perangkat keras Anda. Seharusnya disinkronkan pada reboot tetapi jika mesin Anda crash (atau memiliki masalah melakukan shutdown yang benar) itu tidak bisa menyinkronkannya.
Dave Drager

Yah itu vhost, jadi saya tidak punya akses ke jam perangkat keras (setidaknya saya harap tidak!)
John Bachir

Ada jam perangkat keras yang ditiru sama seperti ada BIOS yang ditiru.
Keith Stokes

Saya adalah admin pada beberapa platform VPS, tidak satupun dari mereka (openvz, Xen) memiliki akses untuk mengatur jam pada sistem. Mereka semua harus dilakukan di tingkat tuan rumah. Kirim tiket dengan tuan rumah Anda untuk menunjukkan waktu tidak aktif, mereka harus menjalankan ntp dan menyinkronkan waktu untuk Anda.
Dave Drager

7

Baiklah, pada saat mengajukan pertanyaan ini, saya telah menginstal ulang ntp dengan konfigurasi default vendor (Ubuntu 10.0.4) dan membiarkannya berjalan selama beberapa hari. Pada tulisan ini, ntpdate -q ntp.ubuntu.commenunjukkan bahwa waktu saya akurat dalam 0,000216 detik. Jadi, masalah yang saya alami pasti dengan konfigurasi khusus saya (di mana saya mencoba membuatnya tidak mungkin untuk host eksternal untuk meminta server saya, yang sudah saya lakukan dengan firewall saya jadi saya tidak terlalu khawatir tentang). Berikut ini adalah Ubuntu 10.0.4 ntp.conf secara keseluruhan, dengan komentar yang dihapus:

driftfile /var/lib/ntp/ntp.drift

statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable

server ntp.ubuntu.com

restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery

restrict 127.0.0.1
restrict ::1

Saya menyambut umpan balik tentang bagaimana konfigurasi ini dapat ditingkatkan.

Saya juga membuat tiket dengan penyedia VPS saya meminta mereka untuk rekomendasi terperinci tentang hal terbaik yang harus dilakukan. Saya mengarahkan mereka ke utas ini, dan beberapa dokumentasi lain yang menunjukkan bahwa mungkin alokasi CPU akan menyebabkan masalah waktu. Inilah yang mereka katakan:

Kernel terbaru seharusnya tidak mengunci sistem Anda ke jam dom0 kami, untuk berada di sisi aman Anda dapat mengatur xen.independent_wallclock = 1 di sysctl.conf Anda. Ini akan memastikan instance server tidak mengikuti jam di server host.

dan:

Saya pikir Anda mungkin salah paham sejauh mana masalah ini memengaruhi klien NTP dalam lingkungan tervirtualisasi. Dalam pengalaman saya pada sistem tervirtualisasi pada host Xen (seperti pengaturan kami di Rackspace Cloud) ketidaktepatan yang diwarisi dengan tidak memiliki jam sistem khusus untuk memproses jumlah interupsi menjadi sepersekian detik, bahkan pada sistem yang sangat dimuat. Ini sedikit ketidakakuratan mudah dikelola oleh NTP bahkan jika itu hanya diatur untuk memperbarui waktu server sekali sehari (atau bahkan lebih jarang dari itu).


4

Salah satu komentar Anda mengatakan Anda menjalankan di vhost. Dalam hal ini, Anda mungkin tidak akan terlalu sukses karena rasa waktu vhost Anda akan tergantung baik pada host yang sebenarnya berjalan dan seberapa sibuk keseluruhan vhost itu.

Bergantung pada virtualisasi yang digunakan, vhost mungkin tidak mendapatkan bagian yang stabil dari interupsi dalam periode waktu tertentu. Ini akan membuat jam berjalan lebih cepat, atau lebih lambat, daripada yang sebenarnya terjadi. Karena ntp sedang mencoba untuk mengukur perubahan pada asumsi bahwa jam Anda adalah suku bunga tetap yang lebih cepat atau lebih lambat daripada bagian dunia lainnya, percepatan dan perlambatan ini akan memberikan ntp yang cocok dan mungkin akhirnya akan menyerah, dengan hasil yang ntp -npmenunjukkan server waktu yang ntp dianggap tidak cocok.

Taruhan terbaik Anda jika ini adalah masalahnya mungkin adalah kekuatan kasar rdate -s $serversetiap begitu sering (seperti setiap enam jam) untuk menarik jam di sekitar dengan hidungnya sehingga tidak melayang berlebihan dari sinkronisasi. Tapi akurasi yang halus mungkin di luar jangkauan.


Penyedia hosting saya (cloud rackspace) telah memberi tahu saya bahwa NTP berfungsi dengan baik di lingkungan mereka.
John Bachir

Lihat jawaban saya yang dikirim / diterima untuk apa yang dikatakan penyedia VPS saya tentang jam, dan akses ke pengaturan waktu.
John Bachir

tanggal otomatis dapat mengatur jam mundur, yang dapat memiliki banyak sekali konsekuensi yang tak terduga.
rackandboneman

4

Hal-hal yang saya temukan di masa lalu, ketika saya menggunakan ntpd bukannya openntpd:

  1. Anda perlu mengizinkan akses ke localhost untuk ntpd untuk memulai dengan benar dan benar-benar melakukan hal-hal

    restrict 127.0.0.1
    restrict ::1
    
  2. Meskipun Anda dapat menggunakan nama host untuk aturan server, membuka kembali lubang untuk berbicara dengan server itu berarti menggunakan restrictyang memerlukan alamat IP, jadi saya akhirnya harus menggunakan IP untuk semuanya.

  3. Anda tidak menyebutkan menggunakan restrictuntuk membuka akses kembali ke server Anda. Itu masalah. Coba blok seperti berikut ini:

    # ntp.xs4all.nl
    server          194.109.22.18
    restrict        194.109.22.18
    
  4. Anda memerlukan banyak rekan atau server untuk ntpd, karena ia mencoba menggunakan voting aturan mayoritas untuk berurusan dengan aktor yang buruk. Jadi minimal 4, masih bisa memiliki mayoritas ketika Anda kehilangan satu, lebih disukai 5.

  5. Untuk mengunci akses default, saya dapat menggunakan:

    restrict default notrust nomodify
    

    sehingga masih bisa query, tapi akhirnya saya menggunakan restrict default ignoreseperti yang Anda lakukan ketika ntpd 4.2 mengubah arti notrust. mendesah

  6. Jika Anda tidak menyediakan layanan waktu untuk orang lain, maka Anda mungkin tidak membutuhkan kekuatan penuh ntpd biasa dan Anda harus mempertimbangkannya openntpdsebagai gantinya. Ditulis oleh kru OpenBSD, ini adalah implementasi yang jauh lebih minimal, menggunakan pemisahan hak istimewa dan file konfigurasi yang jauh lebih sederhana. Ini diduga tidak akan memberikan waktu yang sangat tepat seperti yang akan ntpd, tapi cukup mudah untuk server atau workstation biasa.


Ini info bagus. Saya memeriksa openntpd. Pertanyaan: apakah Anda setuju atau tidak setuju dengan orang lain yang mengklaim bahwa menyetel jam pada vhost tidak mungkin?
John Bachir

Dan mungkin Anda dapat menjawab pertanyaan ini: serverfault.com/questions/223511/…
John Bachir

Saya tidak mengerti apa yang Anda katakan dengan berbagai restrictaturan Anda ... apakah aturan-aturan itu memengaruhi server mana yang dapat saya minta waktu juga? Saya pikir itu hanya mempengaruhi node mana yang bisa menanyakan waktu kepada saya.
John Bachir

1
Ini sebuah ide: ingin mengubah jawaban Anda menjadi file ntp.conf minimal lengkap dengan komentar? :-)
John Bachir

Menyetel jam pada vhost tidak disarankan, kecuali Anda dijamin selalu dijadwalkan dengan setidaknya satu CPU, karena jika tidak, waktu yang dirasakan oleh vhost tidak cocok dengan waktu dunia luar. Dom0 harus mempertahankan waktu. Jawaban pertanyaan lain bagus. NTP adalah UDP, jadi Anda harus mengizinkan paket dari server yang Anda tanyakan waktu. Ntpd saya basi ketika saya pindah ke OpenNTPD beberapa tahun yang lalu.
Phil P

3
  • Jika ntpd tidak dapat terhubung dengan server jarak jauh, Anda tidak akan melihat offset untuk server itu.
  • Jika ntpq akan diblokir oleh ntpd, Anda akan melihat pesan kesalahan yang jelas dari ntpq.
  • Jika beberapa layanan lain juga mengatur waktu (seperti alat vmware), Anda akan melihat lompatan offset untuk server (jalankan ntpq -p setiap 70 detik).

The reach 7output ntpq mengindikasikan, bahwa Anda membiarkan ntpd hanya berjalan selama sekitar 4 menit. 7 adalah 111 biner, yang berarti server sudah mencapai 3 kali. ntp menjangkau setiap 64 detik ( pollnilai) dan sudah menunggu 30 detik ( whennilai) sejak kontak terakhir.

The offset -0.136ditunjukkan, bahwa sistem sudah disinkronisasi. Hanya ntpd yang belum menandai server sebagai sumber. Beri saja lebih banyak waktu dan sebuah bintang kecil akan muncul.

Jadi, sebenarnya ntpd Anda sedang disinkronkan. Tetapi ntpd biasanya tidak menyinkronkan dalam satu lompatan besar (seperti ntpdate), tetapi mencoba menyesuaikan waktu secara perlahan dan memastikan beberapa siklus, bahwa waktunya stabil.

PS: Saya sadar, pertanyaannya sudah sangat tua. Tapi masalah ini tak lekang oleh waktu. Dan semua jawaban lain hanya IMHO menyesatkan. ntpd bahkan direkomendasikan oleh VMWare untuk menjaga waktu tetap sinkron.


Jawaban pertama yang bagus, Robert. Selamat datang di situs ini.
kubanczyk

1

Saya menemukan sistem saya mati dan bingung mengapa jam HW tidak disinkronkan dengan jam sistem pada shutdown bersih. Tampaknya ada pengaturan NTP di sysconfig yang perlu diedit untuk mewujudkannya.

Dalam /etc/sysconfig/ntpd:

# Set to 'yes' to sync hw clock after successful ntpdate
SYNC_HWCLOCK=no

Saya atur itu yes. Tentu saja terlebih dahulu memverifikasi bahwa Anda memiliki server NTP yang solid dan jam sistem Anda dapat diandalkan.

Saya tahu itu - kemiringan saya 47 detik dan jam HW saya juga 47 detik. Bingo! Petunjuk pertama saya adalah kegagalan Kerberos yang terlihat di log. Kerberos dan banyak NAS tidak akan berfungsi jika kemiringan jam terlalu besar.

Semoga harimu menyenangkan!


1
Jepret .. itu relevan dengan RHEL / Centos. Mungkin bukan Ubuntu.
Wayne Sweatt


Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.