सवाल लिनक्स सर्वर की उच्च दर का अनुभव करने वाला कोई और व्यक्ति दूसरे छलांग के दौरान दुर्घटनाग्रस्त हो जाता है?


* नोट: यदि आपके सर्वर में अभी भी उलझन में कर्नेल के कारण समस्याएं हैं, और आप रीबूट नहीं कर सकते हैं - आपके सिस्टम पर स्थापित gnu date के साथ प्रस्तावित सबसे सरल समाधान है: अब दिनांक। यह कर्नेल के आंतरिक "time_was_set" चर को रीसेट करेगा और जावा और अन्य उपयोगकर्ता स्पेस टूल में CPU hogging futex loops को ठीक करेगा। मैंने इस आदेश को अपने सिस्टम पर दबा दिया है, यह पुष्टि की है कि यह टिन पर जो कहता है वह कर रहा है *

पोस्टमार्टम

Anticlimax: केवल एक चीज जो मर गया था क्लस्टर के लिए मेरा वीपीएन (openvpn) लिंक था, इसलिए फिर से स्थापित होने के दौरान एक रोमांचक कुछ सेकंड था। बाकी सब कुछ ठीक था, और दूसरे छलांग पारित होने के बाद एनटीपी शुरू हो गया।

मैंने दिन का पूरा अनुभव लिखा है http://blog.fastmail.fm/2012/07/03/a-story-of-leaping-seconds/

यदि आप मार्को के ब्लॉग को देखते हैं http://my.opera.com/marcomarongiu/blog/2012/06/01/an-humble-attempt-to-work-around-the-leap-second - 1 सेकंड छोड़ने से बचने के लिए एनटीपीडी-एक्स का उपयोग करके 24 घंटों में समय परिवर्तन को चरणबद्ध करने का उनका समाधान है। यह आपके स्वयं के एनटीपी बुनियादी ढांचे को चलाने के लिए एक वैकल्पिक स्मीयरिंग विधि है।


बस आज, 30 जून, 2012 - शनि जीएमटी की शुरुआत के तुरंत बाद शुरू हो रहा है। अलग-अलग टीमों द्वारा प्रबंधित विभिन्न डेटासेंटर में हमारे पास कुछ हद तक सर्वर हैं, सभी अंधेरे जाते हैं - पिंग्स का जवाब नहीं देते, स्क्रीन खाली होती है।

वे सभी डेबियन निचोड़ चल रहे हैं - स्टॉक कर्नेल से कस्टम 3.2.21 बनाता है। अधिकांश डेल एम 610 ब्लेड हैं, लेकिन मैंने अभी भी डेल आर 510 खो दिया है और अन्य विभागों ने अन्य विक्रेताओं से भी मशीनें खो दी हैं। एक पुराना आईबीएम x3550 भी था जो दुर्घटनाग्रस्त हो गया था और जिसे मैंने सोचा था कि असंबंधित हो सकता है, लेकिन अब मैं सोच रहा हूं।

एक क्रैश जो मैंने किया था, से स्क्रीन डंप मिला:

[3161000.864001] BUG: spinlock lockup on CPU#1, ntpd/3358
[3161000.864001]  lock: ffff88083fc0d740, .magic: dead4ead, .owner: imapd/24737, .owner_cpu: 0

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

बस जानना चाहते हैं कि यह एक आम धागा है या "बस हमें"। यह वास्तव में अजीब बात है कि वे अलग-अलग समय पर खरीदे गए विभिन्न डेटासेंटर में अलग-अलग इकाइयां हैं और विभिन्न व्यवस्थापक (मैं फास्टमेल.एफएम चलाता हूं) द्वारा चलाया जाता हूं ... और अब भी अलग विक्रेता हार्डवेयर। दुर्घटनाग्रस्त मशीनों में से अधिकांश सप्ताह / महीनों तक चल रही थीं और 3.1 या 3.2 श्रृंखला कर्नेल चल रही थीं।

