VPS clock sync समस्या को कैसे ठीक करें

आपका VPS clock क्यों पीछे या आगे हो जाता है

VPS का clock इसलिए drift करता है क्योंकि उसे सही करने वाला कोई process नहीं चल रहा होता। Kernel समय की गणना एक hardware counter से करता है जो या तो थोड़ा तेज चलता है या थोड़ा धीमा, और यदि कोई time sync client न चल रहा हो, तो यह छोटी सी त्रुटि हर घंटे बढ़ती जाती है। Virtual machine के भीतर एक दूसरा कारण भी होता है: आपका guest अन्य guests के साथ physical CPU साझा करता है, इसलिए जिन क्षणों में उसे CPU नहीं मिलता, उन क्षणों में वह समय की गणना नहीं कर पाता।

वर्तमान KVM guest पर counter स्वयं शायद ही कभी वास्तविक समस्या होता है। Paravirtual kvm-clock source उस मान को पढ़ता है जिसे host बनाए रखता है, इसलिए एक सही ढंग से चल रहा guest अपने host के समय का सटीक अनुसरण करता है। जो घड़ियाँ स्पष्ट रूप से गलत होती हैं, वे आमतौर पर किसी साधारण कारण से गलत होती हैं। या तो कोई sync daemon नहीं चल रहा है, या दो daemon एक साथ चल रहे हैं और आपस में टकरा रहे हैं, या outbound UDP port 123 आपके provider के network से बाहर ही नहीं जा पा रहा है। एक guest अपना time discipline host से या NTP (network time protocol) से लेता है, न कि अपने स्वयं के oscillator से।

गलत घड़ी वास्तव में क्या खराब करती है

• TOTP (time-based one-time password) टू-फैक्टर कोड मेल नहीं खाते, इसलिए आप ऐसे सर्वर से लॉक हो जाते हैं जिसका पासवर्ड और की (key) दोनों सही हैं।
• एक मिनट पहले जारी किया गया सर्टिफिकेट अस्वीकार कर दिया जाता है, और curl, SSL certificate problem: certificate is not yet valid प्रिंट करता है।
• apt update, E: Release file for ... is not valid yet (invalid for another 1d 2h 3min 4s) के साथ रिपॉजिटरी को अस्वीकार कर देता है।
• निर्धारित कार्य गलत समय पर शुरू होते हैं, और घड़ी के अचानक बदलने से एक जॉब दो बार चल सकती है जबकि दूसरी छूट सकती है।
• दो सर्वरों के लॉग्स को एक साथ नहीं मिलाया जा सकता, इसलिए घटना की समय-सीमा (timeline) का अनुमान लगाकर निर्माण करना पड़ता है।

सहनशीलता (tolerance) उतनी कम है जितनी अधिकांश लोग उम्मीद नहीं करते। नीचे दिए गए आंकड़े प्रलेखित डिफॉल्ट्स हैं, न कि किसी परीक्षण से लिए गए माप।

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

एक TOTP कोड उस काउंटर से गणना किया जाता है जो हर 30 सेकंड में आगे बढ़ता है, और अधिकांश वेरिफायर दोनों तरफ एक स्टेप स्वीकार करते हैं। प्रत्येक दिशा में आधे मिनट की त्रुटि ही पूरी सीमा है। Kerberos कहीं अधिक उदार है, जिसमें 300 सेकंड की डिफॉल्ट स्क्यू (skew) छूट है। सर्टिफिकेट बिल्कुल भी उदार नहीं है: इसे 0 सेकंड की ग्रेस अवधि के साथ निश्चित क्षणों के विरुद्ध जांचा जाता है, इसलिए एक सेकंड पहले की घड़ी उस सर्टिफिकेट को अस्वीकार कर देती है जो पूरी तरह से वैध है।

तीन घड़ियाँ, और कौन सी महत्वपूर्ण है

