किसी अन्य व्यक्ति को दूसरे दिन लीप के दौरान लिनक्स सर्वर क्रैश की उच्च दर का सामना करना पड़ रहा है?

Question

* नोट: यदि आपके सर्वर में अभी भी गुठली के कारण समस्याएँ हैं, और आप रिबूट नहीं कर सकते हैं - आपके सिस्टम पर स्थापित ग्नू तिथि के साथ प्रस्तावित सबसे सरल समाधान है: दिनांक -s अब। यह कर्नेल के आंतरिक "time_was_set" वैरिएबल को रीसेट करेगा और जावा और अन्य यूजरस्पेस टूल में सीपीयू हॉगिंग फ्यूटेक्स लूप को ठीक करेगा। मैंने अपने सिस्टम पर इस आदेश की पुष्टि की है, यह पुष्टि करता है कि यह टिन पर क्या कह रहा है *

पोस्टमार्टम

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

मैंने 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 सेकंड के स्किप से बचने के लिए ntpd -x का उपयोग करके 24 घंटे से अधिक के समय में परिवर्तन करना। यह अपने स्वयं के ntp बुनियादी ढांचे को चलाने के लिए एक वैकल्पिक स्मियरिंग विधि है।

---

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

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

एक दुर्घटना जो मुझे कहा से एक स्क्रीन डंप मिला:

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

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

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

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

काम करता है

ठीक है, लोग, यहाँ मैंने इसके चारों ओर कैसे काम किया।

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

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

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

जैसा कि एक अनाम उपयोगकर्ता ने सुझाव दिया है - दौड़ने adjtimexका एक विकल्प सिर्फ खुद को समय निर्धारित करना है, जो संभवतः लेप्सकॉन्ड काउंटर को भी साफ़ कर देगा।

Comments

आज 30 वें स्थान पर एक छलांग है। मुझे यह समझने में संकोच है कि आपकी समस्या है, लेकिन मैं अपने डेबियन मशीनों को करीब से देखूंगा।

— jscott

सुबह से हम विभिन्न विक्रेताओं से कम से कम 9 अलग-अलग डेबियन निचोड़ बक्से खो चुके हैं, जो सभी स्टॉक स्टॉक को 2.6.32 कर्नेल से चला रहे हैं। कंसोल

— कंबलिंग के

इस बारे में lkml पोस्टिंग lkml.indiana.edu/hypermail/linux/kernel/1203.1/04598.html

— डैनियल एस स्टर्लिंग

यह रिपोर्ट करने के लिए धन्यवाद! अब मैं अपने सर्वर पर बहुत बारीकी से घूर रहा हूं।

— Janne Pikkarainen

एलकेएमएल धागे ने संकेत दिया कि date -s "`date`"मदद करता है - यह निश्चित रूप से मेरी मदद करता है।

— पोइंटी जूल 1'12

Answer 1

यह एक लाइवलॉक के कारण होता है जब ntpd एक लीप सेकंड डालने के लिए कर्नेल को बताने के लिए adjtimex (2) कहता है। देखें lkml पोस्टिंग http://lkml.indiana.edu/hypermail/linux/kernel/1203.1.14545.html

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

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

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

यह आरएचईएल 6 और अन्य डिस्ट्रोस को नई गुठली (लगभग 2.6.26 की तुलना में नया) से प्रभावित करता है, लेकिन आरएचईएल 5 को नहीं।

लीप सेकंड से पहले होने का कारण वास्तव में होने वाला है, यह है कि ntpd कर्नेल को आधी रात को लीप सेकंड को संभालने देता है, लेकिन कर्नेल को मध्यरात्रि से पहले लीप सेकंड को डालने के लिए सचेत करने की आवश्यकता है। ntpd इसलिए 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"'

अपडेट करें:

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

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

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

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

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

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

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

पोस्ट-लेप उत्तर अद्यतन:

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

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

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

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

और तब:

ntp_adjtime(&ntv)

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

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

कर्नेल कोडपथ लगभग यही है:

• पंक्ति 663 - do_adjtimex दिनचर्या की शुरुआत।
• लाइन 691 - किसी भी मौजूदा लीप-सेकंड टाइमर को रद्द करें।
• लाइन 709 - ntp_lock स्पिनलॉक को पकड़ो (यह लॉक संभव लाइवलॉक क्रैश में शामिल है)
• लाइन 724 - कॉल process_adjtimex_modes।
• पंक्ति 616 - कॉल process_adj_status।
• लाइन 590 - adjtimex (2) कॉल में सेट किए गए झंडे के आधार पर time_status वैश्विक चर सेट करें
• लाइन 592 - समय-समय पर वैश्विक चर की जाँच करें। ज्यादातर मामलों में, ntp_start_leap_timer को कॉल करें।
• पंक्ति ५५४ - time_status वैश्विक चर की जाँच करें। STA_INS सेट किया जाएगा, इसलिए TIME_INS पर time_state सेट करें और लीप सेकंड टाइमर शुरू करने के लिए hrtimer_start (एक और कर्नेल फ़ंक्शन) को कॉल करें। टाइमर बनाने की प्रक्रिया में, यह कोड xtime_lock को पकड़ लेता है। यदि ऐसा होता है जबकि एक अन्य CPU पहले ही xtime_lock और ntp_lock को पकड़ लेता है, तो कर्नेल लाइवलॉक करता है। यही कारण है कि जॉन स्टल्ज ने हर्टिमर का उपयोग करने से बचने के लिए पैच लिखा था। यही आज सबको परेशान कर रहा था।
• लाइन 598 - अगर ntp_start_leap_timer ने वास्तव में लीप टाइमर शुरू नहीं किया है, तो time_state को TIME_OK पर सेट करें
• लाइन 751 - यह मानते हुए कि कर्नेल लाइवलॉक नहीं है, स्टैक अनवाउंड है और ntp_lock स्पिनलॉक जारी किया गया है।

