एनटीपी दूरस्थ सर्वर के बजाय LOCAL से क्यों तालमेल बैठा रहा है?

Question

इसलिए, मैं अपने वर्तमान NTP सेटअप को डीबग करने का प्रयास कर रहा हूं, और पाया कि वह मेरे एकल कॉन्फ़िगर सर्वर से ऑफसेट 3 सेकंड से अधिक है, और समायोजन नहीं कर रहा है। Ntpq आउटपुट में LOCAL (0) पर तारांकन संकेत करता है कि सिस्टम 10.130.33.201 सर्वर (जो हमारे सिस्टम पर एक और लिनक्स बॉक्स है जिसे हम सब कुछ सिंक करना चाहते हैं) के बजाय ख़ुशी से सिंक कर रहा है।

ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 10.130.33.201   LOCAL(0)         9 u   49   64  377    0.242  -3742.2   1.049
*LOCAL(0)        .LOCL.          10 l    2   64  377    0.000    0.000   0.001

और यह मेरी ntp.conf फाइल है। किसी और ने लिखा है, इसलिए मुझे 100% यकीन नहीं है कि सब कुछ सही है।

server 10.130.33.201 burst iburst minpoll 4 maxpoll 11
driftfile /mnt/active/etc/ntp.drift

restrict -4 default  nomodify nopeer notrap
restrict -6 default  ignore

# Undisciplined Local Clock. This is a fake driver intended for backup
# and when no outside source of synchronized time is available.
server  127.127.1.0     # local clock
fudge   127.127.1.0 stratum 10

मैंने फट और iburst और minpoll / maxpoll के बारे में पढ़ा है, इसलिए मुझे एहसास है कि उन लोगों की आवश्यकता नहीं हो सकती है, लेकिन मुझे नहीं लगता कि मेरे मौजूदा मुद्दे से कोई लेना-देना है।

इसके अलावा, यह कैसे तैनात किया जाता है, उस कॉन्फ़िगरेशन फ़ाइल को बदलने में बहुत काम लगेगा, इसलिए मुझे उम्मीद है कि ऐसा कुछ भी नहीं है जो वास्तव में बदलना चाहिए। मुझे उम्मीद है कि यह मेरे लिए समझ में नहीं आ रहा है कि एनटीपी कैसे काम करता है।

---

EDIT -

तो, ऐसा लगता है कि यह इस प्रश्न का एक डुप्लिकेट है , लेकिन मुझे नहीं लगता कि पोस्टर को पर्याप्त उत्तर मिला, इसलिए मैं अभी भी जानना चाहूंगा कि स्थानीय समय को सर्वर पर क्यों पसंद किया जा रहा है। इसके अलावा, नीचे दिए गए उत्तरों में से एक के अनुसार, मैंने कॉन्फिगरेशन को preferसर्वर लाइन पर कॉन्फिगर करने और रीस्टार्ट करने की कोशिश की, लेकिन इसका कोई असर नहीं हुआ।

यदि मैं कॉन्फ़िगर में सभी "स्थानीय" लाइनों को हटाता हूं, जैसा कि अन्य प्रश्न का उत्तर है, तो सर्वर अनुपलब्ध होने पर क्या होगा? क्या NTP मरता है या बस कोशिश करता रहता है?

---

महत्वपूर्ण संस्करण -

ठीक है, सामान्य रूप से, 10.130.33.201 ("सर्वर") के पास इंटरनेट तक पहुंच नहीं है, और उपयोग करने के लिए जीपीएस समय स्रोत नहीं है। महत्वपूर्ण हिस्सा यह है कि सिस्टम के सभी उपकरणों में सर्वर के समान समय होता है, भले ही वह समय वास्तव में कितना सही हो।

इसलिए, यह देखने के लिए कि क्या होगा, मैंने NTP फाइल सर्वर में से एक को सर्वर की कॉन्फिग फाइल में जोड़ा, ताकि उसे लोकल से समय मिलने के बजाय वहां से समय मिले। यह अब सही ढंग से NTP समय सर्वर से समय मिलता है।