System clock वह है जो महत्वपूर्ण है। यह kernel की CLOCK_REALTIME है: 1 January 1970 UTC से अब तक के seconds की गिनती, जो memory में रहती है और हर उस चीज़ द्वारा पढ़ी जाती है जो समय दर्ज करती है। Log lines, certificate checks, TOTP codes और file modification times सभी इसी से आते हैं। जब कोई कहता है कि सर्वर का समय गलत है, तो उनका मतलब इसी घड़ी से होता है।

Hardware clock, जिसे RTC (real time clock) भी कहा जाता है, एक अलग counter है जो मशीन बंद होने पर भी चलता रहता है। एक physical machine पर यह battery से चलने वाली chip होती है। Guest के अंदर इसे hypervisor द्वारा emulate किया जाता है, इसलिए यह काफी हद तक host का एक artefact है। Linux इसे boot के समय शुरुआती value के लिए एक बार पढ़ता है, फिर अपनी गिनती खुद रखता है। timedatectl इसे RTC time line पर print करता है। VPS पर उस line से debug न करें, क्योंकि यह आपके system clock की sync स्थिति के बजाय host के समय के बारे में बताता है। Container में आमतौर पर कोई /dev/rtc नहीं होता है, इसलिए hwclock --show, hwclock: Cannot access the Hardware Clock via any known method. के साथ विफल हो जाता है।

Clocksource वह है जिससे kernel उन reads के बीच गिनती करता है। अपने kernel से पूछें कि उसने किसे चुना है:

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

KVM पर आप आमतौर पर kvm-clock देखेंगे। यह host द्वारा बनाए गए value को पढ़ता है, और यही कारण है कि बिना किसी NTP client वाला KVM guest भी कुछ समय तक लगभग सही रहता है। tsc CPU का अपना counter है। Xen guests xen report करते हैं, और Hyper-V guests hyperv source report करते हैं। इस setting को न बदलें जब तक कि आपके पास इसे बदलने का कोई ठोस कारण न हो, क्योंकि kernel पहले से ही उस hardware पर सबसे अच्छे source को चुनता है जिस पर वह भरोसा करता है।

कुछ hosts guest को PTP (precision time protocol) device भी देते हैं, जो chrony को network के बजाय सीधे host clock को पढ़ने की अनुमति देता है। इसे जाँचना उचित है, और यह अक्सर shared VPS पर उपलब्ध नहीं होता है:

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

यदि modprobe विफल हो जाता है या कोई device दिखाई नहीं देता है, तो आपका host इसे प्रदान नहीं करता है और network NTP ही आपका समाधान है। यदि clock_name KVM virtual clock का नाम बताता है, तो chrony अपनी config में refclock PHC /dev/ptp0 poll 2 line के साथ इसका उपयोग कर सकता है।

अपनी मशीन पर समय की स्थिति पढ़ें

एक कमांड से शुरुआत करें। यह एक ही स्क्रीन में इस प्रश्न का उत्तर देता है कि "क्या कोई चीज़ इस घड़ी को सही रख रही है"।

timedatectl

याद किए गए नंबर पर भरोसा करने के बजाय इन पंक्तियों को पढ़ें:

• Local time और Universal time आपके ज़ोन और UTC में प्रिंट किए गए एक ही क्षण हैं। यदि वे समान हैं, तो मशीन पहले से ही UTC पर है।
• RTC time ऊपर वर्णित हार्डवेयर घड़ी है। VPS पर, इसे अनदेखा करें।
• Time zone वह है जिसका उपयोग सिस्टम स्थानीय समय को फॉर्मेट करने के लिए करता है।
• System clock synchronized कर्नेल का अपना फ्लैग है। एक टाइम डेमन इसे तब सेट करता है जब वह अपने स्रोतों पर भरोसा करता है, इसलिए no का मतलब है कि बूट के बाद से किसी ने भी इस घड़ी को नियंत्रित नहीं किया है।
• NTP service विशेष रूप से systemd-timesyncd पर रिपोर्ट करता है। n/a chrony चलाने वाली मशीन पर सामान्य है, क्योंकि वहां timesyncd इंस्टॉल नहीं होता है। System clock synchronized: yes के साथ NTP service: n/a का मतलब है कि chrony काम कर रहा है और कर्नेल इससे सहमत है।