सबसे हालिया दुर्घटना एक मशीन थी जो 3.2.21 चलने के लगभग 6 घंटे तक थी।

कामकाजी

ठीक है दोस्तों, यहां मैंने इसके आसपास कैसे काम किया है।

  1. अक्षम एनटीपी: /etc/init.d/ntp stop
  2. बनाया था http://linux.brong.fastmail.fm/2012-06-30/fixtime.pl (मार्को से चोरी कोड, टिप्पणियों में ब्लॉग पोस्ट देखें)
  3. भाग गया fixtime.pl एक तर्क के बिना कि एक छलांग दूसरा सेट था
  4. भाग गया fixtime.pl दूसरे छलांग को हटाने के लिए एक तर्क के साथ

नोट: पर निर्भर करता है adjtimex। मैंने निचोड़ की एक प्रति डाल दी है adjtimex बाइनरी पर http://linux.brong.fastmail.fm/2012-06-30/adjtimex - यह एक निचोड़ 64 बिट सिस्टम पर निर्भरता के बिना चलाएगा। यदि आप इसे उसी निर्देशिका में डालते हैं fixtime.pl, अगर सिस्टम एक मौजूद नहीं है तो इसका उपयोग किया जाएगा। जाहिर है अगर आपके पास 64-बिट निचोड़ नहीं है ... अपना खुद का पता लगाएं।

मैं शुरू करने जा रहा हूँ ntp फिर कल

एक अनाम उपयोगकर्ता के रूप में सुझाव दिया - चलाने के लिए एक विकल्प adjtimex केवल समय निर्धारित करने के लिए है, जो संभावित रूप से leapsecond काउंटर को भी स्पष्ट करेगा।


366
2018-06-30 16:15


मूल


आज 30 वें स्थान पर एक छलांग है। मुझे यह समझने में संकोच नहीं है कि यह आपकी समस्या है, लेकिन मैं अपनी डेबियन मशीनों को बारीकी से देखूंगा। - jscott
सुबह से हम विभिन्न विक्रेताओं से कम से कम 9 अलग-अलग डेबियन निचोड़ बक्से खो चुके हैं, सभी चल रहे स्टॉक 2.6.32 कर्नेल निचोड़ते हैं। कंसोल रिक्त करने के कारण हम क्रैश डंप नहीं कर पाए हैं ... - kargig
इस बारे में lkml पोस्टिंग lkml.indiana.edu/hypermail/linux/kernel/1203.1/04598.html - Daniel S. Sterling
इसकी रिपोर्ट करने के लिए धन्यवाद! अब मैं अपने सर्वर पर बहुत करीब से घूर रहा हूं। - Janne Pikkarainen
एलकेएमएल धागे ने संकेत दिया कि date -s "`date`" मदद करता है - यह निश्चित रूप से मेरी मदद की। - Pointy


जवाब:


यह एक livelock के कारण होता है जब ntpd कर्नेल को एक छलांग लगाने के लिए कर्नेल को बताने के लिए adjtimex (2) कहते हैं। एलकेएमएल पोस्टिंग देखें http://lkml.indiana.edu/hypermail/linux/kernel/1203.1/04598.html

Red Hat को भी उनके KB आलेख को अद्यतन करना चाहिए। https://access.redhat.com/knowledge/articles/15145

अद्यतन: इस समस्या के लिए रेड हैट का दूसरा KB आलेख यहां है: https://access.redhat.com/knowledge/solutions/154713 - पिछला लेख पहले, असंबंधित समस्या के लिए है

काम-आसपास बस एनटीपीडी बंद करना है। अगर ntpd पहले ही एडीटाइक्स (2) कॉल जारी करता है, तो आपको 100% सुरक्षित होने के लिए ntpd को अक्षम करने और रीबूट करने की आवश्यकता हो सकती है।

इससे आरएचईएल 6 और अन्य डिस्ट्रोज़ नए कर्नेल चल रहे हैं (लगभग 2.6.26 से नए), लेकिन आरएचईएल 5 नहीं।

