क्यों चल रहे लिनक्स सिस्टम को अपडेट करना समस्याग्रस्त नहीं है?


25

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

एक उदाहरण देता हूं।

मान लीजिए कि एक निश्चित पैकेज से एक प्रोग्राम "ए" एक सिस्टम पर चल रहा है। यह कार्यक्रम, एक निश्चित बिंदु पर, उसी पैकेज से एक और फ़ाइल ("बी") खोलने की आवश्यकता है। उसके बाद, प्रोग्राम "ए" "बी" को बंद कर देता है क्योंकि इसे अब इसकी आवश्यकता नहीं है। मान लीजिए अब मैं पैकेज "ए" और "बी" को अपडेट करता हूं। इस ऑपरेशन से "ए" सीधे प्रभावित नहीं होता है, कम से कम फिलहाल, क्योंकि यह रैम में चल रहा है और हार्ड डिस्क पर "ए" को बदल दिया गया है। मान लीजिए कि "बी" को फाइल सिस्टम पर भी बदल दिया गया है। अब "ए" को किसी कारण से "बी" को फिर से पढ़ने की आवश्यकता है। सवाल यह है कि क्या यह संभव है कि "ए" "बी" का असंगत संस्करण ढूंढ सकता है और किसी अन्य तरीके से दुर्घटना या खराबी कर सकता है?

लाइव सीडी या कुछ इसी तरह की प्रक्रिया के साथ रीबूट करके कोई भी अपने सिस्टम को अपडेट क्यों नहीं करता है?


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

जवाबों:


23

यूजरलैंड को अपडेट करना शायद ही कभी एक समस्या है

आप अक्सर लाइव सिस्टम पर पैकेज अपडेट कर सकते हैं क्योंकि:

  1. साझा पुस्तकालयों को मेमोरी में संग्रहीत किया जाता है, प्रत्येक कॉल पर डिस्क से नहीं पढ़ा जाता है, इसलिए पुराने संस्करण उपयोग में रहेंगे जब तक कि एप्लिकेशन को फिर से शुरू नहीं किया जाता है।
  2. ओपन फाइल वास्तव में फाइल-डिस्क्रिप्टर से पढ़ी जाती है , न कि फाइल के नाम से, इसलिए फाइल कंटेंट चल रहे एप्लिकेशन के लिए तब भी उपलब्ध रहते हैं, जब तक कि सेक्टरों के लिखित या फाइल डिस्क्रिप्टर के बंद होने तक स्थानांतरित / नाम बदल दिया जाता है।
  3. यदि पैकेज को अच्छी तरह से डिज़ाइन किया गया है तो पैकेज को फिर से लोड करने या फिर से शुरू करने की आवश्यकता होती है। उदाहरण के लिए, जब भी libc6 को अपग्रेड किया जाता है, तो डेबियन कुछ सेवाओं को पुनः आरंभ करेगा।

आम तौर पर, जब तक आप अपने कर्नेल को अपडेट नहीं कर रहे हैं और ksplice का उपयोग नहीं कर रहे हैं, तब प्रोग्राम या सेवाओं को अपडेट का लाभ उठाने के लिए पुनरारंभ करने की आवश्यकता हो सकती है। हालांकि, यूजरलैंड में कुछ भी अपडेट करने के लिए सिस्टम को रिबूट करने की आवश्यकता शायद ही होती है, हालांकि डेस्कटॉप पर यह व्यक्तिगत सेवाओं को पुनरारंभ करने की तुलना में कभी-कभी आसान होता है।

यह भी देखें

http://en.wikipedia.org/wiki/Ring_%28computer_security%29#Supervisor_mode


लेकिन क्या होगा, अगर आपको सभी कैश-मेमोरी की आवश्यकता है? उस स्थिति में शेयर-पुस्तकालयों को फिर से डिस्क से लोड करना होगा ...
निल्स