अगला, पूछें कि आप कितना पीछे या आगे हैं। अपने फोन से इसका अंदाजा न लगाएं। यदि chrony चल रहा है:

chronyc tracking
chronyc sources -v

chronyc tracking उन नंबरों को प्रिंट करता है जो प्रश्न का उत्तर देते हैं। System time NTP समय से वर्तमान ऑफसेट है, जिसके बाद fast या slow शब्द आता है। Last offset सबसे हालिया सुधार का आकार है। Frequency वह दर त्रुटि है जिसे chrony ने आपकी घड़ी में मापा है और पहले से ही उसकी भरपाई कर रहा है। Leap status को Normal पढ़ना चाहिए। यदि यह Not synchronised पढ़ता है और Reference ID, 00000000 () है, तो chrony ने अभी तक किसी स्रोत पर निर्णय नहीं लिया है।

chronyc sources -v सूची के ऊपर एक लीजेंड प्रिंट करता है, ताकि आपको प्रतीकों को याद न रखना पड़े। दो कॉलम अधिकांश अर्थ स्पष्ट करते हैं। प्रत्येक पंक्ति की शुरुआत में स्टेट कैरेक्टर यह बताता है कि chrony उस स्रोत को कैसे रेट करता है, जहाँ * उस स्रोत को चिह्नित करता है जिसका वह वर्तमान में उपयोग कर रहा है और हर पंक्ति पर ? का मतलब है कि कोई भी जवाब नहीं दे रहा है। Reach अंतिम आठ पोल का उत्तर इतिहास है जिसे ऑक्टल में प्रिंट किया गया है: 377 का मतलब है कि सभी आठों का उत्तर दिया गया था, 0 का मतलब है कि किसी का भी नहीं।

यदि इसके बजाय systemd-timesyncd प्रभारी है:

timedatectl timesync-status
timedatectl show-timesync --all

timesync-status उस सर्वर को प्रिंट करता है जिससे वह बात कर रहा है, पोल अंतराल और एक Offset मान। यदि कमांड स्टेटस प्रिंट करने के बजाय सर्विस के बारे में त्रुटि लौटाती है, तो timesyncd इस बॉक्स पर प्रभारी डेमन नहीं है, जो स्वयं आपके प्रश्न का उत्तर है।

बिना किसी अतिरिक्त टूल के बाहरी दुनिया के साथ एक मोटे चेक के लिए, अपनी घड़ी की तुलना एक सार्वजनिक HTTP Date हेडर से करें, जिसे GMT में एक सेकंड के रिज़ॉल्यूशन के साथ परोसा जाता है:

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

यहाँ एक या दो सेकंड का अंतर सामान्य है और इसका कोई मतलब नहीं है। एक मिनट का अंतर आपकी बग है।

VPS पर chrony या systemd-timesyncd

Ubuntu और Debian डिफ़ॉल्ट रूप से systemd-timesyncd के साथ आते हैं। यह एक SNTP (simple network time protocol) क्लाइंट है: यह एक समय में एक सर्वर से पूछताछ करता है और घड़ी को उसके अनुसार समायोजित करता है। ऐसी मशीन पर जो हमेशा ऑनलाइन रहती है और जिसका समय लगभग सही रहता है, यह पर्याप्त है और इसे चलाने में लगभग कोई संसाधन खर्च नहीं होता।