मैंने ऐसा करने के बाद, ग्राहकों को अब LOCAL (0) पसंद करने के बजाय सर्वर के साथ सिंक किया

 ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*10.130.33.201   38.229.71.1      3 u   58   64  377    0.216  715621.   1.001
 LOCAL(0)        .LOCL.          10 l   18   64  377    0.000    0.000   0.001

नया प्रश्न - जब मेरा सर्वर स्थानीय (मूल उदाहरण जो दिया गया था) का उपयोग कर रहा है, तो ऐसा लगता है कि ग्राहक कह रहे हैं, "ओह, 10.130.33.201 LOCAL (0) का उपयोग कर रहा है। हम्म, मेरे पास एक LOCAL (0) सर्वर भी है। - मैं 10.130.33.201 के माध्यम से समान जानकारी प्राप्त करने के बजाय सीधे इसका उपयोग करूंगा। "

क्या यह मामला है? क्या वे "स्रोत पर सीधे" जाने की कोशिश कर रहे हैं जो गलत तरीके से LOCAL (0) है? मुझे अपने सर्वर को LOCAL (0) से समय प्राप्त करने की आवश्यकता है, और मुझे सर्वर से समय प्राप्त करने के लिए क्लाइंट की आवश्यकता है। अभी क्लाइंट कॉन्फिग फाइल से "लोकल" सर्वर को हटाना एकमात्र विकल्प है, लेकिन मैं यह समझना चाहूंगा कि ऐसा क्यों हो रहा है, और यदि संभव हो तो, उनके कॉन्फिग को बदलने से बचें (कॉन्फिग चेंज बहुत काम का होगा क्योंकि हमारा पर्यावरण...)।

इसके अलावा, यह एक अच्छा जवाब के बिना एक और डुप्लिकेट की तरह दिखता है।

Comments

साथ ही, यदि आपके पास 10.130.33.201 तक हमेशा ऑन-नेटवर्क नेटवर्क है, तो स्थानीय घड़ी स्रोत को हटाने पर विचार करें।

— हारून कोपले

Answer 1

केवल एक एनटीपी सर्वर को कॉन्फ़िगर करने के साथ, एल्गोरिथ्म पूरी तरह से निश्चित नहीं है कि किस पर भरोसा करना है। हालांकि, दूरस्थ मेजबान के साथ स्ट्रेटम कम है, मुझे यकीन है कि एल्गोरिथ्म को लगता है कि स्थानीय समय अधिक भरोसेमंद है।

preferअपने serverकथन के साथ कीवर्ड का उपयोग करने का प्रयास करें जो कि अधिमान्य समय स्रोत के रूप में सेट हो।

---

EDIT -

तो, ऐसा लगता है कि यह इस प्रश्न का एक डुप्लिकेट है, लेकिन मुझे नहीं लगता कि पोस्टर को पर्याप्त उत्तर मिला, इसलिए मैं अभी भी जानना चाहूंगा कि स्थानीय समय को सर्वर पर क्यों पसंद किया जा रहा है।

वास्तव में पर्याप्त उत्तर के लिए, आप एक बहुत ही जटिल एल्गोरिथ्म के आंत्र में खुदाई करने जा रहे हैं। प्रलेखन भी विशिष्ट नहीं है, लेकिन मुझे यकीन है कि वहाँ एक श्वेत पत्र या विनिर्देश है।

यदि मैं कॉन्फ़िगर में सभी "स्थानीय" लाइनों को हटाता हूं, जैसा कि अन्य प्रश्न का उत्तर है, तो सर्वर अनुपलब्ध होने पर क्या होगा? क्या NTP मरता है या बस कोशिश करता रहता है?

