VPS चे घड्याळ drift का होते? वेळ sync कशी करावी

तुमच्या VPS चे घड्याळ का drift होते

तुमच्या VPS चे घड्याळ drift होते, कारण ते दुरुस्त करणारी कोणतीही प्रक्रिया चालू नसते. Kernel वेळ मोजण्यासाठी hardware counter वापरतो. हा counter थोडा जलद किंवा थोडा मंद चालू शकतो. Time sync client चालू नसल्यास ही लहानशी चूक प्रत्येक तासागणिक वाढत जाते. Virtual machine मध्ये याचे आणखी एक कारण असते. तुमचा guest physical CPU इतर guests सोबत share करतो. त्यामुळे guest 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) द्वि-घटक कोड जुळत नाहीत. त्यामुळे 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 अशा counter वरून मोजला जातो, जो प्रत्येक 30 सेकंदांनी पुढे सरकतो. बहुतेक verifiers एक step आधी किंवा नंतरचा code स्वीकारतात. प्रत्येक दिशेतील अर्ध्या मिनिटाची चूक ही संपूर्ण उपलब्ध मर्यादा आहे. Kerberos अधिक tolerance ठेवतो. त्याची default skew allowance 300 सेकंद आहे. Certificate मात्र कोणतीही tolerance ठेवत नाही. ते निश्चित वेळांशी तपासले जाते आणि grace period 0 सेकंदांचा असतो. त्यामुळे घड्याळ एक सेकंद मागे असल्यास पूर्णपणे वैध certificate नाकारले जाते.

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

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

hardware clock, ज्याला RTC (real time clock) असेही म्हणतात, हा स्वतंत्र counter आहे. मशीन बंद असतानाही तो चालू राहतो. Physical machine मध्ये तो battery-backed chip असतो. Guest मध्ये hypervisor त्याचे emulation करतो, त्यामुळे तो मुख्यतः host शी संबंधित असतो. Linux boot वेळी सुरुवातीची value मिळवण्यासाठी तो एकदा वाचतो आणि त्यानंतर स्वतःची मोजणी सुरू ठेवतो. timedatectl ती value 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 म्हणजे या reads मधील कालावधी kernel ज्याच्या आधारे मोजते तो source. तुमच्या kernel ने कोणता source निवडला आहे ते पाहण्यासाठी:

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 दाखवतात आणि Hyper-V guests hyperv source दाखवतात. ही setting बदलण्याचे मोजलेले कारण नसल्यास ती तशीच ठेवा, कारण त्या hardware वर kernel आधीच त्याला विश्वासार्ह वाटणारा सर्वोत्तम 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 ते उपलब्ध करून देत नाही आणि network NTP हाच पर्याय आहे. clock_name ने KVM virtual clock दाखवले, तर chrony ते आपल्या config मधील refclock PHC /dev/ptp0 poll 2 line द्वारे वापरू शकते.

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

एका command ने सुरुवात करा. “ही घड्याळाची अचूकता राखणारे काही चालू आहे का?” या प्रश्नाचे उत्तर एका स्क्रीनवर मिळते.

timedatectl

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

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

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

chronyc tracking
chronyc sources -v

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

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

systemd-timesyncd वेळेचे synchronization करत असल्यास:

timedatectl timesync-status
timedatectl show-timesync --all

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

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

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

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

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

Ubuntu आणि Debian मध्ये systemd-timesyncd पूर्वनिर्धारितपणे उपलब्ध असते. हे SNTP (simple network time protocol) client आहे. ते एका वेळी एका server ला query करते आणि त्यानुसार clock हळूहळू समायोजित करते. सतत online असलेल्या आणि सुरुवातीला साधारणपणे अचूक वेळ असलेल्या machine साठी हे पुरेसे आहे. ते चालवण्यासाठी जवळजवळ कोणताही अतिरिक्त खर्च येत नाही.

chrony ही पूर्ण NTP implementation आहे. Virtual machine साठी ती अधिक चांगली default निवड आहे. तिच्या स्वतःच्या output मधून याची कारणे दिसतात. ती एकाच वेळी अनेक sources चे polling करते आणि परस्पर विसंगत sources वगळते. ती तुमच्या clock मधील rate error मोजते आणि तो drift file मध्ये लिहिते. त्यामुळे प्रत्येक sample च्या मागे धावण्याऐवजी clock ची प्रवृत्ती दुरुस्त केली जाते. Physical box च्या तुलनेत VM मध्ये घडणाऱ्या दोन गोष्टींमधूनही chrony जलदपणे सावरते: 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 चालू असताना त्याचे output वाचा. Debian आणि Ubuntu मध्ये chrony आणि systemd-timesyncd या दोन्ही packages कडून time-daemon उपलब्ध केले जाते. त्यामुळे chrony install करताना apt timesyncd काढून टाकते. हे योग्य आणि अपेक्षित आहे. दोन्ही एकाच वेळी कधीही चालवू नका. कारण एकाच clock वर वेळ सेट करणारे दोन daemons परस्परविरोधी काम करतील. ते चालू असताना कोणत्याही daemon ने दाखवलेल्या offset वर विश्वास ठेवता येत नाही. Rocky आणि AlmaLinux वर sudo dnf install -y chrony वापरून install करा. तेथे unit चे नाव chronyd आहे, chrony नाही.

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

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

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

