एक सॉफ्टवेयर पैकेज ठीक उसी तरह से क्यों चलता है, जब इसे अपग्रेड किया जा रहा हो?


29

कहते हैं कि मैं एक सॉफ्टवेयर चला रहा हूं, और फिर मैं सॉफ्टवेयर को अपग्रेड करने के लिए पैकेज मैनेजर चलाता हूं, मैं देखता हूं कि लिनक्स पैकेज अपग्रेड के लिए रनिंग प्रक्रिया को कम नहीं करता है - यह अभी भी ठीक चल रहा है। लिनक्स यह कैसे करता है?

जवाबों:


35

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

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


10
स्पष्ट करने के लिए, लिनक्स के तहत आप एक निष्पादन योग्य फ़ाइल को संशोधित नहीं कर सकते, जबकि यह चल रहा है। लेकिन आप फ़ाइल को अनलिंक कर सकते हैं और इसे उसी नाम की नई फ़ाइल से बदल सकते हैं।
cjm

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

4
@ जेलीग्रे जब तक मैं गलत नहीं समझ रहा हूँ, आप जहाँ तक मैं जानता हूँ, आप ऐसा नहीं कर सकते: sprunge.us/egiR
क्रिस डाउन

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

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

18

निष्पादनकर्ता आम तौर पर एक बार खोले जाते हैं, एक फाइल डिस्क्रिप्टर से जुड़े होते हैं, और निष्पादन के एक एकल अवधि के दौरान उनके बाइनरी को दोबारा खोलने के लिए एक फाइल डिस्क्रिप्टर नहीं होता है। उदाहरण के लिए, यदि आप निष्पादित करते हैं bash, तो exec()आम तौर पर केवल एक /bin/bashबार इनकोड के लिए एक फाइल डिस्क्रिप्टर बनाता है - इनवोकेशन पर।

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

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

सरल उपयोग के मामलों के लिए, हालांकि, प्रक्रिया को पुनरारंभ किए बिना अपग्रेड करना सुरक्षित है।


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

1
मुझे डर है कि आपका पहला पैराग्राफ गलत है। यूनिक्स / लिनक्स कर्नेल एक बार में निष्पादन योग्य कार्यक्रमों को लोड नहीं करते हैं, लेकिन मेमोरी उन्हें मैप करती है। इसका मतलब है कि केवल वास्तव में उपयोग किए जाने वाले पृष्ठ ही इसे रैम बनाते हैं। यह लिनक्स के तहत "टेक्स्ट फ़ाइल व्यस्त" सुरक्षा का पूरा बिंदु है। कोई गारंटी नहीं है कि एक निष्पादन योग्य का कुछ हिस्सा लॉन्च होने के बाद लंबे समय तक पढ़ा नहीं जाएगा। इसके अलावा कुछ पृष्ठ बड़े पर्याप्त कार्यक्रमों के लिए कभी भी लोड नहीं होंगे और यह गतिशील रूप से भरी हुई पुस्तकालयों के लिए और भी अधिक सच है। उदाहरण के लिए bashबाइनरी लगभग 200 4K पृष्ठ हैं, यह सुनिश्चित नहीं है कि वे सभी एक औसत सत्र में उपयोग किए जाते हैं।
१५:०५ पर jlliagre

@jlliagre मैं ialloc()पढ़ने पर एक कर्नेल संरचना के बारे में बात कर रहा था , न कि पृष्ठों की मेमोरी मैपिंग। क्या मैं यह सोचने में सही नहीं हूं कि आधुनिक एक्सट्रीम * फाइलसिस्टम पर, इनोड अंततः इन-कर्नेल (और वीएम सिस्टम के अंदर) के अनुरूप है?
क्रिस डाउन

निष्पादन योग्य सामग्री की कोई गारंटी नहीं है कि इसे चलाने के बाद लंबे समय तक पढ़ा नहीं जाएगा, और इसकी कोई गारंटी भी नहीं है कि निष्पादन समय के दौरान कुछ समय बाद फिर से वही पृष्ठ नहीं पढ़े जाएंगे।
जूलियाग्रे

@jlliagre राइट, लेकिन मेरा मतलब यह नहीं है। शायद मैंने अपने जवाब में अपने शब्दों को थोड़ा सा छोटा कर दिया, मैं यह स्पष्ट करने का प्रयास करूंगा कि मेरा क्या मतलब था।
क्रिस डाउन
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.