3
वास्तव में # 1 का वर्णन इतना स्पष्ट नहीं था। पुरानी लाइब्रेरी फ़ाइल सामग्री एक अलग (मूल) इनोड के अंतर्गत रहती है, भले ही इससे लिंक करने वाले सभी नाम छूट गए हों, जब तक कि किसी प्रक्रिया में फ़ाइल खुल गई है, या इसकी सामग्री मैप नहीं हो गई है, डेटा अलग रखा गया है (और फाइल सिस्टम नहीं कर सकता फ़ाइल के अनलिंक होने तक r / o को रिमूव किया जाए)। मूल फ़ाइल को मैप करने वाली प्रक्रिया में अभी भी मूल सामग्री में मेमोरी मैपिंग है।
स्केपरन 19

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

@ जो नहीं - स्वैप राम है, भी। स्केपरेन बताता है कि क्या होता है: फ़ाइल-हैंडल को बरकरार रखा जा रहा है। इसलिए मूल रूप से कार्यक्रम में पुरानी (गई) लाइब्रेरी के लिए एक हैडल है, जिसे तब तक नहीं हटाया जाएगा जब तक कि हैंडल फिर से फ्री न हो जाए - यह सब फाइलसिस्टम-लेवल पर है - रैम-लेवल पर नहीं।
नेल्स

4

हां, आपने जो वर्णन किया है वह संभव है, लेकिन ज्यादातर समय यदि फ़ाइल को पैकेज के साथ शामिल किया जाता है, तो यह एक लाइब्रेरी या अन्य फाइल होने वाली है, जिसे एक बार और केवल एक बार पढ़ा जाता है (क्योंकि यह नहीं बदलता है, इसका कोई कारण नहीं है) इसे कई बार पढ़ें)। यदि फ़ाइल को दीर्घकालिक की आवश्यकता है, तो एप्लिकेशन को संभवतः फ़ाइल हैंडल को खुला छोड़ देगा, जिसमें भले ही वह वास्तविक फाइल सिस्टम पर प्रतिस्थापित हो, खुले फ़ाइल हैंडल पुराने संस्करण को खुला रखेगा।

ज्यादातर मामलों में, किसी भी डेटा को प्रक्रिया के जीवन के दौरान कई बार पढ़ा जाता है जो उपयोगकर्ता / चर डेटा है, और यह पैकेज अपग्रेड के दौरान नहीं बदलेगा। इसके अलावा जब डेटा परिवर्तनशील होता है, तो कोई भी प्रोग्रामर अपने दाहिने दिमाग में यह सुनिश्चित कर लेगा कि प्रोग्राम इसे एक रीडिंग से दूसरे में बदलने से संभाल सकता है।


फ़ाइल को अभी भी "बैकिंग स्टोर" के रूप में फिर से पढ़ा जा सकता है यदि इसकी मैपिंग से मेमोरी में कोई बदलाव नहीं हुआ (जो अन्यथा उपलब्ध होने पर बैकिंग स्टोर को स्वैप करने के लिए शिफ्ट कर देगा), और मेमोरी कॉपी का उपयोग करने के लिए अन्य मांग के दबाव के कारण छूट जाती है। स्मृति। लेकिन यह कोई समस्या नहीं है क्योंकि मूल फ़ाइल अभी भी खुली या मैप की गई है। प्रतिस्थापन पुस्तकालय एक नई और अलग फ़ाइल है जिसे पुरानी प्रक्रिया ने नहीं खोला है।
स्केपरन

1
@Skaperen मैं मान रहा हूँ कि आप मेमोरी-मैप्ड फ़ाइलों के बारे में बात कर रहे हैं। पैकेज को अपग्रेड करते समय ये कोई समस्या नहीं हैं। सभी पैकेज प्रबंधक पुराने को बदलने के लिए उन्हें अधिलेखित करने के बजाय नई फाइलें बनाते हैं। वास्तव में ऐसा करने का एकमात्र तरीका यह है कि चल रहे निष्पादन योग्य को संशोधित नहीं किया जा सकता है, इसे केवल अनलिंक किया जा सकता है।
पैट्रिक

4

मान लीजिए कि "बी" को फाइल सिस्टम पर भी बदल दिया गया है। अब "ए" को किसी कारण से "बी" को फिर से पढ़ने की आवश्यकता है। सवाल यह है कि क्या यह संभव है कि "ए" "बी" का असंगत संस्करण ढूंढ सकता है और किसी अन्य तरीके से दुर्घटना या खराबी कर सकता है?

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

