मैंने एलएसआई समर्थन को दो बार अधिसूचित किया है, लेकिन अभी तक वे समस्या को पुन: उत्पन्न करने में असमर्थ हैं। मैं इसके बारे में कुछ निष्पक्ष विशेषज्ञ विचार प्राप्त करने के लिए यहां पोस्ट करना चाहता हूं और देखें कि क्या किसी और ने भी इसी तरह की समस्या देखी है।

हम कई सर्वरों का प्रबंधन करते हैं जो बहुत भारी डिस्क IO के साथ इंटरनेट सेवाएं प्रदान करते हैं। सभी डेबियन परीक्षण (Sid) -amd64 चलाते हैं और 85xx - 96xx श्रृंखला से 3वेयर RAID कार्ड का उपयोग करते हैं। 3.9.x-amd64 में डेबियन कर्नेल अपडेट के साथ हमें tw_cli के साथ एक segfault मिलना शुरू हुआ। हमने tdm2 का परीक्षण किया और यह segfaults भी है।

समस्या को पुन: उत्पन्न करने के लिए: (ऐसा करने के लिए आपको अपने सिस्टम में RAID कार्ड की आवश्यकता नहीं है) 1. डेबियन परीक्षण (सिड) की ताजा स्थापना। आईएसओ है http://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-cd/ 2. tw_cli इंस्टॉल करें और इसे चलाने का प्रयास करें।

हमने 3.2 और 3.9.6/3.9.8-amd64 के तहत स्ट्रेस के साथ tw_cli को रूट के रूप में चलाया और tw_cli कॉल uname के ठीक बाद segfault हो रहा है जैसा कि आप नीचे देख सकते हैं।

अच्छी दौड़:

execve("/usr/local/sbin/tw_cli", ["tw_cli", "/c0", "show", "all"], ["TERM=xterm", "SHELL=/bin/bash", "SSH_CLIENT=71.207.183.174 60609 "..., "SSH_TTY=/dev/pts/0", "USER=root", "MAIL=/var/mail/root", "PATH=/usr/local/sbin:/usr/local/"..., "PWD=/root", "LANG=C", "PS1=\\h:\\w\\$ ", "SHLVL=1", "HOME=/root", "LOGNAME=root", "SSH_CONNECTION=71.207.183.174 60"..., "_=/usr/bin/strace"]) = 0
uname({sysname="Linux", nodename="yorick.ironicdesign.com", release="3.2.0-4-amd64", version="#1 SMP Debian 3.2.46-1", machine="x86_64"}) = 0
brk(0)                                  = 0x2664000
brk(0x2685000)                          = 0x2685000
uname({sysname="Linux", nodename="yorick.ironicdesign.com", release="3.2.0-4-amd64", version="#1 SMP Debian 3.2.46-1", machine="x86_64"}) = 0
open("/proc/devices", O_RDONLY)         = 3
...

खराब रन:

execve("/usr/local/sbin/tw_cli", ["tw_cli", "/c0", "show", "all"], ["SHELL=/bin/bash", "TERM=screen", "SSH_CLIENT=98.26.9.112 58271 22", "SSH_TTY=/dev/pts/0", "USER=root", "SSH_AUTH_SOCK=/tmp/ssh-595iwzIik"..., "TERMCAP=SC|screen|VT 100/ANSI X3"..., "PATH=/usr/local/sbin:/usr/local/"..., "MAIL=/var/mail/root", "STY=17473.mdorman", "PWD=/root", "LANG=C", "PS1=\\h:\\w\\$ ", "HOME=/root", "SHLVL=2", "LOGNAME=root", "WINDOW=0", "SSH_CONNECTION=98.26.9.112 58271"..., "_=/usr/bin/strace"]) = 0
uname({sysname="Linux", nodename="yorick.ironicdesign.com", release="3.10-1-amd64", version="#1 SMP Debian 3.10.1-1 (2013-07-16)", machine="x86_64"}) = 0
brk(0)                                  = 0x26ef000
brk(0x2710000)                          = 0x2710000
uname({sysname="Linux", nodename="yorick.ironicdesign.com", release="3.10-1-amd64", version="#1 SMP Debian 3.10.1-1 (2013-07-16)", machine="x86_64"}) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---

उपरोक्त अच्छे क्रम में, uname के बाद अगली कॉल /proc/devices को खोलना है जो मौजूद है और कोई समस्या नहीं होनी चाहिए। कुछ और जो हमें लगता है वह उल्लेखनीय है और आप इसे ऊपर खराब रन में देख सकते हैं, 3.9/3.10 कर्नेल में uname स्ट्रिंग में एक तारीख जोड़ता है।