chrony एक पूर्ण NTP कार्यान्वयन है और वर्चुअल मशीन के लिए बेहतर डिफ़ॉल्ट विकल्प है, जिसके कारण आप इसके आउटपुट में देख सकते हैं। यह एक साथ कई स्रोतों से डेटा लेता है और उन स्रोतों को हटा देता है जो मेल नहीं खाते। यह आपकी घड़ी की दर की त्रुटि को मापता है और इसे एक drift फ़ाइल में लिखता है, जिससे यह प्रत्येक सैंपल का पीछा करने के बजाय घड़ी की प्रवृत्ति को सुधारता है। यह उन दो स्थितियों से भी जल्दी उबर जाता है जो एक VM के साथ होती हैं लेकिन भौतिक मशीन के साथ नहीं: इसे इसके होस्ट द्वारा रोका जा सकता है, और इसे चलते समय एक अलग होस्ट पर ले जाया जा सकता है। जब होस्ट PTP डिवाइस उपलब्ध कराया जाता है, तो chrony ही उसे पढ़ता है।

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

apt आउटपुट को ध्यान से पढ़ें। Debian और Ubuntu पर chrony और systemd-timesyncd दोनों पैकेज time-daemon प्रदान करते हैं, इसलिए chrony इंस्टॉल करते समय apt timesyncd को हटा देता है। यह सही और वांछित व्यवहार है। कभी भी दोनों को एक साथ न चलाएं, क्योंकि एक ही घड़ी को सेट करने वाले दो डेमन आपस में टकराएंगे और ऐसा होने पर किसी के भी द्वारा रिपोर्ट किए गए ऑफसेट पर भरोसा नहीं किया जा सकता। Rocky और AlmaLinux पर sudo dnf install -y chrony के साथ इंस्टॉल करें, जहाँ यूनिट का नाम chrony के बजाय chronyd होता है।

Debian और Ubuntu पर कॉन्फ़िगरेशन फ़ाइल /etc/chrony/chrony.conf है, और Rocky और Alma पर /etc/chrony.conf है। वितरण का डिफ़ॉल्ट कॉन्फ़िगरेशन VPS के लिए पहले से ही उपयुक्त है, इसलिए इसे केवल किसी ठोस कारण से ही बदलें। दो निर्देशों को समझना उपयोगी है:

• pool और server लाइनें समय के स्रोतों के नाम बताती हैं। iburst जोड़ने से chrony को स्टार्टअप पर एक तेज़ बर्स्ट भेजने का निर्देश मिलता है, जिससे पहला सिंक मिनटों के बजाय सेकंड में हो जाता है।
• makestep यह तय करता है कि chrony कब घड़ी को सीधे जंप कराएगा और कब धीरे-धीरे समायोजित करेगा। grep -n makestep /etc/chrony/chrony.conf के साथ जांचें कि आपके सिस्टम में क्या सेट है। Debian और Ubuntu का डिफ़ॉल्ट, makestep 1 3, का अर्थ यह है: chronyd शुरू होने के बाद पहले तीन अपडेट के दौरान, यदि समय एक सेकंड से अधिक का अंतर दिखाता है तो घड़ी को सीधे सेट करें, और उसके बाद केवल धीरे-धीरे (slewing) सुधार करें।

यदि आप चाहते हैं कि समय ट्रैफ़िक रास्ते में छेड़छाड़ के विरुद्ध प्रमाणित हो, तो chrony 4 और उसके बाद के संस्करण NTS (network time security) का समर्थन करते हैं। पहले chronyd -v के साथ अपना संस्करण सुनिश्चित करें, और ध्यान दें कि NTS के लिए UDP 123 के साथ-साथ आउटबाउंड TCP पोर्ट 4460 का खुला होना भी आवश्यक है:

server time.cloudflare.com iburst nts

पुनः आरंभ करें और भरोसा करने से पहले सत्यापित करें। यदि कॉन्फ़िगरेशन पार्स होने में विफल रहता है, तो आपके पास कोई समय डेमन नहीं बचेगा, और घड़ी आपको इसकी सूचना नहीं देगी।

sudo systemctl restart chrony
chronyc sources -v
chronyc tracking

घड़ी के मिनटों में गलत होने पर भी वह गलत क्यों बनी रहती है