अच्छा कोडिंग अभ्यास इंटरफ़ेस को समान कार्य करता है। परिणामस्वरूप यह ज्यादा मायने नहीं रखता कि कौन सा संस्करण लोड किया गया है, इसके अलावा अगर नए संस्करण में बग्स तय किए गए थे।

कॉन्फ़िगरेशन फ़ाइलें थोड़ा अलग मामला है, लेकिन आमतौर पर स्टार्टअप के दौरान पढ़ा जाता है। इस मामले में, "ए" तब तक "बी" नहीं पढ़ेगा, जब तक कि कॉन्फ़िगरेशन का पुनः लोड नहीं किया जाता। फिर, कॉन्फ़िगरेशन फ़ाइल के प्रारूप या अर्थ को बदलने के लिए यह खराब कोडिंग अभ्यास होगा। कॉन्फ़िगरेशन फ़ाइल के असंगत संस्करण का एक अलग नाम होना चाहिए, इसलिए यह समस्या का कारण नहीं होगा।

लाइव सीडी या कुछ इसी तरह की प्रक्रिया के साथ रीबूट करके कोई भी अपने सिस्टम को अपडेट क्यों नहीं करता है?

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

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


0

कुछ ऐसे मामले हैं जहां यह एक समस्या है:

  • JDK अपग्रेड करते समय एक जावा-वीएम चल रहा है: मैंने myselv से वही सवाल पूछा जो आपको मिला - मेरे पास एक रनिंग टोमैट था जो जावा का उपयोग करता है। जेडीके के एक पैच-अपडेट के बाद अब भी यह बिना किसी समस्या के चला - तो ऐसा लग रहा था।

अब स्पष्टीकरण कैश-मेमोरी है। ठीक है - मैंने सभी उपलब्ध रैम का उपयोग करने के लिए एक मेमोरी-हॉग-प्रोग्राम शुरू किया - और फिर टॉमकैट दुर्घटनाग्रस्त हो गया (जब मैं वहां चल रहे ऐपटन तक पहुँचा)।

  • SuSE- सिस्टम पर कर्नेल-अपग्रेड: SuSE पर पुराने-कर्नेल और इसके मॉड्यूल कर्नेल के पैच-अपग्रेड के ठीक बाद डिलीट हो जाते हैं। यदि आप कुछ नया उपयोग करना चाहते हैं, तो इसके लिए कर्नेल-मॉड्यूल की आवश्यकता होती है, जो अब तक लोड नहीं किया गया था, सेवा विफल हो जाएगी।

2
टॉमकैट के कुछ टुकड़े (एस) की तरह लगता है, या जावा स्तर के नीचे गतिशील पुस्तकालयों का उपयोग किया गया (जैसे dlopen () और ऐसे) जो लाइव APIs के मिश्रण के साथ समाप्त हो सकते हैं।
स्कैपरन

साझा लाइब्रेरी का उपयोग करने पर भी @ शकरकंद - अगर वे किसी कार्यक्रम के उपयोग के बाद बंद हो जाते हैं तो परेशानी होनी चाहिए यदि कैश विरल हो रहा है ...
Nils

1
एक खुली फ़ाइल डिस्क्रिप्टर में डिस्क पर डेटा को एक निर्देशिका में फ़ाइल के रूप में बनाए रखने की समान शक्ति होती है। जब तक डिस्क या हार्ड फाइल डिस्क्रिप्टर पर हार्ड-लिंक नहीं होगा, तब तक मूल इनोड को डिलीट नहीं किया जाएगा । कैश का इससे कोई लेना-देना नहीं है। अब, कुछ कार्यक्रमों उनके फ़ाइल वर्णनकर्ता जब वे उनका उपयोग नहीं कर रहे बंद करने और है कि कर सकते हैं डेटा चले जाओ।
dmckee

@ मार्की राइट। हम कोर के पास हो रहे हैं। तो एक "सामान्य" कार्यक्रम के लिए क्या सामान्य है: पुस्तकालय खोलें और इसे खुला रखें, या पुस्तकालय को लोड करें और बाद में बंद करें?
नेल्स
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.