हमें लगता है कि ये दो स्ट्रेस रन यह संकेत दे सकते हैं कि tw_cli क्रैश हो रहा है क्योंकि इसे uname कॉल से अप्रत्याशित प्रतिक्रिया मिल रही है। एलएसआई समर्थन कहते हैं:

"3dm2 और tw_cli उबंटू के नवीनतम कर्नेल 3.10.x के साथ भी ठीक काम करते हैं और उबंटू आमतौर पर डेबियन से अस्थिर कर्नेल खींचता है और इसे अपने रिलीज के लिए उपयोग करता है।"

एफडब्ल्यूआईडब्ल्यू, मुझे यकीन नहीं है कि एलएसआई समर्थन किस बारे में बात कर रहा है। हमने अभी-अभी उबंटू 1304 (रेरिंग रिंगटेल) और uname -a के एक नए, अप-टू-डेट इंस्टालेशन के साथ परीक्षण किया "लिनक्स मैक-वर्कस्टेशन 3.8.0-26-जेनेरिक # 38-उबंटू एसएमपी सोम जून 17 21:43:33 यूटीसी 2013 x86_64 x86_64 x86_64 जीएनयू/लिनक्स"। तो उबंटू 1304 3.8 कर्नेल का उपयोग कर रहा है, 3.10 का नहीं। और tw_cli और tdm2 दोनों ठीक काम करते हैं।

तो कोई मददगार विचार? इस समय हमारे विकल्प दिखाई देते हैं: - हमारे कर्नेल संस्करण को 3.2 पर पिन करें और आशा करें कि जो भी समस्या जल्द ही ठीक हो जाए - हमारे RAID की निगरानी करना बंद कर दें (वास्तव में एक विकल्प नहीं) - हमारे सभी सर्वरों के लिए कस्टम कर्नेल संकलित करें क्योंकि जाहिर तौर पर स्टॉक डेबियन टेस्टिंग कर्नेल में यह समस्या है - हमारे सभी सर्वरों के लिए उबंटू पर स्विच करें (संभव नहीं) - हमारे RAID कार्ड को अरेका जैसे किसी व्यक्ति पर स्विच करें (मौजूदा सर्वर के लिए भी संभव नहीं है, लेकिन हमारी अगली सर्वर पीढ़ी के लिए विचार किया जा रहा है)

=================== फॉलोअप =========================

मुझे एलएसआई/3वेयर समर्थन से अभी निम्नलिखित प्रतिक्रिया मिली है। मुझे डर है कि उनके प्रति मेरी प्रतिक्रिया बहुत अच्छी नहीं थी, हालांकि मेरा मानना ​​है कि इसने स्थिति को सटीक रूप से अभिव्यक्त किया है।

एलएसआई/3वेयर ने कहा: हम डेबियन अस्थिर कर्नेल 3.9-1-amd64 के साथ इस मुद्दे को पुन: उत्पन्न करने में सक्षम हैं लेकिन इंजीनियरिंग गैर-स्थिर या गैर-रिलीज़ किए गए कर्नेल के लिए सॉफ़्टवेयर जारी नहीं करता है। यदि संभव हो, तो कृपया तब तक प्रतीक्षा करें जब तक कि डेबियन आधिकारिक रूप से कर्नेल जारी न कर दे। 3dm2 और tw_cli को Ubuntu आधिकारिक रिलीज़ 13.04 के साथ काम करना चाहिए जिसमें अद्यतन कर्नेल 3.8.x से 3.10 शामिल हैं।

मेरी प्रतिक्रिया:

तो अंतिम परिणाम है:

  • आप डेबियन परीक्षण की एक नई स्थापना नहीं करेंगे जो समस्या को पुन: उत्पन्न करेगा। मैंने आपको "आधिकारिक" परीक्षण आईएसओ का लिंक भी दिया है जिसमें समस्या है।

इसके बजाय आप पहले एक कस्टम कर्नेल संकलित करते हैं जो किसी तरह समस्या से बचा जाता है। फिर आप समस्या को पुन: उत्पन्न करने के लिए परीक्षण को अस्थिर करने के लिए कूदते हैं। सिवाय "इंजीनियरिंग अन-स्टेबल या अन-रिलीज़ किए गए कर्नेल के लिए सॉफ़्टवेयर जारी नहीं करता है" ... इसलिए एक बार फिर आप कोई कार्रवाई करने से बचते हैं।

  • फिर आपके पास यह सुझाव देने की हिम्मत है कि हम डेबियन आधिकारिक रिलीज़ (हम हैं) का उपयोग नहीं कर रहे हैं या कि हम अपने सभी सर्वरों पर चल रही अपनी सेवाओं को बंद कर सकते हैं और एक नए वितरण के लिए स्वैप कर सकते हैं ???

