VPS का समय गलत क्यों है और इसे कैसे ठीक करें

आपका 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-backed chip होती है। Guest के अंदर इसे hypervisor द्वारा emulate किया जाता है, इसलिए यह काफी हद तक host का एक artefact है। Linux इसे boot के समय शुरुआती मान के लिए एक बार पढ़ता है, फिर अपनी गिनती खुद रखता है। 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. के साथ fail हो जाता है।

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

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

KVM पर आप आमतौर पर kvm-clock देखेंगे। यह host द्वारा बनाए गए मान को पढ़ता है, और यही कारण है कि बिना किसी 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 fail हो जाता है या कोई device नहीं दिखता है, तो आपका host इसे offer नहीं करता है और 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 file में लिखता है, ताकि यह केवल हर सैंपल का पीछा करने के बजाय घड़ी की प्रवृत्ति को ही ठीक कर सके। यह उन दो स्थितियों से भी जल्दी उबर जाता है जो एक VM में होती हैं लेकिन फिजिकल बॉक्स में नहीं: इसे होस्ट द्वारा pause किया जा सकता है, और चलते समय इसे किसी दूसरे होस्ट पर स्थानांतरित किया जा सकता है। जब होस्ट 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 को हटा देता है। यह सही और अपेक्षित व्यवहार है। कभी भी दोनों को एक साथ न चलाएं, क्योंकि एक ही घड़ी को सेट करने वाले दो डेमन आपस में टकराएंगे और ऐसा होने पर किसी के भी द्वारा रिपोर्ट किए गए offset पर भरोसा नहीं किया जा सकता। 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 को स्टार्टअप पर एक तेज़ burst भेजने का निर्देश मिलता है, जिससे पहला सिंक मिनटों के बजाय सेकंडों में हो जाता है।
• 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 जो एक सप्ताह से चल रहा है और फिर उसमें चालीस सेकंड की त्रुटि मिलती है, तो वह उसे slew करेगा, और चालीस सेकंड को slew करने में आपके द्वारा अपेक्षित समय से कहीं अधिक समय लगता है। इसे एक बार, जानबूझकर, शांत समय पर force करें:

sudo chronyc makestep
chronyc tracking

chronyc tracking को अब शून्य के करीब System time offset रिपोर्ट करना चाहिए, और Last offset को उस आकार को दिखाना चाहिए जिसे अभी ठीक किया गया है। इसे किसी व्यस्त database host पर चलाने से पहले सोचें, क्योंकि पीछे की ओर जंप करने वाली घड़ी उस सॉफ़्टवेयर को भ्रमित कर सकती है जिसने यह मान लिया था कि समय केवल आगे बढ़ता है। Daemon को पुनरारंभ करना उसी सुधार का एक सौम्य संस्करण है, क्योंकि start होने पर 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 करती है, इसलिए date गलत दिखता है जबकि clock सही होती है। 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 को सिस्टम टाइम ज़ोन में format करता है, और journalctl --utc उन्हें UTC में मजबूर करता है। दो अलग-अलग ज़ोन में स्थित दो सर्वर हर घटना को एक conversion exercise में बदल देते हैं, और दबाव में किए गए conversions के कारण ही लोग timeline को गलत पढ़ लेते हैं। सिस्टम को UTC पर रखें, timestamps को UTC में स्टोर करें, और केवल उस बिंदु पर convert करें जहाँ कोई इंसान उन्हें पढ़ रहा हो। जिसे भी किसी एक command के लिए स्थानीय समय देखना हो, वह मशीन को बदले बिना ऐसा कर सकता है:

TZ=Europe/Berlin date

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

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

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

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 सेटिंग है जो महीनों बाद चुपचाप विफल हो सकती है। यह बिल्कुल वैसा ही मामला है जिसे एक रूटीन चेक पकड़ सकता है, लेकिन याददाश्त नहीं। timedatectl और chronyc tracking को एक साथ पढ़ने में केवल दो सेकंड लगते हैं। इन्हें नए VPS पर पहले दस मिनट के काम के हिस्से के रूप में चलाएं, और जब आप नियमित Linux सर्वर मेंटेनेंस चेकलिस्ट पर काम करें, तब भी इन्हें दोहराएं। यदि आप चाहते हैं कि यह चेक अपने आप चले और offset बढ़ने पर अलर्ट दे, तो systemd सर्विस और टाइमर लिखना एक छोटी यूनिट के लिए पैटर्न बताता है जो एक शेड्यूल पर रिपोर्ट करती है। इस तरह का चेक एक daemon के बजाय एक छोटा script होता है, इसलिए इसे डिफ़ॉल्ट के बजाय Type=oneshot की आवश्यकता होती है, और systemd सर्विस प्रकारों का विवरण बताता है कि गलत प्रकार चुनने पर आपको एक ऐसी यूनिट क्यों मिलती है जो बिना काम पूरा किए ही सफलता की रिपोर्ट दे देती है।

FAQ

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

timedatectl चलाएँ और System clock synchronized लाइन को पढ़ें। यह kernel का अपना flag है, जिसे clock को नियंत्रित करने वाला daemon सेट करता है, इसलिए 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 की error दर को सीखता है, और host pause या live migration के बाद जल्दी recover हो जाता है। Debian या Ubuntu पर chrony install करने से systemd-timesyncd अपने आप हट जाता है, क्योंकि दोनों packages time-daemon प्रदान करते हैं। कभी भी एक साथ दो time daemons न चलाएँ।

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

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

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

नहीं, और आपको इसकी आवश्यकता भी नहीं है। एक container host के CLOCK_REALTIME को साझा करता है, क्योंकि Linux time namespaces केवल monotonic और boot-time clocks को ही virtualize करते हैं। एक 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 साल भर में एक बार ही चलती है और अलग-अलग servers के timestamps बिना किसी conversion के एक सीध में रहते हैं। इसे sudo timedatectl set-timezone UTC के साथ सेट करें। जिसे भी local समय देखना हो, वह किसी भी command के आगे TZ=America/New_York date लगा सकता है, जिससे system clock में कोई बदलाव नहीं होता।