एक time daemon के पास offset को ठीक करने के दो तरीके होते हैं। Slewing घड़ी की गति को तब तक तेज या धीमा करता है जब तक कि त्रुटि समाप्त न हो जाए, जिससे समय आगे बढ़ता रहता है और कोई भी timestamp न तो दोहराया जाता है और न ही छोड़ा जाता है। Stepping सीधे सही मान पर जंप करती है, जो तेज होता है और घड़ी को पीछे भी ले जा सकता है। Wall clock से बीते हुए समय को मापने वाली किसी भी चीज़ के लिए पीछे जाना खतरनाक है, इसलिए दोनों daemon slewing को प्राथमिकता देते हैं।

यही प्राथमिकता कारण है कि एक बहुत गलत घड़ी लंबे समय तक गलत बनी रह सकती है। chrony केवल उस विंडो के भीतर step करता है जिसकी अनुमति makestep देता है, जो डिफ़ॉल्ट रूप से daemon के शुरू होने के बाद के पहले कुछ अपडेट होते हैं। एक chronyd जो एक सप्ताह से चल रहा है और फिर 40 सेकंड की त्रुटि पाता है, वह इसे slew करेगा, और 40 सेकंड को slew करने में आपके द्वारा प्रतीक्षा किए जाने वाले समय से कहीं अधिक समय लगता है। इसे एक शांत क्षण में, जानबूझकर, एक बार force करें:

sudo chronyc makestep
chronyc tracking

chronyc tracking को अब शून्य के करीब एक System time offset की रिपोर्ट करनी चाहिए, और Last offset को उस मान का आकार दिखाना चाहिए जिसे अभी ठीक किया गया है। इसे व्यस्त database host पर चलाने से पहले सोचें, क्योंकि पीछे की ओर कूदने वाली घड़ी उस सॉफ़्टवेयर को भ्रमित कर सकती है जिसने यह माना था कि समय केवल आगे बढ़ता है। Daemon को पुनरारंभ करना उसी सुधार का अधिक सौम्य संस्करण है, क्योंकि makestep विंडो शुरू होने पर फिर से खुल जाती है।

Containers host की clock साझा करते हैं

Container की अपनी कोई wall clock नहीं होती, इसलिए इसके अंदर sync करने के लिए कुछ भी नहीं होता है। Linux time namespaces केवल monotonic और boot-time clocks को ही virtualise करती हैं। CLOCK_REALTIME virtualised नहीं है, जिसका अर्थ है कि container उसी system clock को पढ़ता है जिस पर वह host चल रहा है। Host पर clock को ठीक करें और उस host पर मौजूद हर container उसी क्षण ठीक हो जाता है।

इसके कुछ परिणाम होते हैं। Image में chrony या ntpd install न करें, क्योंकि यह ज्यादा से ज्यादा कुछ नहीं करेगा। Unprivileged container के अंदर date सेट करना date: cannot set date: Operation not permitted के साथ विफल हो जाता है, क्योंकि kernel को उस call के लिए CAP_SYS_TIME की आवश्यकता होती है। CAP_SYS_TIME प्रदान करने से container को private clock नहीं मिलती, बल्कि यह container को host की clock बदलने की क्षमता देता है और इसलिए हर दूसरे container की clock भी बदल जाती है।

Container के अंदर अलग time zone होना clock की समस्या नहीं है। अपनी खुद की /etc/localtime वाली image उसी क्षण को दूसरे zone के लिए format करके print करती है, इसलिए clock सही होने के बावजूद date गलत दिखाई देता है। Container environment में TZ=UTC सेट करें और भ्रम दूर हो जाएगा। आपके द्वारा चुना गया runtime यहाँ कुछ भी नहीं बदलता है, और rootless Podman और Docker की तुलना में यह बताया गया है कि वह क्या बदलता है।

Time zones: सर्वर पर UTC, लोगों के लिए स्थानीय समय

मशीन को UTC पर सेट करें और उसे वहीं रहने दें।

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