ऐसा होने का कारण है से पहले लीप दूसरा वास्तव में होने वाला है कि एनटीपीडी कर्नेल को मध्यरात्रि में दूसरी छलांग को संभालने देता है, लेकिन कर्नाटक को आधी रात से पहले लीप डालने के लिए चेतावनी देने की आवश्यकता होती है। इसलिए एनटीपीडी लीप सेकेंड के दिन के दौरान कभी-कभी adjtimex (2) को कॉल करता है, जिस बिंदु पर यह बग ट्रिगर होता है।

अगर आपके पास adjtimex (8) स्थापित है, तो आप यह स्क्रिप्ट का उपयोग यह निर्धारित करने के लिए कर सकते हैं कि ध्वज 16 सेट है या नहीं। फ्लैग 16 "लीप सेकेंड डालने" है:

adjtimex -p | perl -p -e 'undef $_, next unless m/status: (\d+)/; (16 & $1) && print "leap second flag is set:\n"'

अद्यतन करें:

रेड हैट ने अपने केबी आलेख को नोट करने के लिए अद्यतन किया है: "आरएचईएल 6 ग्राहक एक ज्ञात मुद्दे से प्रभावित हो सकते हैं जो एनटीपी लेडकॉन्ड घोषणा प्राप्त करते समय एनएमआई वॉचडॉग को लटका का पता लगाने का कारण बनता है। इस मुद्दे को समय-समय पर संबोधित किया जा रहा है। अगर आपके सिस्टम प्राप्त हुए हैं leapsecond घोषणा और इस मुद्दे का अनुभव नहीं किया, तो वे अब प्रभावित नहीं हैं। "

अद्यतन: उपरोक्त भाषा को Red Hat आलेख से हटा दिया गया था; और एक दूसरा केबी समाधान जोड़ा गया था जो adjtimex (2) क्रैश समस्या का विवरण दिया गया था: https://access.redhat.com/knowledge/solutions/154713

हालांकि, आईबीएम अभियंता जॉन स्टल्ट्ज द्वारा एलकेएमएल पोस्ट में कोड परिवर्तन में नोट किया गया है कि लीप सेकेंड वास्तव में लागू होने पर डेडलॉक भी हो सकता है, इसलिए आप एनटीपीडी को अक्षम करने के बाद रीबूट या एडीटाइक्स (8) का उपयोग करके लीप सेकेंड को अक्षम करना चाह सकते हैं।

अंतिम अद्यतन:

खैर, मैं कोई कर्नेल देव नहीं हूं, लेकिन मैंने जॉन स्टल्ट्ज के पैच की फिर से समीक्षा की: https://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=6b43ae8a619d17c4935c3320d2ef9e92bdeed05d

अगर मैं इसे सही तरीके से पढ़ रहा हूं, तो लीप दूसरे लागू होने पर मैं एक और डेडलॉक होने के बारे में गलत था। ऐसा लगता है कि उनके केबी एंट्री के आधार पर रेड हैट की राय भी है। हालांकि, अगर आपने ntpd को अक्षम कर दिया है, तो इसे किसी अन्य 10 मिनट के लिए अक्षम रखें, ताकि जब आप ntpd कॉल adjtimex (2) कॉल करते हैं तो आप डेडलॉक को हिट नहीं करते हैं।

हम जल्द ही पता लगाएंगे कि क्या कोई और बग है :)

पोस्ट-लीप दूसरा अपडेट:

मैंने पिछले कुछ घंटों को एनटीपीडी और प्री-पैच (बग्गी) कर्नेल कोड के माध्यम से पढ़ा, और जब मैं यहां बहुत गलत हो सकता हूं, तो मैं यह बताने की कोशिश करूंगा कि मुझे क्या लगता है:

सबसे पहले, एनटीपीडी कॉल टाइमडेक्स (2) हर समय। यह इसे "घड़ी लूप फ़िल्टर" के हिस्से के रूप में करता है, जिसे ntp_loopfilter.c में local_clock में परिभाषित किया गया है। आप यहां वह कोड देख सकते हैं: http://www.opensource.apple.com/source/ntp/ntp-70/ntpd/ntp_loopfilter.c (एनटीपी संस्करण 4.2.6 से)।