NTP डेमॉन मरता है या नहीं रुकता है, लेकिन दूरस्थ सर्वर तक पहुंचने में विफल होने के बाद यह सिंक्रनाइज़ेशन समय नहीं छोड़ता है। यही कारण है कि सर्वोत्तम अभ्यास न्यूनतम तीन दूरस्थ सर्वरों का सुझाव देंगे और एलसीएल का उपयोग नहीं करने के लिए जब तक कि आप नेटवर्क से डिस्कनेक्ट नहीं हो जाते। तीन सर्वरों का सुझाव दिया जाता है क्योंकि जब केवल दो होते हैं, और वे असहमत होते हैं, तो वह किसे चुनेगा? तीसरे सर्वर को एल्गोरिथ्म को फर्जी सर्वर को खत्म करने में मदद करनी चाहिए।

अन्त में, मैंने अभी देखा कि आप परिभाषित नहीं करते हैं driftfile। यह मदद कर सकता है?

Comments

क्या दो स्ट्रेट्स (ओम्स?) के बीच अंतर करना इस पर प्रभाव डालता है? सर्वर से कम 9 की मदद होगी?

— जेपी १६१

ये हो सकता है। जाहिर है, मैं एल्गोरिथ्म के खुद के बारे में पूरी जानकारी नहीं है। हालांकि, एकमात्र मामला जहां आपको स्ट्रैटम को ठगना चाहिए, वह स्थानीय घड़ी के साथ है। मैं यह अनुशंसा नहीं कर सकता कि आप एक दूरस्थ सर्वर को एक फिक्स के रूप में ठगें। NTP को न्यूनतम हस्तक्षेप के साथ सबसे अच्छा स्रोत निर्धारित करने के लिए भरोसा किया जाना चाहिए। आपके पास बस एक ऐसा मामला होना चाहिए जहां आपको इसे थोड़ा धक्का देने की जरूरत है।

— हारून कोपले

सुझाव के लिए धन्यवाद। एक बहाव था, लेकिन यह नहीं बनाया जा रहा था इसलिए मैंने यह देखने के लिए हटा दिया कि क्या होगा। स्थानीय लाइन को हटाने से यह सर्वर के साथ सिंक हो जाता है, इसलिए यह कुछ है। आप कहते हैं कि ntpd "दूरस्थ सर्वर तक पहुंचने में विफल रहने के बाद सिंक्रनाइज़ेशन समय छोड़ देगा", लेकिन क्या सर्वर के पहुंचने के बाद यह फिर से शुरू हो जाएगा? मैं केवल एक अस्थायी नेटवर्क व्यवधान के मामले में सुरक्षित रहना चाहता हूं।

— जेपी १६१

नहीं, यह फिर से शुरू नहीं होगा। यह बस देता है। यह कष्टप्रद है और मेरे लिए एक पकड़ -22 भी है। हम जानते हैं कि यदि नेटवर्क कनेक्टिविटी खो गई है तो NTP को पुनः आरंभ करें। आपके बहाव की संभावना नहीं बन रही है क्योंकि ntp के पास पथ की अनुमति नहीं है। उसको दोबारा जांचें।

— हारून कोपले

Answer 2

यह मुझे ऑफसेट के अंतराल की तरह दिखता है (आपके सिस्टम के समय और NTP होस्ट के बीच का अंतर) NTP को ठीक से सेट करने के लिए बहुत अलग है।

मेरा सुझाव,

 1. Stop the NTP service
 2. As root ntpdate -bs 10.130.33.201 to reset your time to something close
 3. Start the NTP service

उसके बाद आपको कोई समस्या नहीं होनी चाहिए।

Comments

यदि मशीन एक वीएम होती है या कुछ अन्य स्थिति है जो इसे गंभीरता से टूटे हुए समय के साथ आने का कारण बनती है तो आप एनटीपी tinker panic 0विकल्प को एनटीपी को किसी भी ऑफसेट को स्वीकार करने के लिए मजबूर करने के लिए सेट कर सकते हैं । लेकिन केवल एनटीपी सर्वर के साथ इसका उपयोग करें आप निश्चित हैं कि खराब समय कभी नहीं लौटेगा।

