VPS चे घड्याळ पुढे-मागे होते? दुरुस्ती कशी करावी

VPS वरील घड्याळ का पुढे-मागे होते

VPS वरील घड्याळ पुढे-मागे होते कारण ते दुरुस्त करणारी कोणतीही यंत्रणा चालू नसते. kernel वेळ मोजणाऱ्या hardware counter कडून वेळ मोजतो. हा counter थोडा जलद किंवा थोडा मंद चालू शकतो. time sync client चालू नसल्यास ही लहान चूक प्रत्येक तासागणिक वाढत जाते. virtual machine मध्ये आणखी एक कारण असते. तुमचा guest इतर guests सोबत physical CPU सामायिक करतो. त्यामुळे तो schedule न झालेला वेळ मोजू शकत नाही.

सध्याच्या KVM guest मध्ये counter हीच समस्या असण्याची शक्यता कमी असते. paravirtual kvm-clock source host कडून राखली जाणारी value वाचतो. त्यामुळे निरोगी guest आपल्या host च्या वेळेशी जवळून जुळतो. स्पष्टपणे चुकीची दिसणारी घड्याळे सहसा अधिक साध्या कारणामुळे चुकीची असतात. कोणताही sync daemon चालू नसतो, किंवा दोन daemon एकमेकांशी संघर्ष करत असतात, किंवा outbound UDP port 123 तुमच्या provider च्या network बाहेर जातच नाही. guest आपली वेळ-सुसूत्रता host कडून किंवा NTP (network time protocol) कडून घेतो; स्वतःच्या oscillator कडून नाही.

प्रत्यक्षात चुकीचे घड्याळ कोणत्या गोष्टी बिघडवते

• TOTP (time-based one-time password) two-factor codes जुळत नाहीत. त्यामुळे password आणि key दोन्ही बरोबर असूनही server मधून तुमचा प्रवेश बंद होतो.
• एक मिनिटापूर्वी जारी केलेले certificate नाकारले जाते आणि 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) सह repository स्वीकारण्यास नकार देते.
• Scheduled काम चुकीच्या वेळी चालते. घड्याळात अचानक बदल झाल्यास एखादे काम दोनदा चालू शकते, तर दुसरे काम वगळले जाऊ शकते.
• दोन server वरील logs एकाच क्रमात लावता येत नाहीत. त्यामुळे incident timeline अंदाजाने तयार करावी लागते.

ही tolerance बहुतेक लोकांच्या अपेक्षेपेक्षा कमी असते. खालील आकडे documented defaults आहेत; ते test मधून घेतलेली measurements नाहीत.

