अप्रत्याशित रूप से और समाधान के कारण NTPD के मरने के संभावित कारण

9

एक वेब एप्लिकेशन पर जो भौतिक दस्तावेज भंडारण के लिए s3 का उपयोग करता है, हम लगातार मरने वाले NTP के साथ समस्याओं का सामना कर रहे हैं। यह एक दिन में एक या दो बार मोटे तौर पर होता है। जब यह होता है तो बहुत कम जानकारी प्रदान की जाती है, इसके अलावा पीआईडी फ़ाइल मौजूद है लेकिन जब मैं स्थिति की जांच करता हूं तो सेवा मृत हो जाती है।

क्या कोई एनटीपीडी के मरने के संभावित कारणों का सुझाव दे सकता है? मैं मान रहा हूं कि शायद घड़ी के बहाव के कारण यह मर रहा है लेकिन मुझे यकीन नहीं है कि इसका कारण क्या होगा। पर्याप्त मेमोरी और उपलब्ध डिस्क स्थान से अधिक है।

पिछली बार सेवा की मृत्यु हो गई थी, यह आउटपुट था:

Sep  6 06:15:25 vm02 rsyslogd: [origin software="rsyslogd" swVersion="5.8.10" x-pid="988" x-info="http://www.rsyslog.com"] rsyslogd was HUPed
Sep  6 06:17:06 vm02 ntpd[10803]: 0.0.0.0 0618 08 no_sys_peer
Sep  6 08:01:10 vm02 ntpd[10803]: 0.0.0.0 0617 07 panic_stop -28101 s; set clock manually within 1000 s.

— user275940
स्रोत

कौन सा ओएस और संस्करण? क्या कोई हिड्स चल रहा है? कितने एनटीपी-सर्वर कॉन्फ़िगर किए गए हैं? एनटीपीडी विकल्प ऑकिटिव क्या हैं?

— नील

आप अपनी ntp.drift फ़ाइल को निकालने का प्रयास कर सकते हैं, यह मूल्य बहुत अधिक हो सकता है और तिरछा हो सकता है

— Rqomey

6

मैं कहूंगा कि सटीक कारण खोजने के लिए 1 मिनट की कोई विधि नहीं है।

हमारे ESXi वातावरण में पहले भी ऐसे ही मुद्दे थे। कहानी को छोटा करने के लिए, हमने पाया कि ESXi होस्ट की घड़ी बहुत अधिक बहाव वाली थी और अतिथि VMs ESXi होस्ट और अपस्ट्रीम NTP सर्वर दोनों से समय को सिंक कर रहे थे। इस वजह से वीएम पर एनटीपीडी उलझन में थी इसलिए उसकी अक्सर मौत हो जाती थी।

हमने कुछ दुर्लभ मामलों में भी पाया कि यादृच्छिक पैकेट हानि ने NTPD को भी छोड़ दिया क्योंकि आपके सर्वर और अपस्ट्रीम NTPd सर्वर के बीच के दौर की यात्रा का समय बहाव के समय की गणना करने के लिए उपयोग किया जाता है।

उपरोक्त दो मामलों में, यदि NTPd एक बड़े समय के बहाव को देखता है, उदाहरण के लिए अधिक से अधिक, यह डिफ़ॉल्ट रूप से क्विट करता है। -g ऑप्शन से थोड़ी मदद मिलेगी।

   -g      Normally,  ntpd  exits  with  a  message to the system log if the offset exceeds the panic threshold,
           which is 1000 s by default. This option allows the time to be set to any value  without  restriction;
           however,  this  can  happen only once. If the threshold is exceeded after that, ntpd will exit with a
           message to the system log. This option can be used with the -q and -x options. See the tinker command
           for other options.

आप सिस्टम लॉग पर एक नज़र डाल सकते हैं , जिसमें कुछ शब्द होने चाहिए जो आपको संकेत दे सकते हैं। आप "ntpq -p" आउटपुट की निगरानी भी कर सकते हैं कि एक मोटा विचार कैसे ऑफसेट विकसित होता है।

— एन्जो वांग
स्रोत

जब आप VMs पर ntpd चला रहे हैं, तो आपको होस्ट के साथ समय भी सिंक नहीं करना चाहिए, और आपको स्थानीय घड़ी को संदर्भ के रूप में शामिल नहीं करना चाहिए।

— पॉल गियर

3

लॉग संदेश स्पष्ट रूप से इंगित करता है कि घड़ी का बहाव निकास का कारण है। संभव समाधान:

Ntpd को -g ध्वज के साथ प्रारंभ करें; हालाँकि, यह मूल कारण को ठीक नहीं करेगा, जो घड़ी तिरछा है।
Ntpd शुरू करने से पहले ntpdate चलाएं; शायद वही कैविएट।
अधिक समय स्रोत जोड़ें; अच्छी सटीकता बनाए रखने के लिए NTP को 4-6 स्रोतों की आवश्यकता होती है। ऐसा करने का एक सरल तरीका अपने संदर्भ में बार-बार होने वाले संदर्भों को शामिल करना है [0-3] .YOURREGION.pool.ntp.org
```
server 0.au.pool.ntp.org iburst
server 1.au.pool.ntp.org iburst
server 2.au.pool.ntp.org iburst
server 3.au.pool.ntp.org iburst

server 0.au.pool.ntp.org iburst
server 1.au.pool.ntp.org iburst
server 2.au.pool.ntp.org iburst
server 3.au.pool.ntp.org iburst
```

— पॉल गियर
स्रोत

1

एक और विकल्प जो आप आज़मा सकते हैं, वह है क्रॉनी। हमारे परीक्षण में यह ntpd से अधिक महत्वपूर्ण रूप से प्रदर्शन करता है और आभासी वातावरण में अनुभव किए गए समय तिरछा को बेहतर तरीके से संभालता है।

http://chrony.tuxfamily.org/

— Jokajak
स्रोत