घड़ी लूप फ़िल्टर अक्सर चलता है - यह हर बार एनटीपीडी अपने अपस्ट्रीम सर्वरों को चुनाव करता है, जो डिफ़ॉल्ट रूप से हर 17 मिनट या उससे अधिक होता है। घड़ी लूप फ़िल्टर का प्रासंगिक बिट है:

if (sys_leap == LEAP_ADDSECOND)
    ntv.status |= STA_INS;

और तब:

ntp_adjtime(&ntv)

दूसरे शब्दों में, उन दिनों पर जब एक छलांग दूसरा होता है, एनटीपीडी "STA_INS" ध्वज सेट करता है और adjtimex (2) (इसकी पोर्टेबिलिटी-रैपर के माध्यम से) को कॉल करता है।

वह सिस्टम कॉल कर्नेल के लिए अपना रास्ता बनाती है। प्रासंगिक कर्नेल कोड यहां दिया गया है: https://github.com/mirrors/linux/blob/a078c6d0e6288fad6d83fb6d5edd91ddb7b6ab33/kernel/time/ntp.c

कर्नेल कोडपैथ मोटे तौर पर यह है:

  • लाइन 663 - do_adjtimex दिनचर्या की शुरुआत।
  • लाइन 691 - किसी मौजूदा लीप-सेकंड टाइमर को रद्द करें।
  • लाइन 70 9 - एनटीपी_लॉक स्पिनलॉक को पकड़ें (यह लॉक संभव livelock दुर्घटना में शामिल है)
  • लाइन 724 - कॉल process_adjtimex_modes।
  • लाइन 616 - कॉल process_adj_status।
  • लाइन 5 9 0 - निर्धारित समय_स्टैटस ग्लोबल वैरिएबल, adjtimex (2) कॉल में सेट झंडे के आधार पर
  • लाइन 592 - ग्लोबल वैरिएबल टाइम_स्टेट की जांच करें। ज्यादातर मामलों में, ntp_start_leap_timer पर कॉल करें।
  • लाइन 554 - वैश्विक चर के समय_स्टैटस की जांच करें। STA_INS सेट हो जाएंगे, इसलिए टाइम_स्टेट को TIME_INS पर सेट करें और लीप दूसरे टाइमर को शुरू करने के लिए hrtimer_start (अन्य कर्नेल फ़ंक्शन) पर कॉल करें। टाइमर बनाने की प्रक्रिया में, यह कोड xtime_lock पकड़ लेता है। अगर ऐसा होता है जबकि एक और सीपीयू पहले से ही xtime_lock पकड़ लिया है तथा ntp_lock, फिर कर्नेल livelocks। यही कारण है कि जॉन स्टल्ट्ज ने hrtimers का उपयोग करने से बचने के लिए पैच लिखा था। यही कारण है कि आज हर किसी को परेशानी हो रही है।
  • लाइन 598 - अगर ntp_start_leap_timer वास्तव में एक लीप टाइमर शुरू नहीं किया है, तो TIME_OK को TIME_OK सेट करें
  • रेखा 751 - मानते हैं कि कर्नेल जीवित नहीं है, ढेर अवांछित है और ntp_lock spinlock जारी किया गया है।

यहाँ कुछ दिलचस्प चीजें हैं।

सबसे पहले, लाइन 691 प्रत्येक बार adjtimex (2) कहा जाता है, मौजूदा टाइमर रद्द करता है। फिर, 554 उस टाइमर को फिर से बनाता है। इसका मतलब यह है कि हर बार एनटीपीडी ने अपने घड़ी लूप फ़िल्टर को चलाया, बग्गी कोड लगाया गया।