— 18 नवंबर को Zoredache

ठीक है, मुझे लगता है कि इससे पहले कि यह एक समस्या थी और इसे अधिक बंद करना पड़ा, और फिर मैंने सोचा कि सर्वर को # चिह्न के साथ सूचीबद्ध किया जाएगा? क्या यह मामला नहीं है? सेकंड या मिलीसेकंड में "ऑफसेट" है?

— जेपी १६१

यह अभी 10.130.33.201 को सिंक नहीं होगा क्योंकि ऑफसेट बहुत अधिक है, लेकिन यह इस तथ्य को ठीक नहीं करेगा कि यह पहली जगह में पर्याप्त बह रहा है कि LCL अधिक वांछनीय हो रहा है। मुझे लगता है कि यह एक काम करने वाला बहाव है, और preferयह काम करेगा।

— हारून कोपले

क्या आप बता सकते हैं कि ऑफसेट बहुत अधिक क्यों है? यह किसी भी तरह से कम से कम है) और कोई # चिह्न नहीं है। इसके अलावा, मैंने दोनों प्रणालियों पर वास्तविक समय को सत्यापित किया है, और वे लगभग 4 सेकंड अलग हैं।

— जेपी १६१

+/- 1000 एमएस ... नहीं +/- 1000 एस । -3742 एमएस पर है ।

— आरोन कोपले

Answer 3

LOCAL सर्वर के रूप में 10.130.33.201 का स्ट्रैटम 9 है, जो स्थानीय स्ट्रेटम की गणना इस से करता है (9 + 1 = 10) स्ट्रैटम पर स्थानीय LOCAL सर्वर के साथ प्रतिस्पर्धा करता है। 10. चूंकि स्थानीय LOCAL स्ट्रैटम में कोई नेटवर्क देरी या घबराहट नहीं है, इसलिए यह रिमोट की तुलना में ntpd को थोड़ा बेहतर लग सकता है।

अगर आप चाहते हैं कि यह कॉन्फिगर काम करे, तो 'मास्टर' LOCAL सर्वर को स्ट्रैटम से कम 9 पर सेट करें। यदि आप स्ट्रैटम 1 सर्वर को पसंद करने के लिए समय ट्रेस करने योग्य चाहते हैं तो बहुत कम नहीं है।

Comments

धन्यवाद। मैं जितनी जल्दी हो सके इस बात की जांच करूंगा। उम्मीद तो दिखती है।

— जेपी १६१

ठीक है, ऐसा लगता है कि मैंने पहले 10.130.33.201 LOCAL सर्वर के स्ट्रैटम को कम करने की कोशिश की थी। वर्तमान में, यह 5 पर सेट है, ग्राहक इसे 6 के रूप में देखता है, लेकिन फिर भी इसे पसंद करता है जो LOCAL है, जिसमें 10. का स्ट्रैटम है। यह कॉन्फ़िगरेशन दिनों के लिए किया गया है।

— जेपी १६१

Answer 4

मुझे पता है कि यह पुराना है, लेकिन मुझे लगता है कि आप सही हैं। कोई भी ntpd मुद्दों को डीबग करने का कोई तरीका नहीं दिखाता है। यह उल्लेखनीय है।

मुझे लगता है कि आप सही रास्ते पर थे जब आपको संदेह था कि स्थानीय और अपस्ट्रीम सर्वर पर LOCAL (0) का उपयोग एक मुद्दा हो सकता है।

यह निश्चित रूप से 4 सर्वरों के एक समय के द्वीप पर था, जिनके साथ मेरा समान मुद्दा था। ये सभी एक-दूसरे के सहयोगी होने के लिए तैयार थे, इसलिए संभवतः यह एक अलग मुद्दा है।