UTC में daylight saving नहीं होती है, और यही इसका मुख्य तर्क है। जिस zone में daylight saving का पालन होता है, वहाँ 02:30 बजे चलने वाला daily job घड़ियाँ पीछे होने वाले दिन दो बार चलता है, और घड़ियाँ आगे होने वाले दिन बिल्कुल नहीं चलता। man 8 cron तीन घंटे से कम के बदलावों के लिए विशेष हैंडलिंग का दस्तावेजीकरण करता है: आगे कूदने (forward jump) के कारण छूटे हुए jobs बदलाव के तुरंत बाद चलते हैं, और पीछे कूदने (backward jump) के कारण दोहराए गए घंटे में आने वाले jobs दूसरी बार नहीं चलते। यह व्यवहार उचित है, लेकिन फिर भी यह ऐसा व्यवहार है जिसके बारे में आपको 03:00 बजे सोचने की आवश्यकता नहीं होनी चाहिए। UTC के तहत job साल के हर दिन, दिन में एक बार चलता है। यदि आपका कोई job किसी अजीब समय पर चलने के बजाय पूरी तरह से गायब है, तो cron job के चुपचाप न चलने के कारण अधिक संभावित स्पष्टीकरण है।

यही तर्क logs पढ़ने पर भी लागू होता है। journalctl timestamps को system time zone में format करता है, और journalctl --utc उन्हें UTC में बाध्य करता है। दो अलग-अलग zones में स्थित दो सर्वर हर घटना को एक conversion exercise में बदल देते हैं, और दबाव में किए गए conversions के कारण ही लोग timeline को गलत पढ़ते हैं। सिस्टम को UTC पर रखें, timestamps को UTC में store करें, और केवल उस बिंदु पर convert करें जहाँ कोई इंसान उन्हें पढ़ रहा हो। जो कोई भी किसी एक command के लिए स्थानीय समय देखना चाहता है, वह मशीन को बदले बिना ऐसा कर सकता है:

TZ=Europe/Berlin date

timedatectl output की एक और पंक्ति इस अनुभाग से संबंधित है। RTC in local TZ को no पढ़ना चाहिए। इसे yes पर सेट करना laptop पर Windows dual-boot करने के लिए एक workaround है, और सर्वर पर यह केवल एक offset जोड़ता है जिससे बाद में किसी को परेशानी हो सकती है। जब यह सेट होता है, तो timedatectl एक चेतावनी देता है कि सिस्टम RTC time को local time zone में पढ़ने के लिए कॉन्फ़िगर किया गया है।

लक्षणों के आधार पर समस्या निवारण

एक सर्वर पर आपका two-factor कोड अस्वीकार कर दिया जाता है। किसी भी अन्य चीज़ की जाँच करने से पहले घड़ी की जाँच करें। कोड एक ऐसे काउंटर से आता है जो हर 30 सेकंड में आगे बढ़ता है, इसलिए यदि सर्वर 90 सेकंड पीछे है, तो वह ऐसे स्टेप का कोड गणना करता है जिसे आपका फोन पहले ही पार कर चुका है। timedatectl में System clock synchronized: no दिखाई देगा, या chronyc tracking एक बड़ा System time ऑफसेट रिपोर्ट करेगा। यह पूरी तरह से अस्वीकृत की (key) से अलग विफलता है, जो अपना स्वयं का संदेश प्रिंट करती है और publickey प्रमाणीकरण विफलताओं के लिए गाइड में कवर की गई है।

apt update कहता है कि Release फाइल अभी वैध नहीं है। पूरा संदेश रिपॉजिटरी का नाम और यह बताता है कि यह कब तक अमान्य रहेगी, उदाहरण के लिए is not valid yet (invalid for another 1d 2h 3min 4s)। आपकी घड़ी रिपॉजिटरी की Release फाइल के अंदर की तारीख से पीछे है, और वह अवधि सीधे तौर पर यह मापती है कि आप कितना पीछे हैं। घड़ी को ठीक करें। इसे पार करने के लिए apt की तारीख जाँच को अक्षम न करें, क्योंकि यह जाँच ही वह चीज़ है जो किसी को आपको पुराना पैकेज इंडेक्स देने से रोकती है।