इसलिए मेरा मानना ​​है कि रेड हैट गलत था जब उन्होंने कहा कि एक बार एनटीपीडी ने लीप-सेकंड फ्लैग सेट किया था, तो सिस्टम क्रैश नहीं होगा। मेरा मानना ​​है कि एनटीपीडी चलाने वाली प्रत्येक प्रणाली में लीप-सेकंड से 24 घंटे की अवधि के लिए हर 17 मिनट (या अधिक) को जीवित रहने की क्षमता थी। मेरा मानना ​​है कि यह भी समझा सकता है कि इतने सारे सिस्टम क्यों दुर्घटनाग्रस्त हो गए; दुर्घटनाग्रस्त होने का एक बार मौका 3 घंटे की तुलना में हिट होने की संभावना कम होगी।

अद्यतन: Red Hat के केबी समाधान में https://access.redhat.com/knowledge/solutions/154713 , Red Hat इंजीनियरों को एक ही निष्कर्ष पर आया था (जो चल रहा है ntpd लगातार बग्गी कोड हिट करेगा)। और वास्तव में उन्होंने ऐसा करने से कई घंटे पहले किया था। यह समाधान मुख्य लेख से जुड़ा नहीं था https://access.redhat.com/knowledge/articles/15145 , इसलिए मैंने इसे अब तक नहीं देखा।

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

तीसरा, क्या लीप-सेकंड वास्तव में होता है जब सिस्टम क्रैश होने का मौका होता है? मैं निश्चित रूप से नहीं जानता, लेकिन संभवतः हां, क्योंकि टाइमर जो आग लगता है और वास्तव में लीप-सेकंड एडजस्टमेंट (ntp_leap_second, लाइन 388 पर) निष्पादित करता है, ntp_lock स्पिनलॉक भी पकड़ता है, और hrtimer_add_expires_ns पर कॉल करता है। मुझे नहीं पता कि क्या कॉल भी एक आजीविका पैदा कर सकता है, लेकिन यह असंभव प्रतीत नहीं होता है।

आखिरकार, लीप-सेकेंड के बाद लीप-सेकंड फ्लैग को अक्षम करने का क्या कारण बनता है? उत्तर में एनटीपीडी मध्यरात्रि के बाद कुछ बिंदु पर लीप-सेकंड ध्वज सेट करना बंद कर देता है जब यह adjtimex (2) को कॉल करता है। चूंकि ध्वज सेट नहीं है, लाइन 554 पर चेक सत्य नहीं होगा, और कोई टाइमर नहीं बनाया जाएगा, और लाइन 598 टाइम_स्टेट ग्लोबल वैरिएबल को TIME_OK पर रीसेट कर देगा। यह बताता है कि यदि आपने लीप सेकेंड के ठीक बाद एडीटाइक्स (8) के साथ ध्वज की जांच की है, तो आप अभी भी लीप-सेकंड फ्लैग सेट देखेंगे।

संक्षेप में, आज के लिए सबसे अच्छी सलाह सबसे पहले मैंने पहली बार दी: ऐसा लगता है कि एनटीपीडी अक्षम करें, और लीप-सेकंड फ्लैग को अक्षम करें।