server time.cloudflare.com iburst nts

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

sudo systemctl restart chrony
chronyc sources -v
chronyc tracking

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

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

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

sudo chronyc makestep
chronyc tracking

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

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

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

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

कंटेनरमध्ये वेगळा time zone असणे ही clock ची समस्या नाही. स्वतःचे /etc/localtime असलेली image त्याच क्षणाचे दुसऱ्या 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 पाळणाऱ्या time zone मध्ये 02:30 वाजताची daily job घड्याळ मागे केले जाते त्या दिवशी दोनदा चालते आणि घड्याळ पुढे केले जाते त्या दिवशी अजिबात चालत नाही. man 8 cron तीन तासांपेक्षा कमी shifts साठी विशेष हाताळणीचे वर्णन करते: forward jump मुळे skip झालेल्या jobs बदलानंतर लवकरच चालवल्या जातात आणि backward jump मुळे repeated hour मध्ये आलेल्या jobs दुसऱ्यांदा चालवल्या जात नाहीत. हे वर्तन योग्य आहे, पण 03:00 वाजता त्याचा विचार करावा लागू नये. UTC अंतर्गत job वर्षातील प्रत्येक दिवशी, दिवसातून एकदा चालते. एखादी job विचित्र वेळी चालण्याऐवजी पूर्णपणे missing असेल, तर cron job शांतपणे कधीच का चालत नाही याची कारणे हे अधिक संभाव्य स्पष्टीकरण आहे.

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

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 local 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 पूर्णपणे नाकारला जाण्यापेक्षा वेगळा failure आहे. अशा वेळी स्वतंत्र 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 आहे. कोणताही प्रतिसाद मिळत नाही. त्यामुळे config ऐवजी egress तपासा. NTP साठी outbound UDP port 123 वापरला जातो. काही networks हे traffic filter किंवा redirect करतात. sudo chronyc ntpdata मध्ये Total TX आणि Total RX यांसह प्रत्येक source चे counters दिसतात. RX शून्य असताना TX count वाढत असल्यास, तुमची packets बाहेर जात आहेत पण कोणताही प्रतिसाद परत येत नाही. यावरून तुमच्या आणि source मधील firewall कडे निर्देश होतो.

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

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

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

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

वेळेचे समक्रमण ही boot-time सेटिंग आहे. ती काही महिन्यांनंतर कोणतीही त्रुटी न दाखवता अपयशी ठरू शकते. नेमकी अशाच गोष्टी नियमित तपासणीत सापडतात; त्या लक्षात राहतीलच असे नाही. timedatectl आणि chronyc tracking एकत्र वाचण्यासाठी दोन सेकंद पुरेसे आहेत. नवीन VPS वर पहिल्या दहा मिनिटांत या तपासण्या करा. तसेच नियमित Linux server maintenance checklist तपासताना त्या पुन्हा करा. Offset वाढल्यावर तपासणीने स्वतःच सूचना द्यावी असे वाटत असल्यास, systemd service आणि timer लिहिणे या पद्धतीत schedule नुसार अहवाल देणाऱ्या छोट्या unit चे उदाहरण दिले आहे. अशा प्रकारची तपासणी daemon ऐवजी छोटी script असते. त्यामुळे default ऐवजी तिला Type=oneshot आवश्यक असते. systemd service types चे स्पष्टीकरण चुकीचा प्रकार वापरल्यास unit ने प्रत्यक्षात मिळवलेली नसलेली success का दाखवते, हे स्पष्ट करते.

FAQ

VPS घड्याळ समकालित आहे का हे कसे तपासावे?

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

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

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

एका सर्व्हरवर माझे TOTP codes fail होतात, पण इतरत्र योग्य का चालतात?

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

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

नाही, आणि त्याची गरजही नाही. Container host चे `CLOCK_REALTIME share करतो, कारण Linux time namespaces फक्त monotonic आणि boot-time clocks virtualise करतात. Unprivileged container ला date: cannot set date: Operation not permitted मिळते. CAP_SYS_TIME जोडल्यास container ला स्वतःचे clock मिळत नाही; उलट तो host चे clock बदलू शकतो. त्यामुळे host चे synchronization करा. 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 हवी असल्यास एखाद्या single command च्या आधी prefix द्या, उदाहरणार्थ TZ=America/New_York date`. यामुळे system clock मध्ये कोणताही बदल होत नाही.