हर सोर्स लाइन unreachable स्थिति दिखाती है और Reach 0 है। कोई भी उत्तर नहीं दे रहा है, इसलिए अपने कॉन्फ़िगरेशन के बजाय egress (बाहर जाने वाले ट्रैफ़िक) को देखें। NTP आउटबाउंड UDP पोर्ट 123 है, और कुछ नेटवर्क इसे फ़िल्टर या रीडायरेक्ट करते हैं। sudo chronyc ntpdata प्रति-स्रोत काउंटर प्रिंट करता है जिसमें Total TX और Total RX शामिल हैं। एक TX काउंट जो बढ़ता है जबकि RX शून्य पर रहता है, इसका मतलब है कि आपके पैकेट बाहर जा रहे हैं और कुछ भी वापस नहीं आ रहा है, जो आपके और स्रोत के बीच एक फ़ायरवॉल की ओर इशारा करता है।

घड़ी सही थी, फिर अचानक बदल गई। होस्ट इवेंट ऐसा करते हैं। एक रिस्टोर किया गया स्नैपशॉट, एक पॉज़ किया गया गेस्ट, या किसी अन्य होस्ट पर लाइव माइग्रेशन गेस्ट के समय को वास्तविक समय से पीछे छोड़ सकता है। chrony अगले पोल पर इसे नोटिस करता है और ठीक करता है; systemd-timesyncd पहले एक लंबे पोल अंतराल की प्रतीक्षा कर सकता है। पुष्टि करें कि डेमन बूट पर systemctl is-enabled chrony के साथ शुरू होता है, क्योंकि हाथ से शुरू किया गया डेमन अगले रीबूट के बाद गायब हो जाता है।

ऑफसेट छोटा है लेकिन कभी स्थिर नहीं होता। CPU steal को देखें। एक गेस्ट जिसे तब शेड्यूल नहीं किया जाता जब उसका टाइमर इंटरप्ट देय होता है, उसके सैंपल्स में देरी हो जाती है, इसलिए ऑफसेट स्थिर होने के बजाय भटकता रहता है। top इसे CPU लाइन पर st आंकड़े के रूप में दिखाता है। शेयर्ड होस्ट पर CPU steal टाइम पढ़ना बताता है कि उस नंबर का क्या अर्थ है और आप इसके बारे में क्या कर सकते हैं।

आपके द्वारा अभी जारी किया गया प्रमाणपत्र 'अभी तक वैध नहीं' के रूप में अस्वीकार कर दिया गया है। curl में SSL certificate problem: certificate is not yet valid प्रिंट होता है, और ब्राउज़र भी कुछ ऐसा ही कहते हैं। प्रमाणपत्र ठीक है; इसकी जाँच करने वाली घड़ी पीछे है। कोई भी मशीन दोषी हो सकती है, इसलिए क्लाइंट और सर्वर दोनों की जाँच करें। यदि इसे जारी करने वाला सर्वर वह है जिसकी घड़ी गलत है, तो certbot और nginx प्रमाणपत्र गाइड उसी सेटअप के नवीनीकरण पक्ष को कवर करती है।

इसे अपने मौजूदा चेक में शामिल करें

Time sync एक ऐसी boot-time सेटिंग है जो महीनों बाद चुपचाप विफल हो जाती है। यह बिल्कुल वैसा ही मामला है जिसे एक routine पकड़ लेती है, लेकिन याददाश्त नहीं। timedatectl और chronyc tracking को एक साथ पढ़ने में दो सेकंड लगते हैं। इन्हें नए VPS पर पहले दस मिनट के हिस्से के रूप में चलाएं, और जब आप नियमित Linux सर्वर मेंटेनेंस चेकलिस्ट पर काम करें, तब भी इन्हें दोहराएं। यदि आप चाहते हैं कि यह चेक अपने आप चले और offset बढ़ने पर अलर्ट दे, तो systemd service और timer लिखना एक छोटी unit के लिए उस पैटर्न को कवर करता है जो एक schedule पर रिपोर्ट करती है।