और कुछ अंतिम विचार:

  • लिनक्स विक्रेताओं में से कोई भी जॉन स्टल्ट्ज के पैच को नहीं देखा और इसे अपने कर्नल पर लगाया :(
  • जॉन स्टल्ट्ज ने कुछ विक्रेताओं को क्यों चेतावनी दी थी? शायद आजीविका का मौका इतना कम लग रहा था कि शोर को जरूरी नहीं बनाया गया था।
  • मैंने जावा प्रक्रियाओं की लॉकिंग या कताई की रिपोर्टें सुनाई हैं जब लीप-सेकंड लागू किया गया था। शायद हमें Google के नेतृत्व का पालन करना चाहिए और पुनर्विचार करना चाहिए कि हम अपने सिस्टम में लीप-सेकंड कैसे लागू करते हैं: http://googleblog.blogspot.com/2011/09/time-technology-and-leaping-seconds.html

06/02 जॉन स्टल्टज़ से अपडेट:

https://lkml.org/lkml/2012/7/1/203

इस पोस्ट में एक चरण-दर-चरण चलने का तरीका था, क्यों लीप दूसरे ने फ्यूटेक्स टाइमर को समय-समय पर और लगातार समाप्त होने का कारण बना दिया, सीपीयू लोड को तेज कर दिया।


322
2018-06-30 19:56



उत्कृष्ट उत्तर के लिए धन्यवाद। तो हमारे बाकी सर्वर क्रैश होने का इंतजार कर रहे हैं। लवली। रोलिंग फिर से शुरू होता है हम आते हैं! - Bron Gondwana
मुझे कैसे पता चलेगा कि क्या adjtimex जारी किया गया है, कर्नेल dmesg में कुछ प्रिंट करता है? क्या मौका है कि एक प्रणाली जो एनटीपीडी बंद करने से पहले दुर्घटनाग्रस्त नहीं हुई, दुर्घटनाग्रस्त हो जाएगी? - Hubert Kario
हबर्ट: "adjtimex" चलाएं (यह आमतौर पर अलग से पैक किया जाता है) और एक छलांग को लंबित इंगित करने के लिए ध्वज 16 देखें। - Dominic Cleal
आप प्रतिनिधि टोपी से नफरत करने जा रहे हैं। - Wesley
@ वेस्ले डेविड: कोई चिंता नहीं, प्रतिनिधि टोपी यूटीसी मध्यरात्रि में रीसेट हो जाएगी। शायद। - mmyers


यह हमें मुश्किल मारा। हमारे कई मेजबानों को पुनरारंभ करने के बाद, मेजबान पुनरारंभ किए बिना निम्नलिखित शर्मनाक सरल और पूरी तरह प्रभावी हो गए:

/etc/init.d/ntp stop
ntpdate 0.us.pool.ntp.org
/etc/init.d/ntp start

सिस्टम की घड़ी को रीसेट करना आवश्यक है। शीश। मैंने जो छह घंटे पहले यह जान लिया है।


33
2017-07-01 07:49



date -s "`date`" मेरे लिए काम किया - Pointy
@ डीनबी: मैंने 3 बजे यूटीसी पर पोस्ट किया है कि घड़ी को रीसेट करने से चाल चलती है, दुर्भाग्य से इसे कम करने में थोड़ी देर लग गई। हमने सर्वर को रिबूट करना शुरू कर दिया था - Gregor


एक सरल सी प्रोग्राम जो कर्नेल के समय स्थिति फ़ील्ड में छलांग को दूसरी बिट साफ़ करता है:

#include <sys/timex.h>
#include <string.h>
#include <stdio.h>

int main(int argc, char **argv) {
    struct timex txc;
    int ret;

    (void) argc;
    (void) argv;

    bzero(&txc, sizeof(txc));
    txc.modes = 0;  /* fetch */
    ret = adjtimex(&txc);
    if (ret < 0) {
        perror("adjtimex (get)");
        return 1;
    }

    txc.modes = ADJ_STATUS;
    txc.status &= ~16;
    ret = adjtimex(&txc);
    if (ret < 0) {
        perror("adjtimex (set)");
        return 1;
    }

    return 0;
}

के रूप रक्षित करें lsec.c, संकलन gcc -Wall -Wextra -o lsec lsec.c और रूट के रूप में चलाओ।

आप इसे चलाने से पहले ntpd को रोकना चाहते हैं, और लीप सेकेंड के बाद ntpd को पुनरारंभ करें।


24
2018-06-30 23:13



क्या करता है (void) argc; पूरा? अप्रयुक्त चर के लिए चेतावनी को शांत करें? उपयोग नहीं करेंगे int main() वही पूरा करें? एक पेडेंट होने की कोशिश नहीं कर रहा, मैं वास्तव में उत्सुक हूँ। - gparent


Postmortem ऐसा लगता है ./lsec का कोई प्रभाव नहीं पड़ता है।

हम जो देख रहे हैं वह बहुत सी सॉफ्टरक्ड प्रक्रिया सीपीयू खाने (आमतौर पर जावा प्रक्रियाओं के भार से रैखिक)

POSTMORTEM को ठीक करने के लिए काम क्या करता है पहले से ही एनटीपी द्वारा लागू लीप सेकंड निम्न है:

यह केवल जारी करने के लिए पर्याप्त प्रतीत होता है:

export LANG="en_EN"; date -s "`date`"

यह एनटीपीडी पुनरारंभ या रीबूट किए बिना लोड को कम करना चाहिए। वैकल्पिक रूप से आप जारी कर सकते हैं:

apt-get install ntpdate
/etc/init.d/ntpd stop; ntpdate pool.ntp.org; /etc/init.d/ntpd start

18
2017-07-01 03:41



क्यूं कर sntp -s और नहीं ntpdate? - errordeveloper
ntpdate यहां स्नैप करने के लिए सिर्फ एक रैपर है, सुनिश्चित करें कि ntpdate का उपयोग करना ठीक है। - Gregor
आह मैं पूरी तरह से चूक गया निचोड़ के लिए एक ntpdate पैकेज है जहां यह वास्तव में एक बाइनरी है। मैंने इसे शामिल करने के लिए अपनी पोस्टिंग संपादित की है। - Gregor
मैंने इस मुद्दे को ठीक करने की समान रिपोर्टें भी सुनी हैं (जैसे कि उपयोग करना date -s)। ऐसा लगता है कि फिक्स की तरह बस सिस्टम को समयबद्ध करने की आवश्यकता है (ऑफ़सेट होने पर डिफ़ॉल्ट एनटीपीडी व्यवहार)। मैं समय निर्धारित करने का अनुमान लगा रहा हूं कि कर्नेल के आंतरिक समय-रखरखाव यांत्रिकी स्वयं को रीसेट करने का कारण बनता है। - Patrick
मेरे जावा ऐप सीपीयू उपयोग में भी तेजी आई है (सॉफ्टरक्ड में बिताए गए CPU समय की उच्च मात्रा के साथ), यह तय है। - Hubert Kario


http://my.opera.com/marcomarongiu/blog/2012/03/12/no-step-back ऐसा लगता है कि डेबियन निचोड़ कर्नेल दूसरे छलांग को संभाल नहीं पाएगा।

Comp.protocols.tim.ntp पर यह धागा ब्याज का है, यह भी: https://groups.google.com/forum/?fromgroups#!topic/comp.protocols.time.ntp/KSflIgjUdPE

उस ने कहा, छलांग दूसरा अभी तक नहीं हुआ है: 23:59:60 यूटीसी

आखिरकार, https://access.redhat.com/knowledge/articles/15145 निम्न कहने के लिए निम्न है: "जब लीप दूसरा होता है, तो कर्नेल सिस्टम लॉग को एक संदेश प्रिंट करता है। एक मौका है कि इस संदेश की छपाई से कर्नेल को Red Hat Enterprise Linux में क्रैश हो सकता है।"


17
2018-06-30 18:47



लेकिन 3.2.21 कर्नेल, अनुमानतः - जो दुर्घटनाग्रस्त मशीनों में से कम से कम एक चल रहा था - Bron Gondwana
उन मशीनों में से कुछ जो ब्रॉन ने इंगित किया है कि हमने वास्तव में एक फिक्स लॉन्च किया है जो आगामी लीप सेकेंड को सही ढंग से संभालना चाहिए। - cosimo
क्या आप किसी जगह को ठीक कर सकते हैं ताकि अन्य विचार / सुझावों की समीक्षा / सुझाव दे सकें? - kargig
मेरे पास कोई फिक्स नहीं है ... मैं सिर्फ जानकारी एकत्र कर रहा हूं। शायद इसे मूल प्रश्न के खिलाफ टिप्पणी के रूप में रखना चाहिए था। - Luca Filipozzi
my.opera.com/marcomarongiu/blog/2012/06/01/... इसमें फिक्सिंग के बारे में अधिक जानकारी है - Bron Gondwana