यहां कुछ दिलचस्प बातें हैं।

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

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

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

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

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

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

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

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

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

---

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

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

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

Comments

उत्कृष्ट उत्तर के लिए धन्यवाद। इसलिए हमारे बाकी सर्वर क्रैश होने के इंतजार में बैठे हैं। लवली। रोलिंग शुरू यहाँ हम आते हैं!

— ब्रॉन गोंडवाना

मुझे कैसे पता चलेगा कि adjtimexजारी किया गया है, क्या कर्नेल dmesg में कुछ प्रिंट करता है? क्या मौका है कि एक प्रणाली जो एनटीपीडी को बंद करने से पहले दुर्घटनाग्रस्त नहीं हुई वह दुर्घटनाग्रस्त हो जाएगी?

— ह्यूबर्ट करियो

हबर्ट: "एडजाइमक्स" चलाएं (यह आमतौर पर अलग से पैक किया जाता है) और एक छलांग के लिए ध्वज 16 की तलाश करें जो लंबित दूसरे को इंगित करता है।

— डोमिनिक क्लेल

आप प्रतिनिधि टोपी से नफरत करने जा रहे हैं।

— वेस्ले

@WesleyDavid: कोई चिंता नहीं, UTC में आधी रात को री कैप कैप रीसेट हो जाएगा। शायद।

— मिमी

Answer 2

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

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

सिस्टम क्लॉक को रीसेट करना आवश्यक है। शीश। मैंने छह घंटे पहले इस बात का पता दिया था।

Comments

date -s "`date`"मेरे लिए काम किया।

— पोइंटी जूल

@DeanB: मैंने 3 बजे UTC में पोस्ट किया है कि घड़ी को रीसेट करने से चाल चल रही है, दुर्भाग्य से इसे मॉडरेट करने में थोड़ा समय लगा। हमने रिबूट करने वाले सर्वरों को भी शुरू किया

— ग्रेगोर

Answer 3

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

#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 को फिर से शुरू करेंगे।

Comments

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

— अपराह्न 29:12

Answer 4

पोस्टमॉर्टम ऐसा लगता है ।/lsec का प्रभाव नहीं है।

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

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

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

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

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

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

Comments

क्यों sntp -sऔर क्या नहीं ntpdate?

— इरोडेवलपर्स

ntpdate यहाँ sntp के लिए एक आवरण है, निश्चित रूप से ntpdate का उपयोग करना ठीक है।

— ग्रेगोर

आह, मैं पूरी तरह से याद किया है निचोड़ के लिए एक ntpdate पैकेज है जहां यह वास्तव में एक द्विआधारी है। इसे शामिल करने के लिए मैंने अपनी पोस्टिंग संपादित की है।

— ग्रेगोर

मैंने इस मुद्दे को ठीक करने की समान रिपोर्टें भी सुनी हैं (जैसे कि उपयोग करना date -s)। ऐसा लगता है कि इसे ठीक करने के लिए सिस्टम समय निर्धारित करने की आवश्यकता है बजाय इसे (डिफ़ॉल्ट एनटीपीपी व्यवहार जब ऑफसेट छोटा होता है)। मैं अनुमान लगा रहा हूं कि समय की सेटिंग के कारण कर्नेल के आंतरिक टाइम-मैकेनिक खुद को रीसेट कर सकते हैं।

— पैट्रिक

मेरे जावा एप्स सीपीयू के उपयोग में भी वृद्धि हुई (सॉफ्टरिक में सीपीयू समय की उच्च मात्रा के साथ), इसने इसे ठीक कर दिया।

— ह्यूबर्ट करियो जूल

Answer 5

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 में कर्नेल क्रैश होने का कारण बन सकता है। "

Comments

लेकिन 3.2.21 कर्नेल, संभवतः - जो कि दुर्घटनाग्रस्त मशीनों में से कम से कम एक चल रहा था

— ब्रॉन गोंडवाना

उन मशीनों में से कुछ पर जिन्हें ब्रोन ने संकेत दिया था कि हमने वास्तव में एक फिक्स रोल किया है जिसे आगामी लीप सेकंड को सही ढंग से संभालना चाहिए।

— कोसिमो

क्या आप किसी जगह को ठीक कर सकते हैं ताकि अन्य लोग विचारों की समीक्षा / सुझाव दे सकें?

— कारगिग

मेरे पास एक फिक्स नहीं है ... मैं सिर्फ जानकारी इकट्ठा कर रहा हूं। शायद इसे मूल प्रश्न के खिलाफ टिप्पणी के रूप में रखना चाहिए था।

— लुका फिलिप्पोज़ज़ी

my.opera.com/marcomarongiu/blog/2012/06/01/... उसे ठीक करने के लिए और अधिक विवरण होता है

— Bron गोंडवाना