FAQ

मैं यह कैसे जाँचूँ कि मेरा VPS clock सिंक में है या नहीं?

timedatectl चलाएँ और System clock synchronized लाइन को पढ़ें। यह kernel का अपना flag है, जिसे वह daemon सेट करता है जो clock को नियंत्रित कर रहा है, इसलिए chrony मशीन पर yes के साथ NTP service: n/a का दिखना सामान्य और सही है। error के आकार के लिए, chronyc tracking चलाएँ और System time पढ़ें, या यदि systemd-timesyncd का उपयोग हो रहा है तो timedatectl timesync-status चलाएँ और Offset पढ़ें। मशीन के बाहर किसी चीज़ के साथ जाँच करने के लिए, date -u की तुलना किसी भी HTTPS साइट द्वारा लौटाए गए Date header से करें।

क्या मुझे VPS पर chrony या systemd-timesyncd का उपयोग करना चाहिए?

महत्वपूर्ण कार्यों के लिए chrony का उपयोग करें। systemd-timesyncd एक SNTP client है जो केवल एक सर्वर का अनुसरण करता है, और यह ऐसी मशीन के लिए ठीक है जो हमेशा online रहती है और शुरू से ही सही समय के करीब होती है। chrony कई sources से जानकारी लेता है, असहमत sources को हटा देता है, आपकी clock की दर में होने वाली त्रुटि को सीखता है, और host के pause या live migration के बाद जल्दी रिकवर हो जाता है। Debian या Ubuntu पर chrony इंस्टॉल करने से systemd-timesyncd अपने आप हट जाता है, क्योंकि दोनों packages time-daemon प्रदान करते हैं। कभी भी दो time daemons एक साथ न चलाएँ।

मेरे TOTP codes एक सर्वर पर विफल क्यों होते हैं जबकि अन्य सभी जगह काम करते हैं?

क्योंकि TOTP code वर्तमान समय का एक function है। यह code एक counter से आता है जो हर 30 seconds में आगे बढ़ता है, इसलिए सर्वर और आपके फोन का इस बात पर सहमत होना जरूरी है कि अभी कौन सा step चल रहा है। अधिकांश verifiers एक step आगे या पीछे की अनुमति देते हैं, जिससे दोनों दिशाओं में लगभग आधे मिनट की छूट मिलती है। उस सर्वर पर timedatectl की जाँच करें। यदि System clock synchronized में no दिखाई देता है, तो sync ठीक करें और shared secret में कोई बदलाव किए बिना codes फिर से मेल खाने लगेंगे।

क्या मैं Docker container के अंदर समय सेट कर सकता हूँ?

नहीं, और आपको इसकी आवश्यकता भी नहीं है। एक container host के CLOCK_REALTIME को साझा करता है, क्योंकि Linux time namespaces केवल monotonic और boot-time clocks को ही virtualise करते हैं। एक unprivileged container को date: cannot set date: Operation not permitted मिलता है, और CAP_SYS_TIME जोड़ने से वह host की clock को ही बदल देता है, न कि उसे अपनी अलग clock देता है। host को ही sync करें। container के अंदर अलग local time का मतलब time zone setting है, इसलिए container environment में TZ सेट करें।

क्या सर्वर को UTC या local time का उपयोग करना चाहिए?

UTC का उपयोग करें, और जब कोई व्यक्ति output पढ़े तब local time लागू करें। UTC कभी भी daylight saving के लिए नहीं बदलता, इसलिए एक daily job साल भर में एक बार ही चलती है और अलग-अलग सर्वरों के timestamps बिना किसी conversion के एक सीध में रहते हैं। इसे sudo timedatectl set-timezone UTC के साथ सेट करें। जो कोई भी local समय देखना चाहता है, वह किसी भी command के आगे उसे लगा सकता है, उदाहरण के लिए TZ=America/New_York date, जो system clock के बारे में कुछ भी नहीं बदलता है।