सबसे पहले, अनाथ मोड नामक समय द्वीपों को संभालने का एक बेहतर तरीका है जो कि पिछले कुछ समय के ntpd संस्करणों के साथ समर्थित है:

Doc.ntp.org पर अनाथ विधा

प्रारंभ में सभी 4 सर्वरों में 10 की समान गति थी और उनकी स्थानीय घड़ी को प्राथमिकता दी गई। मैंने तय किया कि और अभी भी वे अपनी स्थानीय घड़ी पसंद करते हैं (स्ट्रैटम हालांकि महत्वपूर्ण लगता है)।

मैंने ntpq कमांड पे (सहकर्मी) का उपयोग किया, जैसे कि क्या हो रहा था उस पर एक हैंडल पाने के लिए आर.वी. जानकारी को डंप करने के लिए आपको सर्वर के एसोसिएशन नंबर पर rv (readvar) का उपयोग करना होगा। पे और जैसा कि एक ही इंडेक्स द्वारा सॉर्ट किया जा रहा है ताकि आप उस तरह से संख्या प्राप्त कर सकें। जैसा कि एक फ़ील्ड है जिसे कंडीशन कहा जाता है जो सर्वर को पसंद नहीं करने पर मान अस्वीकार कर सकता है।

आरवी आउटपुट में एक क्षेत्र होता है जिसे फ्लैश कहा जाता है। यदि सब ठीक रहा तो यह शून्य हो जाएगा। यदि नहीं, तो यह मुद्दों का एक बिटमास्क (हेक्स में प्रदर्शित) है। उन्हें यहाँ देखा जा सकता है:

ntpd आंतरिक डीकोड

मुद्दा मैं 0800 peer_loop था। यह पता चला कि घड़ी का रिफिड महत्वपूर्ण है। स्थानीय घड़ी और दूरस्थ सर्वर से LOCAL (0) को देखकर यह सोचना था कि वहाँ एक लूप था। डेविड मिल्स ने पुष्टि की कि comp.protocols.time पर पोस्ट में 'एनटीपी में लूप से बचने के लिए' (मैं अपने 2 लिंक की सीमा तक पहुंच गया हूं, क्षमा करें!)

यूनीक रिफिड सेट करने के लिए ठगने के लिए रिफिड तर्क का उपयोग करने से काम नहीं हुआ - यह अभी भी प्राप्तकर्ता के रूप में LOCAL (0) के रूप में दिखता है।

जो काम करने के लिए लग रहा था वह स्थानीय चालक के लिए अद्वितीय उदाहरण संख्याओं का उपयोग कर रहा था। 127.127.1। [0-3]। सर्वर और ठग लाइन दोनों पर एक ही आईडी का उपयोग करें। जब मैंने ऐसा किया, तो सर्वर आम तौर पर सबसे कम स्ट्रेटम सर्वर के लिए सिंक होता था, जो आमतौर पर इसकी स्थानीय घड़ी का उपयोग करता था। हालाँकि यह कभी-कभी किसी अन्य सर्वर का उपयोग करने की कोशिश करता था जो इसे स्रोत के रूप में उपयोग कर रहा था। हालाँकि कई बार तालमेल बैठ गया और लगता है कि इस तरह से रहना है।

शायद मदद करने के लिए बहुत देर हो चुकी है, लेकिन मैं इसे प्रस्तुत करता हूं कि NTP यह तर्क और समस्या निवारण के लिए उत्तरदायी है। मुझे परीक्षण और त्रुटि से जवाब तक पहुंचने में घंटों लग गए और फिर बाद में डॉक्स मिले।

Answer 5

यदि कोई अनुरोध विफल रहता है, तो वांछित NTS को NTP अनुरोध भेजने के लिए सर्वर को बाध्य करने के लिए iburst का उपयोग करें

Comments

इसके लिए बेहतर स्पष्टीकरण की जरूरत है।

— स्वेन