हमारे लिए अच्छी खबर यह है कि हम डेबियन समुदाय में हैं और सभी को बताएंगे कि एलएसआई ने इसे कैसे संभाला है। यह आपके उत्पादों की दीर्घकालिक व्यवहार्यता के बारे में शेष Linux समुदाय को एक मजबूत संकेत भेजने वाला है।

शुक्रिया

============= मेरा निष्कर्ष ============

हां, हम उत्पादन में आधिकारिक डेबियन परीक्षण रिलीज का उपयोग करते हैं और कुछ लोग सोचते हैं कि यह बुद्धिमानी नहीं है।

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

इसलिए जब हम आधिकारिक डेबियन परीक्षण को लोड करने और उनके सॉफ़्टवेयर को ठीक करने का निर्णय लेने के लिए एलएसआई/3वेयर की प्रतीक्षा करते हैं, तो हम शायद अपने कर्नेल को 3.2 पर पिन कर देंगे। हमें 3.10 कर्नेल को संकलित करने का समय भी मिल सकता है जो कि uname -r के साथ एक तारीख को आउटपुट नहीं करता है यह देखने के लिए कि क्या यह वास्तव में कारण है। यदि ऐसा है तो हम कर्नेल के लिए अनाम कॉल में उस परिवर्तन को प्राप्त करने में सक्षम हो सकते हैं।

answer

कर्नेल 3.12.XXX के साथ डेबियन टेस्टिंग पर मुझे यहाँ भी यही समस्या थी। मेरे लिए कमांड सेटर्च (या linux64) ने काम किया:

web3:~# setarch x86_64 --uname-2.6 tw_cli /c0/u0 show all

या

web3:~# linux64 --uname-2.6 tw_cli /c0/u0 show all

समस्या तारीख नहीं है, यह है कि tw_cli रिलीज में XYZ(-R-arch) की तलाश में है और इसे केवल XY(-R-arch) - 3.2.0-4-amd64 बनाम 3.10-2-amd64 मिल रहा है। जब रिलीज को 3.10.0-2-amd64 पर सेट किया जाता है तो यह ठीक चलता है। वे सीमित प्रारूपों के साथ sscanf() कर रहे हैं, और बहुत कम या कोई त्रुटि जांच नहीं कर रहे हैं।

jam:~# uname -r
3.10-2-amd64
jam:~# tw_cli /c0 show firmware
Segmentation fault
jam:~# echo 3.10.0-2-amd64 > /sys/module/utsname/parameters/release
jam:~# uname -r
3.10.0-2-amd64
jam:~# tw_cli /c0 show firmware
/c0 Firmware Version = FE9X 4.10.00.027

यदि बाइनरी गतिशील थी तो आप LD_PRELOAD के साथ एक uname() प्रतिस्थापन के बारे में देख सकते थे लेकिन यह स्थिर है। कोई स्रोत कोड नहीं है इसलिए हमारे विकल्प सीमित हैं:

  • LSI/3वेयर tw_cli को ठीक करता है, उम्मीद है कि सभी uname() बकवास को हटा देगा
  • रिलीज में XYZ-R-arch का उपयोग करने के लिए डेबियन प्राप्त करें
  • असेंबली के साथ अच्छा कोई बाइनरी पैच या कुछ इसी तरह के साथ आता है
  • एक कस्टम कर्नेल चलाएँ
  • एक पुराना कर्नेल चलाएँ
  • खाई 3वेयर

मुझे मेरा 9650 पसंद है लेकिन यह बकवास है।

जब तक आप इसका परीक्षण नहीं करना चाहते तब तक आपको डेबियन परीक्षण नहीं चलाना चाहिए। विशेष रूप से सर्वर पर नहीं। मैं कहूंगा कि इसे डेबियन स्थिर में पुन: पेश करने का प्रयास करें।

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

वास्तव में इसके बारे में सोचने के लिए आते हैं, अगर tdm2 segfaults तो व्यवस्थापक इंटरफ़ेस भी काम नहीं कर रहा है ...

3.10 कर्नेल (tw_cli segfault सहित) के साथ डेबियन परीक्षण पर एक ही समस्या है। उल्लेख करने की आवश्यकता है, डेबियन परीक्षण 'स्थिर रिलीज' नामक अन्य डिस्ट्रो की तुलना में बहुत अधिक स्थिर है;) हालांकि समस्या की तरह लगता है कि डिस्ट्रो परीक्षण से अधिक कर्नेल संस्करण से संबंधित है। 3.2 पर वापस स्विच किया गया और यह ठीक काम करता है, एलएसआई सॉफ्टवेयर अपडेट की भी प्रतीक्षा कर रहा है, लेकिन हमारे पास 3वेयर 9500 श्रृंखला है, इसलिए इसके लिए कोई बड़ी उम्मीद नहीं है।