[
  {
    "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 code हा प्रत्येक 30 सेकंदांनी पुढे जाणाऱ्या counter वरून मोजला जातो. बहुतेक verifiers एक step आधी किंवा नंतरचा code स्वीकारतात. प्रत्येक दिशेतील अर्ध्या मिनिटाची चूक ही संपूर्ण अनुमत मर्यादा आहे. Kerberos अधिक सहनशील आहे. त्याची default skew allowance 300 सेकंद आहे. Certificate मात्र अजिबात सहनशील नसते. ते fixed instants विरुद्ध तपासले जाते आणि 0 सेकंदांचा grace period असतो. त्यामुळे घड्याळ एक सेकंद मागे असल्यास पूर्णपणे वैध certificate नाकारले जाते.

तीन घड्याळे आणि त्यांपैकी कोणते महत्त्वाचे आहे

system clock हे महत्त्वाचे घड्याळ आहे. ते kernel चे CLOCK_REALTIME आहे: UTC नुसार 1 January 1970 पासूनच्या सेकंदांची संख्या. हे मूल्य memory मध्ये ठेवले जाते आणि वेळ नोंदवणाऱ्या सर्व घटकांकडून वाचले जाते. Log lines, certificate checks, TOTP codes आणि file modification times याच घड्याळावर आधारित असतात. कोणी server ची वेळ चुकीची आहे असे म्हणते, तेव्हा त्यांचा संदर्भ याच घड्याळाशी असतो.

hardware clock, ज्याला RTC (real time clock) असेही म्हणतात, हा स्वतंत्र counter आहे. Machine बंद असतानाही तो सुरू राहतो. Physical machine मध्ये तो battery-backed chip असतो. Guest मध्ये hypervisor त्याचे emulation करतो, त्यामुळे तो मुख्यतः host कडून मिळणारा घटक असतो. Linux boot वेळी सुरुवातीचे मूल्य मिळवण्यासाठी तो एकदा वाचतो आणि त्यानंतर स्वतःची गणना सुरू ठेवतो. timedatectl ते RTC time line वर दाखवते. VPS वर त्या line वरून troubleshooting करू नका, कारण ती तुमच्या system clock च्या sync state ऐवजी host च्या वेळेविषयीची कल्पना दाखवते. Container मध्ये सहसा /dev/rtc उपलब्धच नसते, त्यामुळे hwclock --show hwclock: Cannot access the Hardware Clock via any known method. सह fail होते.

clocksource म्हणजे या वाचनांदरम्यान kernel ज्याच्या मदतीने वेळ मोजतो तो स्रोत. तुमच्या 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 दाखवतात आणि Hyper-V guests hyperv source दाखवतात. हे setting बदलण्याचे मोजलेले कारण नसल्यास ते तसेच ठेवा, कारण त्या hardware वर विश्वास ठेवता येणारा सर्वोत्तम source kernel आधीच निवडतो.

काही 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 ते देत नाही आणि network NTP हाच पर्याय आहे. clock_name मध्ये KVM virtual clock दिसत असल्यास, configuration मधील refclock PHC /dev/ptp0 poll 2 line वापरून chrony त्याचा उपयोग करू शकते.

तुमच्या मशीनवरील वेळेची स्थिती वाचा

एका command पासून सुरुवात करा. एका screen मध्ये “हे clock अचूक ठेवणारी कोणतीही यंत्रणा कार्यरत आहे का?” या प्रश्नाचे उत्तर मिळते.

timedatectl

तुम्हाला आठवत असलेल्या एखाद्या संख्येवर विश्वास ठेवण्याऐवजी या ओळी वाचा:

• Local time आणि Universal time हे तुमच्या time zone मध्ये आणि UTC मध्ये छापलेले एकाच क्षणाचे वेळ-मूल्य आहेत. ती दोन्ही एकसारखी असल्यास मशीन आधीपासून UTC वर आहे.
• RTC time हे वर वर्णन केलेले hardware clock आहे. VPS वर ते दुर्लक्षित करा.
• Time zone local time format करण्यासाठी system वापरत असलेली time zone आहे.
• System clock synchronized हा kernel चा स्वतःचा flag आहे. Time daemon त्याच्या sources वर विश्वास बसल्यानंतर तो set करतो. त्यामुळे no म्हणजे boot झाल्यापासून या clock ची कोणत्याही daemon ने शिस्तबद्ध दुरुस्ती केलेली नाही.
• NTP service विशेषतः systemd-timesyncd ची स्थिती दाखवते. chrony चालू असलेल्या मशीनवर n/a सामान्य आहे, कारण तेथे timesyncd install केलेले नसते. System clock synchronized: yes आणि NTP service: n/a एकत्र दिसत असल्यास chrony हे काम करत आहे आणि kernel त्याच्याशी सहमत आहे.

यानंतर तुमची वेळ किती चुकली आहे ते तपासा. फोनवरील वेळेशी अंदाजाने तुलना करू नका. chrony चालू असल्यास:

chronyc tracking
chronyc sources -v

chronyc tracking या प्रश्नाचे उत्तर देणारे आकडे छापते. System time हे NTP time पासूनचा सध्याचा offset आहे. त्यानंतर fast किंवा slow हा शब्द येतो. Last offset ही सर्वात अलीकडील correction ची व्याप्ती आहे. Frequency हा chrony ने तुमच्या clock मध्ये मोजलेला rate error आहे आणि chrony त्याची आधीच भरपाई करत आहे. Leap status मध्ये Normal दिसायला हवे. त्यात Not synchronised दिसत असेल आणि Reference ID हे 00000000 () असेल, तर chrony ने अद्याप कोणता source वापरायचा हे निश्चित केलेले नाही.

chronyc sources -v list च्या वर legend छापते, त्यामुळे symbols लक्षात ठेवण्याची गरज नसते. दोन columns मधून बहुतेक माहिती मिळते. प्रत्येक line च्या सुरुवातीचा state character chrony त्या source चे मूल्यांकन कसे करते ते दाखवतो. * हा सध्या वापरात असलेला source दर्शवतो. प्रत्येक line वर ? असल्यास कोणताही source उत्तर देत नाही. Reach मध्ये मागील आठ polls चा reply history octal स्वरूपात छापला जातो. 377 म्हणजे आठही polls ना उत्तर मिळाले; 0 म्हणजे एकाही poll ला उत्तर मिळाले नाही.

systemd-timesyncd जबाबदार असल्यास:

timedatectl timesync-status
timedatectl show-timesync --all

timesync-status कोणत्या server शी संपर्क साधला जात आहे, poll interval आणि Offset value छापते. Command status छापण्याऐवजी service संबंधी error देत असल्यास, या box वर timesyncd हा daemon जबाबदार नाही. हेच तुमच्या प्रश्नाचे उत्तर आहे.

कोणतेही अतिरिक्त tools न वापरता बाहेरील जगाशी साधारण तुलना करण्यासाठी, तुमच्या clock ची सार्वजनिक HTTP Date header शी तुलना करा. ही header GMT मध्ये, one second resolution सह दिली जाते:

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

येथे one second किंवा two seconds चा फरक सामान्य आहे आणि त्याचा अर्थ काहीही गंभीर नाही. One minute चा फरक असल्यास समस्या तुमच्या configuration मध्ये आहे.

VPS वर chrony किंवा systemd-timesyncd

Ubuntu आणि Debian मध्ये systemd-timesyncd डीफॉल्टनुसार उपलब्ध असते. हे SNTP (simple network time protocol) क्लायंट आहे. ते एका वेळी एका सर्व्हरची चौकशी करते आणि त्यानुसार घड्याळाची वेळ हळूहळू दुरुस्त करते. नेहमी ऑनलाइन असलेल्या आणि सुरुवातीला साधारणपणे अचूक वेळ असलेल्या मशीनसाठी हे पुरेसे आहे. ते चालवण्यासाठी जवळजवळ कोणतीही अतिरिक्त साधने लागत नाहीत.

chrony ही पूर्ण NTP अंमलबजावणी आहे. आभासी मशीनवर ती अधिक योग्य डीफॉल्ट आहे. याची कारणे तिच्या स्वतःच्या आउटपुटमध्ये दिसतात. ती एकाच वेळी अनेक स्रोतांकडून माहिती घेते आणि परस्पर विसंगत असलेले स्रोत वगळते. ती तुमच्या घड्याळाच्या दरातील त्रुटी मोजून ती drift file मध्ये लिहिते. त्यामुळे प्रत्येक नमुन्याचा पाठलाग करण्याऐवजी घड्याळाची नैसर्गिक चूक दुरुस्त केली जाते. भौतिक सर्व्हरच्या तुलनेत VM मध्ये घडणाऱ्या दोन परिस्थितींमधूनही ती लवकर सावरते: host तिला pause करू शकतो आणि चालू असतानाच वेगळ्या host वर हलवू शकतो. host कडून PTP device उपलब्ध करून दिल्यास ते वाचण्याचे काम 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 या दोन्ही packages कडून time-daemon उपलब्ध असल्यामुळे chrony install करताना apt timesyncd काढून टाकते. हे योग्य आणि अपेक्षित आहे. दोन्ही एकाच वेळी कधीही चालवू नका. समान घड्याळाची वेळ सेट करणारे दोन daemons परस्परविरोधी काम करतील आणि ते चालू असताना त्यांपैकी कोणत्याही daemon ने सांगितलेल्या offset वर विश्वास ठेवता येणार नाही. Rocky आणि AlmaLinux वर sudo dnf install -y chrony वापरून install करा. तेथे unit चे नाव chronyd आहे, chrony नाही.

Debian आणि Ubuntu वर configuration file /etc/chrony/chrony.conf आहे, तर Rocky आणि Alma वर ती /etc/chrony.conf आहे. VPS साठी distribution default आधीच योग्य आहे. त्यामुळे कारण असल्याशिवाय त्यात बदल करू नका. दोन directives समजून घेणे उपयुक्त आहे:

• pool आणि server ओळी time sources ची नावे देतात. iburst जोडल्यास chrony startup वेळी जलद burst पाठवते. त्यामुळे पहिला sync काही मिनिटांऐवजी काही सेकंदांत होतो.
• chrony ने घड्याळाची वेळ हळूहळू बदलण्याऐवजी थेट बदलावी की नाही हे makestep ठरवते. तुमच्या configuration मध्ये काय आहे ते grep -n makestep /etc/chrony/chrony.conf वापरून तपासा. Debian आणि Ubuntu मधील डीफॉल्ट makestep 1 3 याचा अर्थ असा आहे: chronyd सुरू झाल्यानंतरच्या पहिल्या तीन updates दरम्यान घड्याळाची वेळ एक सेकंदापेक्षा जास्त चुकीची असल्यास ती थेट दुरुस्त करा. त्यानंतर फक्त हळूहळू वेळ समायोजित करा.

मार्गातील छेडछाडीपासून time traffic चे authentication हवे असल्यास chrony 4 आणि त्यानंतरच्या आवृत्त्या NTS (network time security) चे समर्थन करतात. प्रथम chronyd -v वापरून तुमची आवृत्ती तपासा. NTS साठी UDP 123 सोबत outbound TCP port 4460 देखील खुला असणे आवश्यक आहे:

server time.cloudflare.com iburst nts

विश्वास ठेवण्यापूर्वी सेवा restart करून पडताळणी करा. Configuration parse करण्यात अपयशी ठरल्यास कोणताही time daemon चालू राहत नाही. घड्याळ स्वतःहून ही बाब तुम्हाला सांगणार नाही.

sudo systemctl restart chrony
chronyc sources -v
chronyc tracking

काही मिनिटांनी चुकीचे असलेले घड्याळ चुकीचेच का राहते

Time daemon कडे offset दुरुस्त करण्याचे दोन मार्ग असतात. Slewing मध्ये error नाहीसा होईपर्यंत घड्याळाचा वेग वाढवला किंवा कमी केला जातो. त्यामुळे वेळ पुढेच सरकते आणि कोणताही timestamp पुन्हा येत नाही किंवा वगळला जात नाही. Stepping मध्ये घड्याळ थेट योग्य मूल्यावर नेले जाते. ही पद्धत जलद असते, परंतु घड्याळ मागे जाऊ शकते. Wall clock वरून elapsed time मोजणाऱ्या कोणत्याही गोष्टीसाठी मागे जाणे धोकादायक असते. त्यामुळे दोन्ही daemon प्राधान्याने slew करतात.

या प्राधान्यामुळे मोठ्या प्रमाणात चुकीचे असलेले घड्याळ बराच काळ चुकीचे राहू शकते. chrony फक्त makestep परवानगी देत असलेल्या window मध्येच step करते. Default नुसार ही window daemon सुरू झाल्यानंतरच्या पहिल्या काही updates पुरती असते. एक आठवडा सुरू असलेल्या chronyd ला नंतर चाळीस सेकंदांचा error आढळला, तर तो तो error slew करेल. चाळीस सेकंद slew करण्यास तुम्हाला प्रतीक्षा करावीशी वाटेल त्यापेक्षा खूप जास्त वेळ लागतो. शांत वेळ निवडून हे एकदा जाणीवपूर्वक force करा:

sudo chronyc makestep
chronyc tracking

chronyc tracking ने आता जवळपास शून्य असलेला System time offset दाखवला पाहिजे. Last offset ने नुकत्याच दुरुस्त केलेल्या मूल्याचा आकार दाखवला पाहिजे. व्यस्त database host वर ही command चालवण्यापूर्वी विचार करा, कारण मागे जाणारे घड्याळ वेळ फक्त पुढे सरकते असे गृहीत धरणाऱ्या software मध्ये गोंधळ निर्माण करू शकते. Daemon पुन्हा सुरू करणे हा याच दुरुस्तीचा अधिक सौम्य प्रकार आहे, कारण सुरू होताना makestep window पुन्हा उघडते.

कंटेनर host चे घड्याळ सामायिक करतात

कंटेनरचे स्वतःचे wall clock नसते, त्यामुळे त्यामध्ये sync करण्यासारखे काही नसते. Linux time namespaces केवळ monotonic आणि boot-time clocks virtualise करतात. CLOCK_REALTIME virtualise केलेले नसते. त्यामुळे कंटेनर ज्या host वर चालतो, त्याच host चे system clock तो वाचतो. host वरील clock दुरुस्त केल्यावर त्या host वरील प्रत्येक कंटेनर त्याच क्षणी दुरुस्त होतो.

यामुळे काही परिणाम होतात. Image मध्ये chrony किंवा ntpd install करू नका, कारण सर्वोत्तम परिस्थितीतही त्याचा काही उपयोग होत नाही. Unprivileged कंटेनरमध्ये date सेट केल्यास date: cannot set date: Operation not permitted error येतो, कारण त्या call साठी kernel ला CAP_SYS_TIME आवश्यक असते. CAP_SYS_TIME grant केल्याने कंटेनरला private clock मिळत नाही. त्याऐवजी host चे clock बदलण्याची क्षमता मिळते आणि त्यामुळे इतर प्रत्येक कंटेनरचे clock देखील बदलते.

कंटेनरमध्ये वेगळा time zone असणे ही clock ची समस्या नाही. स्वतःचे /etc/localtime असलेली image त्याच instant ला दुसऱ्या zone साठी format करून दाखवते. त्यामुळे date चुकीचे दिसते, परंतु clock बरोबर असते. कंटेनरच्या environment मध्ये TZ=UTC सेट करा. त्यामुळे हा गोंधळ दूर होतो. तुम्ही निवडलेला runtime येथे काहीही बदलत नाही. rootless Podman आणि Docker ची तुलना त्यातून काय बदलते हे स्पष्ट करते.

वेळ क्षेत्रे: सर्व्हरवर UTC, वापरकर्त्यांसाठी स्थानिक वेळ

मशीन UTC वर सेट करा आणि ती तशीच ठेवा.

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

UTC मध्ये daylight saving नसते, आणि हाच मुख्य मुद्दा आहे. daylight saving वापरणाऱ्या वेळ क्षेत्रातील 02:30 वाजताची दैनिक job घड्याळ मागे केल्याच्या दिवशी दोनदा चालते आणि घड्याळ पुढे केल्याच्या दिवशी अजिबात चालत नाही. man 8 cron तीन तासांपेक्षा कमी कालावधीच्या बदलांसाठी विशेष हाताळणी नोंदवते: घड्याळ पुढे केल्यामुळे चुकलेल्या jobs बदलानंतर लवकरच चालवल्या जातात आणि घड्याळ मागे केल्यामुळे पुन्हा आलेल्या तासात असलेल्या jobs दुसऱ्यांदा चालवल्या जात नाहीत. हे वर्तन योग्य आहे; तरीही 03:00 वाजता त्याचा विचार करण्याची गरज नसावी. UTC अंतर्गत job वर्षातील प्रत्येक दिवशी एकदाच चालते. तुमची एखादी job चुकीच्या वेळी चालण्याऐवजी पूर्णपणे गहाळ होत असेल, तर cron job शांतपणे कधीही का चालत नाही याची कारणे हे अधिक संभाव्य स्पष्टीकरण आहे.

हाच मुद्दा logs वाचतानाही लागू होतो. journalctl system time zone मधील timestamps चे स्वरूपन करते आणि journalctl --utc UTC सक्तीने वापरते. दोन वेगवेगळ्या वेळ क्षेत्रांतील सर्व्हर असल्यास प्रत्येक incident चे रूपांतर करण्याचे काम होते; आणि दबावाखाली केलेल्या रूपांतरणांमुळे timeline चा चुकीचा अर्थ लावला जातो. Systems UTC वर ठेवा, timestamps UTC मध्ये साठवा आणि एखादा मनुष्य ते वाचत असताना एकदाच रूपांतर करा. एखाद्याला एका command साठी स्थानिक वेळ हवी असल्यास मशीनचा वेळ बदलण्याची गरज नाही:

TZ=Europe/Berlin date

timedatectl च्या output मधील आणखी एक line या section शी संबंधित आहे. RTC in local TZ चे मूल्य no असावे. Laptop वर Windows सोबत dual-boot करण्यासाठी ते yes वर सेट करणे हा workaround आहे. मात्र server वर त्यामुळे नंतर कोणीतरी अडचणीत येईल असा अतिरिक्त offset निर्माण होतो. ते सेट असल्यास timedatectl system ला RTC time स्थानिक time zone मध्ये वाचण्यासाठी configure केले आहे, असा warning print करते.

लक्षणांनुसार समस्या निवारण

एका सर्व्हरवर तुमचा two-factor code नाकारला जातो. इतर काहीही तपासण्यापूर्वी घड्याळ तपासा. हा code दर 30 seconds ने पुढे जाणाऱ्या counter मधून तयार होतो. त्यामुळे 90 seconds मागे असलेला सर्व्हर तुमच्या फोनने आधीच पार केलेल्या step मधील code तयार करतो. timedatectl मध्ये System clock synchronized: no दिसेल किंवा chronyc tracking मोठा System time offset दाखवेल. ही समस्या key थेट नाकारली जाण्यापेक्षा वेगळी आहे. key नाकारल्यास स्वतंत्र message दिसतो. त्यासाठी publickey authentication failures साठीच्या मार्गदर्शकात माहिती दिली आहे.

apt update मध्ये Release file अद्याप valid नसल्याचे सांगितले जाते. पूर्ण message मध्ये repository आणि ते किती वेळ invalid राहील हे दिलेले असते. उदाहरणार्थ, is not valid yet (invalid for another 1d 2h 3min 4s). तुमचे घड्याळ repository च्या Release file मधील तारखेपेक्षा मागे आहे. दिलेला कालावधी हा घड्याळ किती मागे आहे याचे थेट मोजमाप आहे. घड्याळ दुरुस्त करा. ही समस्या टाळण्यासाठी apt चे date check disable करू नका. हे check stale package index पुरवण्यापासून संरक्षण करते.

प्रत्येक source line मध्ये unreachable state दिसते आणि Reach 0 आहे. कोणताही प्रतिसाद मिळत नाही. त्यामुळे तुमच्या configuration ऐवजी egress तपासा. NTP outbound UDP port 123 वापरते. काही network त्याला filter किंवा redirect करतात. sudo chronyc ntpdata मध्ये Total TX आणि Total RX यांसह प्रत्येक source चे counters दाखवले जातात. RX शून्य असताना TX count वाढत असेल, तर तुमची packets बाहेर जात आहेत पण कोणतेही packets परत येत नाहीत. यावरून तुमच्या आणि source च्या मध्ये firewall असल्याची शक्यता दिसते.

घड्याळ बरोबर होते, नंतर अचानक बदलले. Host वरील घटनांमुळे असे होऊ शकते. Restored snapshot, paused guest किंवा दुसऱ्या host वर केलेले live migration यांमुळे guest चा वेळ वास्तविक वेळेपेक्षा मागे राहू शकतो. पुढील poll वेळी chrony हे ओळखून वेळ दुरुस्त करते. systemd-timesyncd मात्र आधी दीर्घ poll interval पूर्ण होण्याची वाट पाहू शकते. systemctl is-enabled chrony वापरून daemon boot वेळी सुरू होतो का ते तपासा. हाताने सुरू केलेला daemon पुढील reboot नंतर चालू राहणार नाही.

Offset लहान आहे, पण कधीही स्थिर होत नाही. CPU steal तपासा. Timer interrupt येण्याच्या वेळी guest ला schedule न मिळाल्यास त्याचे samples उशिरा घेतले जातात. त्यामुळे offset स्थिर होण्याऐवजी बदलत राहतो. top CPU line वर हे st figure म्हणून दाखवते. Shared host वरील CPU steal time वाचणे या मार्गदर्शकात या number चा अर्थ आणि त्यावर करता येणाऱ्या उपायांची माहिती दिली आहे.

आत्ताच issue केलेले certificate not yet valid म्हणून नाकारले जाते. curl मध्ये SSL certificate problem: certificate is not yet valid दाखवले जाते आणि browsers मध्येही तत्सम message दिसतो. Certificate मध्ये समस्या नाही. ते तपासणाऱ्या machine चे घड्याळ मागे आहे. चुकीचे घड्याळ client किंवा server पैकी कोणत्याही machine वर असू शकते, त्यामुळे दोन्ही तपासा. Certificate issue करणाऱ्या server चे घड्याळ चुकीचे असल्यास, त्याच setup मधील renewal प्रक्रियेसाठी certbot आणि nginx certificate मार्गदर्शक पहा.

तुम्ही आधीच करत असलेल्या तपासण्यांमध्ये हे समाविष्ट करा

वेळ समक्रमण ही boot-time setting आहे. ती काही महिन्यांनंतर कोणतीही त्रुटी न दाखवता अयशस्वी होऊ शकते. अशा गोष्टी नियमित तपासणीमुळे लक्षात येतात; केवळ स्मरणशक्तीवर त्या अवलंबून राहत नाहीत. timedatectl आणि chronyc tracking एकत्र वाचण्यासाठी दोन सेकंद पुरेसे आहेत. नवीन VPS वर पहिल्या दहा मिनिटांमध्ये या तपासण्या करा. तसेच नियमित Linux server maintenance checklist वापरताना त्या पुन्हा करा. offset वाढल्यावर तपासणीने स्वतः चालून सूचना द्यावी असे असल्यास, systemd service आणि timer लिहिणे ठरावीक वेळापत्रकानुसार अहवाल देणाऱ्या छोट्या unit साठी ही पद्धत स्पष्ट करते.

FAQ

माझ्या VPS चे घड्याळ समक्रमित आहे की नाही हे कसे तपासू?

`timedatectl चालवा आणि System clock synchronized ओळ वाचा. हा kernel चा स्वतःचा flag आहे. घड्याळाचे शिस्तबद्ध समक्रमण करणाऱ्या daemon ने तो सेट केलेला असतो. त्यामुळे chrony असलेल्या मशीनवर yes सोबत NTP service: n/a दिसणे सामान्य आणि योग्य आहे. त्रुटीचे प्रमाण पाहण्यासाठी chronyc tracking चालवा आणि System time वाचा. systemd-timesyncd समक्रमणाची जबाबदारी घेत असेल, तर timedatectl timesync-status चालवा आणि Offset वाचा. मशीनच्या बाहेरील स्रोताशी तुलना करायची असल्यास, date -u ची तुलना कोणत्याही HTTPS साइटने परत केलेल्या Date` header शी करा.

VPS वर chrony वापरावे की systemd-timesyncd?

महत्त्वाच्या कोणत्याही मशीनवर chrony वापरा. systemd-timesyncd हा एका server चे अनुसरण करणारा SNTP client आहे. मशीन सतत online राहत असेल आणि सुरुवातीपासून तिची वेळ जवळपास अचूक असेल, तर तो पुरेसा आहे. chrony अनेक sources चे polling करतो, परस्पर विसंगत sources नाकारतो, तुमच्या घड्याळातील rate error शिकतो आणि host pause किंवा live migration नंतर जलदपणे समक्रमित होतो. Debian किंवा Ubuntu वर chrony install केल्यावर systemd-timesyncd आपोआप काढला जातो, कारण दोन्ही packages `time-daemon` पुरवतात. एकाच वेळी दोन time daemons कधीही चालवू नका.

माझे TOTP codes एका server वर अपयशी ठरतात, पण इतरत्र का चालतात?

कारण TOTP code हा सध्याच्या वेळेवर आधारित function असतो. हा code प्रत्येक 30 seconds ने पुढे जाणाऱ्या counter मधून तयार होतो. त्यामुळे कोणता step सध्या लागू आहे याबाबत server आणि तुमचा phone यांच्यात एकमत असणे आवश्यक आहे. बहुतेक verifiers दोन्ही बाजूंना एक step स्वीकारतात. त्यामुळे प्रत्येक दिशेला साधारण अर्ध्या मिनिटाची मुभा मिळते. त्या server वर `timedatectl तपासा. System clock synchronized मध्ये no` दिसत असल्यास sync दुरुस्त करा. shared secret मध्ये कोणताही बदल न करता codes पुन्हा जुळतील.

Docker container मध्ये वेळ सेट करू शकतो का?

नाही, आणि त्याची गरजही नाही. Container host चे `CLOCK_REALTIME share करतो, कारण Linux time namespaces केवळ monotonic आणि boot-time clocks चे virtualisation करतात. Unprivileged container ला date: cannot set date: Operation not permitted मिळतो. CAP_SYS_TIME जोडल्यास container ला स्वतःचे घड्याळ मिळत नाही; त्याऐवजी तो host चे घड्याळ बदलू शकतो. त्यामुळे host चेच समक्रमण करा. Container मधील वेगळी local time ही time zone setting असते. त्यामुळे container environment मध्ये TZ` सेट करा.

Server ने UTC वापरावे की local time?

UTC वापरा आणि एखादी व्यक्ती output वाचते त्या वेळी local time लागू करा. Daylight saving मुळे UTC कधीही बदलत नाही. त्यामुळे daily job संपूर्ण वर्षभर दररोज एकदाच चालतो आणि वेगवेगळ्या servers वरील timestamps कोणत्याही conversion शिवाय एकमेकांशी जुळतात. `sudo timedatectl set-timezone UTC वापरून ते सेट करा. Local reading हवी असल्यास कोणत्याही व्यक्तीला एका command च्या सुरुवातीला prefix लावता येतो, उदाहरणार्थ TZ=America/New_York date`. यामुळे system clock मध्ये कोणताही बदल होत नाही.