Erlang 21

release_handler




erlang

release_handler

मॉड्यूल

release_handler

मॉड्यूल सारांश

अनपैकिंग और रिलीज़ पैकेज की स्थापना

विवरण

रिलीज़ हैंडलर प्रक्रिया एसएएसएल एप्लिकेशन से संबंधित है, जो रिलीज़ हैंडलिंग , यानी अनपैकिंग, इंस्टॉलेशन और रिलीज़ पैकेज को हटाने के लिए ज़िम्मेदार है।

सिस्टम डॉक्यूमेंटेशन में OTP Design Principles में हैंडलिंग और एक उदाहरण जारी करने का परिचय दिया गया है।

एक रिलीज़ पैकेज एक संपीड़ित टार फ़ाइल है जिसमें एक रिलीज़ के एक निश्चित संस्करण के लिए कोड होता है, जिसे systools:make_tar/1,2 कहकर बनाया जाता है। रिलीज़ पैकेज रिलीज़ के पिछले संस्करण के $ROOT/releases डायरेक्टरी में स्थित होना है, जहाँ $ROOT इंस्टॉलेशन रूट डायरेक्टरी, code:root_dir() RELDIR कॉन्फ़िगरेशन पैरामीटर RELDIR या ओएस पर्यावरण चर RELDIR का उपयोग करके एक और releases निर्देशिका निर्दिष्ट की जा सकती है। नई रिलीज़ को स्थापित करने के लिए रिलीज़ हैंडलर को इस निर्देशिका तक पहुँच लिखना होगा। रिलीज़ हैंडलर की लगातार स्थिति वहाँ एक फ़ाइल में संग्रहीत की जाती है जिसे RELEASES कहा जाता है।

एक रिलीज पैकेज में हमेशा शामिल होता है:

  • एक रिलीज़ संसाधन फ़ाइल, Name.rel
  • एक बूट स्क्रिप्ट, Name.boot

.rel फ़ाइल में रिलीज़ के बारे में जानकारी होती है: इसका नाम, संस्करण और कौन सा ERTS और अनुप्रयोग संस्करण इसका उपयोग करता है।

एक रिलीज़ पैकेज भी हो सकता है:

  • एक रिलीज के उन्नयन फ़ाइल, relup
  • एक सिस्टम कॉन्फ़िगरेशन फ़ाइल, sys.config
  • एक सिस्टम कॉन्फ़िगरेशन स्रोत फ़ाइल, sys.config.src

relup फ़ाइल में रिलीज़ के इस संस्करण में अपग्रेड या डाउनग्रेड करने के तरीके के निर्देश हैं।

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

प्रत्येक रिलीज़ संस्करण की एक स्थिति होती है, जिसे unpacked किया जा सकता है, current , permanent या old । हमेशा एक नवीनतम रिलीज होती है, जिसमें या तो स्थिति permanent (सामान्य मामला) या current (स्थापित, लेकिन अभी तक स्थायी नहीं होती है)। निम्न तालिका में स्थिति मूल्यों का अर्थ चित्रित किया गया है:

Status     Action                NextStatus
-------------------------------------------
-          unpack                unpacked
unpacked   install               current
           remove                -
current    make_permanent        permanent
           install other         old
           remove                -
permanent  make other permanent  old
           install               permanent
old        reboot_old            permanent
           install               current
           remove                -

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

रिलीज़ हैंडलिंग को ठीक से काम करने के लिए, रनटाइम सिस्टम को पता होना चाहिए कि यह किस रिलीज़ पर चल रहा है। यह भी बदलने में सक्षम होना चाहिए (रनटाइम में) जो बूट स्क्रिप्ट और सिस्टम कॉन्फ़िगरेशन फ़ाइल का उपयोग किया जाता है अगर सिस्टम को पुनरारंभ किया जाता है। यदि एर्लांग को एक एम्बेडेड सिस्टम के रूप में शुरू किया गया है, तो यह स्वचालित रूप से ध्यान रखा जाता है। सिस्टम प्रलेखन में Embedded System में इसके बारे में पढ़ें। इस स्थिति में, सिस्टम कॉन्फ़िगरेशन फ़ाइल sys.config अनिवार्य है।

नई रिलीज़ की स्थापना सिस्टम को पुनरारंभ कर सकती है। start_prg कॉन्फ़िगरेशन पैरामीटर start_prg द्वारा कौन से प्रोग्राम का उपयोग करना है, जो $ROOT/bin/start लिए डिफ़ॉल्ट है।

Windows NT पर एमुलेटर रीस्टार्ट यह उम्मीद करता है कि सिस्टम erlsrv प्रोग्राम (एक सेवा के रूप में) का उपयोग करके शुरू किया गया है। इसके अलावा, रिलीज़ हैंडलर को उम्मीद है कि इस सेवा का नाम NodeName _ Release , जहां NodeName Erlang नोड नाम (अप करने के लिए, लेकिन "@" सहित शामिल नहीं है) का पहला भाग है और Release वर्तमान रिलीज़ संस्करण है। रिलीज हैंडलर को उम्मीद है कि start_erl.exe जैसा एक कार्यक्रम start_erl.exe को "मशीन" के रूप में निर्दिष्ट किया गया है। पुनरारंभ के साथ उन्नयन के दौरान, एक नई सेवा पंजीकृत और शुरू की जाती है। नई सेवा को स्वचालित पर सेट किया जाता है और नई रिलीज को स्थायी बनाने पर पुरानी सेवा को हटा दिया जाता है।

डिस्क हैंडलर पर चल रहे नोड पर रिलीज़ हैंडलर, या केवल-पढ़ने के लिए फ़ाइल सिस्टम के साथ, निम्नलिखित एसएएसएल कॉन्फ़िगरेशन पैरामीटर (विवरण के लिए, sasl(6) ) का उपयोग करके तदनुसार कॉन्फ़िगर किया जाना चाहिए:

masters

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

client_directory

मास्टर नोड्स की निर्देशिका संरचना में client_directory निर्दिष्ट किया जाना चाहिए।

static_emulator

यह पैरामीटर निर्दिष्ट करता है कि क्या Erlang एम्यूलेटर सांख्यिकीय रूप से क्लाइंट नोड पर स्थापित है। एक स्थिर इम्यूलेटर वाला नोड गतिशील रूप से एक नए एमुलेटर पर स्विच नहीं कर सकता है, क्योंकि निष्पादन योग्य फ़ाइलों को सांख्यिकीय रूप से मेमोरी में लिखा जाता है।

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

ओटीपी में परिभाषित संरचना की तुलना में किसी अन्य फ़ाइल संरचना का उपयोग करने के लिए कार्य प्रदान किए जाते हैं। इन कार्यों का उपयोग स्थानीय रूप से रिलीज़ अपग्रेड का परीक्षण करने के लिए किया जा सकता है।

निर्यात

check_install_release (Vsn) -> {ok, OtherVsn, Descr} | {त्रुटि, कारण}
check_install_release (Vsn, Opts) -> {ok, OtherVsn, Descr} | {त्रुटि, कारण}

प्रकार

जाँचता है कि क्या Vsn का निर्दिष्ट संस्करण Vsn स्थापित किया जा सकता है। रिलीज में स्टेटस current नहीं होना चाहिए। यदि फ़ाइल या sys.config जारी नहीं है, तो चेतावनी जारी sys.config है। यदि relup फ़ाइल मौजूद है, तो इसकी सामग्री की जाँच की जाती है और यदि कोई त्रुटि पाई जाती है, तो उसका {error,Reason} बनता है। यह भी जांचता है कि सभी आवश्यक एप्लिकेशन मौजूद हैं और सभी नए कोड लोड किए जा सकते हैं; {error,Reason} यदि कोई त्रुटि पाई जाती है तो वापस कर दी जाती है।

रिलीज़ अपग्रेड स्क्रिप्ट में point_of_no_return निर्देश से पहले होने वाले सभी निर्देशों का मूल्यांकन करता है।

install_release/1 के समान रिटर्न देता है। यदि कोई relup फ़ाइल नहीं relup तो relup "" को डिफॉल्ट करता है।

यदि विकल्प purge निर्दिष्ट किया जाता है, तो सभी पुराने कोड जो नरम-शुद्ध किए जा सकते हैं, उन्हें अन्य सभी चेक सफलतापूर्वक पूरा होने के बाद शुद्ध किया जाता है। यह install_release/1 द्वारा आवश्यक समय को कम करने के लिए उपयोगी हो सकता है।

create_RELEASES (रूट, RelDir, RelFile, AppDirs) -> ठीक | {त्रुटि, कारण}

प्रकार

एक प्रारंभिक RELEASES फ़ाइल बनाता है जिसका उपयोग रिलीज़ हैंडलर द्वारा किया जाता है। नई रिलीज़ स्थापित करने के लिए यह फ़ाइल मौजूद होनी चाहिए।

Root इंस्टॉलेशन ( $ROOT ) की $ROOT जैसा कि पहले बताया गया है। RelDir वह निर्देशिका है जहाँ RelDir फ़ाइल बनाई जानी है (सामान्यतः $ROOT/releases )। RelFile .rel फ़ाइल का नाम है जो एक्सटेंशन .rel सहित प्रारंभिक रिलीज़ का वर्णन करता है।

AppDirs का उपयोग निर्दिष्ट करने के लिए किया जा सकता है जहां से निर्दिष्ट अनुप्रयोगों के लिए मॉड्यूल लोड किए जाने हैं। App एक App का नाम है, Vsn संस्करण है, और Dir उस निर्देशिका का नाम है जहां App-Vsn स्थित है। इसी मॉड्यूल को Dir/App-Vsn/ebin अंतर्गत स्थित किया जाना है। AppDirs में निर्दिष्ट नहीं अनुप्रयोगों के लिए निर्देशिका $ROOT/lib AppDirs में स्थित माना जाता है।

install_file (Vsn, फ़ाइल) -> ठीक | {त्रुटि, कारण}

प्रकार

रिलीज़ संरचना में रिलीज़-निर्भर फ़ाइल स्थापित करता है। रिलीज़-निर्भर फ़ाइल रिलीज़ संरचना में होनी चाहिए जब एक नया रिलीज़ स्थापित किया गया हो: start.boot , relup , और sys.config

फ़ंक्शन को कहा जा सकता है, उदाहरण के लिए, जब ये फाइलें लक्ष्य पर उत्पन्न होती हैं। इस समारोह को set_unpacked/2 बाद बुलाया जाना है।

install_release (Vsn) -> {ok, OtherVsn, Descr} | {त्रुटि, कारण}
install_release (Vsn, [Opt]] -> {ok, OtherVsn, Descr} | {Continue_after_restart, OtherVsn, Descr} | {त्रुटि, कारण}

प्रकार

रिलीज़ का निर्दिष्ट संस्करण Vsn स्थापित करता है। वर्तमान संस्करण से अपग्रेड के लिए Vsn और एक स्क्रिप्ट के लिए पहले इस फ़ाइल में एक स्क्रिप्ट {UpFromVsn,Descr1,Instructions1} लिए लगता है। यदि नहीं मिला है, तो फ़ंक्शन वर्तमान संस्करण के लिए एक relup फ़ाइल और एक स्क्रिप्ट के लिए दिखता है {Vsn,Descr2,Instructions2} इस फाइल में Vsn लिए डाउनग्रेड करने के लिए।

यदि कोई स्क्रिप्ट मिलती है, तो पहली बात यह है कि एप्लिकेशन विनिर्देशों को .app फ़ाइलों और sys.config अनुसार रिलीज़ संस्करण Vsn अनुसार अपडेट किया जाता है।

एप्लिकेशन के विनिर्देशों को अद्यतन किए जाने के बाद, स्क्रिप्ट में दिए गए निर्देशों का मूल्यांकन किया जाता है और फ़ंक्शन सफल होने पर {ok,OtherVsn,Descr} रिटर्न करता है। OtherVsn और OtherVsn संस्करण हैं (स्क्रिप्ट में निर्दिष्ट के रूप में UpFromVsn या Vsn ) और विवरण ( Descr1 या Descr2 )।

यदि {continue_after_restart,OtherVsn,Descr} वापस कर दिया जाता है, तो नवीनीकरण निर्देशों को निष्पादित करने से पहले एमुलेटर को पुनरारंभ किया जाता है। यह तब होता है जब एमुलेटर या किसी भी अनुप्रयोग कर्नेल, STDLIB या SASL को अपडेट किया जाता है। नया एमुलेटर संस्करण और ये मुख्य अनुप्रयोग पुनरारंभ होने के बाद निष्पादित होते हैं। अन्य सभी अनुप्रयोगों के लिए पुराने संस्करण शुरू किए गए हैं और अपग्रेड निर्देशों को निष्पादित करके अपग्रेड सामान्य रूप से किया जाता है।

यदि कोई पुनर्प्राप्त करने योग्य त्रुटि होती है, तो फ़ंक्शन {error,Reason} और मूल एप्लिकेशन विनिर्देश बहाल हो जाते हैं। यदि कोई गैर-पुनर्प्राप्ति योग्य त्रुटि होती है, तो सिस्टम को पुनरारंभ किया जाता है।

विकल्प :

error_action

परिभाषित करता है कि यदि नोड को फिर से शुरू किया जाना है (अगर init:restart() ) या रिबूट ( init:reboot() ) यदि स्थापना के दौरान कोई त्रुटि है। डिफ़ॉल्ट restart

code_change_timeout

सभी कॉल के लिए sys:change_code के टाइम-आउट को परिभाषित करता है। यदि कोई मान निर्दिष्ट नहीं है या default निर्दिष्ट है, तो sys में निर्धारित डिफ़ॉल्ट मान का उपयोग किया जाता है।

suspend_timeout

सभी कॉल के लिए sys:suspend लिए टाइम-आउट को परिभाषित करता है sys:suspend । यदि कोई मान निर्दिष्ट नहीं किया गया है, तो upgrade या suspend निर्देशों के Timeout पैरामीटर द्वारा परिभाषित मूल्यों का उपयोग किया जाता है। यदि default निर्दिष्ट किया गया है, तो sys में परिभाषित डिफ़ॉल्ट मान का उपयोग किया जाता है।

{update_paths,Bool}

इंगित करता है कि यदि सभी एप्लिकेशन कोड पथ अपडेट किए जाने हैं ( Bool==true ) या यदि संशोधित अनुप्रयोगों के लिए केवल कोड पथ अपडेट किए जाने हैं ( Bool==false , डिफ़ॉल्ट)। इस विकल्प का डिफ़ॉल्ट $ROOT/lib/App-Vsn तुलना में अन्य एप्लिकेशन निर्देशिकाओं के लिए केवल प्रभाव है, अर्थात, एप्लिकेशन निर्देशिकाओं में निर्दिष्ट AppDirs में कॉल करने के create_RELEASES/4 या set_unpacked/2

उदाहरण:

किसी रिलीज़ के वर्तमान संस्करण CurVsn में, myapp की एप्लिकेशन डायरेक्टरी $ROOT/lib/myapp-1.0 । एक नया संस्करण NewVsn रिलीज़ हैंडलर के बाहर NewVsn है और रिलीज़ हैंडलर को इसके बारे में एक कॉल के साथ सूचित किया जाता है:

release_handler:set_unpacked(RelFile, [{myapp,"1.0","/home/user"},...]).
=> {ok,NewVsn}

यदि NewVsn को विकल्प {update_paths,true} साथ स्थापित किया गया है, तो code:lib_dir(myapp) रिटर्न code:lib_dir(myapp)

ध्यान दें

यदि सिस्टम में कई प्रक्रियाएँ हैं, तो नई रिलीज़ को स्थापित करने में समय लग सकता है। कारण यह है कि मॉड्यूल को शुद्ध करने से पहले पुराने कोड के संदर्भ के लिए प्रत्येक प्रक्रिया की जांच की जानी चाहिए। इस चेक से कचरा संग्रहण और डेटा की नकल हो सकती है।

check_install_release के निष्पादन को गति देने के लिए, पहले विकल्प purge का उपयोग करके check_install_release कॉल करें। यह पुराने कोड के लिए समान जांच करता है। फिर सभी मॉड्यूल को शुद्ध करता है जो नरम-शुद्ध हो सकते हैं। शुद्ध किए गए मॉड्यूल का अब कोई पुराना कोड नहीं है, और install_release/1 को चेक करने की आवश्यकता नहीं है।

यह अपग्रेड के लिए समग्र समय को कम नहीं करता है, लेकिन यह वास्तविक उन्नयन शुरू होने से पहले चेक और पर्ज को पृष्ठभूमि में निष्पादित करने की अनुमति देता है।

ध्यान दें

OTP R15 से पुराने संस्करण से एमुलेटर को अपग्रेड करते समय, नए एप्लिकेशन बीम कोड को पुराने एमुलेटर में लोड करने का प्रयास किया जाता है। कभी-कभी नए बीम प्रारूप को पुराने एमुलेटर द्वारा नहीं पढ़ा जा सकता है, इसलिए कोड लोडिंग विफल हो जाती है और पूर्ण उन्नयन समाप्त हो जाता है। इस समस्या को दूर करने के लिए, नए एप्लिकेशन कोड को पुराने एमुलेटर के साथ संकलित किया जाना है। पूर्व OTP R15 संस्करणों से एमुलेटर अपग्रेड के बारे में अधिक जानकारी के लिए, सिस्टम प्रलेखन में Design Principles देखें।

make_permanent (Vsn) -> ठीक | {त्रुटि, कारण}

प्रकार

निर्दिष्ट रिलीज़ संस्करण Vsn स्थायी बनाता है।

remove_release (Vsn) -> ठीक है | {त्रुटि, कारण}

प्रकार

सिस्टम से एक रिलीज़ और उसकी फ़ाइलें निकालता है। रिलीज स्थायी रिलीज नहीं होनी चाहिए। केवल फ़ाइलों और निर्देशिकाओं को किसी अन्य रिलीज़ द्वारा उपयोग में नहीं निकालता है।

reboot_old_release (Vsn) -> ठीक | {त्रुटि, कारण}

प्रकार

पुरानी रिलीज़ को स्थायी बनाकर सिस्टम को init:reboot() करता है, और init:reboot() कॉल करता है init:reboot() सीधे। रिलीज की स्थिति old होनी चाहिए।

set_removed (Vsn) -> ठीक है | {त्रुटि, कारण}

प्रकार

रिलीज हैंडलर के बाहर रिलीज को हटाने के लिए संभव बनाता है। रिलीज हैंडलर को बताता है कि रिलीज सिस्टम से हटा दिया गया है। यह फ़ंक्शन किसी भी फाइल को डिलीट नहीं करता है।

set_unpacked (RelFile, AppDirs) -> {ठीक है, Vsn} | {त्रुटि, कारण}

प्रकार

रिलीज हैंडलर के बाहर रिलीज के अनपैकिंग को संभालना संभव बनाता है। रिलीज हैंडलर को बताता है कि रिलीज अनपैक्ड है। Vsn को रिलीज़ रिसोर्स फ़ाइल RelFile से निकाला जाता है।

AppDirs का उपयोग निर्दिष्ट करने के लिए किया जा सकता है जहां से निर्दिष्ट अनुप्रयोगों के लिए मॉड्यूल लोड किए जाने हैं। App एक App का नाम है, Vsn संस्करण है, और Dir उस निर्देशिका का नाम है जहां App-Vsn स्थित है। इसी मॉड्यूल को Dir/App-Vsn/ebin अंतर्गत स्थित किया जाना है। AppDirs में निर्दिष्ट नहीं अनुप्रयोगों के लिए निर्देशिका $ROOT/lib AppDirs में स्थित माना जाता है।

unpack_release (नाम) -> {ठीक है, Vsn} | {त्रुटि, कारण}

प्रकार

releases निर्देशिका में स्थित रिलीज़ पैकेज Name.tar.gz releases

उदाहरण के लिए, पैकेज पर कुछ जाँच करता है, जाँच करता है कि सभी अनिवार्य फाइलें मौजूद हैं, और इसकी सामग्री को निकालता है।

कौन से_रेल () -> [{नाम, बनाम, ऐप्स, स्थिति}]

प्रकार

रिलीज़ हैंडलर को ज्ञात सभी रिलीज़ लौटाता है।

जो_रेलिस (स्थिति) -> [{नाम, बनाम, ऐप्स, स्थिति}]

प्रकार

किसी विशेष स्थिति के रिलीज़ हैंडलर को ज्ञात सभी रिलीज़ लौटाता है।

आवेदन अपग्रेड / डाउनग्रेड

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

चेतावनी

ये कार्य मुख्य रूप से .appup फ़ाइलों के सरलीकृत परीक्षण के लिए अभिप्रेत हैं। उन्हें release_handler प्रक्रिया के संदर्भ में नहीं चलाया जाता है। इसलिए उन्हें install_release/1 कॉल के साथ एक साथ उपयोग नहीं किया जाना चाहिए, क्योंकि इससे release_handler असंगत स्थिति में समाप्त हो जाता है।

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

यदि अपग्रेड या डाउनग्रेड विफल हो जाता है, तो एप्लिकेशन असंगत स्थिति में समाप्त हो सकता है।

निर्यात

अपग्रेड_ऐप (ऐप, डेयर) -> {ठीक है, अनरजिस्टर्ड} | restart_emulator | {त्रुटि, कारण}

प्रकार

वर्तमान App से एक App को .appup करता है। जो कि .appup फ़ाइल के अनुसार Dir में स्थित एक नए संस्करण में है।

App का नाम है, जिसे शुरू किया जाना चाहिए। Dir App की नई लाइब्रेरी डायरेक्टरी है। इसी मॉड्यूल के साथ ही .app और .appup फाइलें Dir/ebin अंतर्गत स्थित Dir/ebin

फ़ंक्शन .appup फ़ाइल को .appup है और .appup upgrade_script/2 का उपयोग करके एप्लिकेशन के वर्तमान संस्करण से अपग्रेड स्क्रिप्ट खोजने का प्रयास करता है। इस स्क्रिप्ट का मूल्यांकन eval_appup_script/4 का उपयोग करके किया गया है, ठीक उसी तरह जैसे कि install_release/1 करता है।

निम्न में से एक लौटाता है:

  • {ok, Unpurged} यदि स्क्रिप्ट का मूल्यांकन करना सफल है, जहां Unpurged अनरजिस्टर्ड मॉड्यूल की सूची है
  • यदि यह निर्देश स्क्रिप्ट में है, तो restart_emulator करें
  • {error, Reason} यदि स्क्रिप्ट को खोजने या उसका मूल्यांकन करने में कोई त्रुटि हुई

यदि restart_new_emulator निर्देश स्क्रिप्ट में पाया जाता है {error,restart_new_emulator} upgrade_app/2 रिटर्न {error,restart_new_emulator} । ऐसा इसलिए है क्योंकि restart_new_emulator को नवीनीकरण के बाकी निर्देशों को निष्पादित करने से पहले एमुलेटर के एक नए संस्करण की आवश्यकता होती है, और यह केवल install_release/1 द्वारा किया जा सकता है।

downgrad_app (App, Dir) ->
downgrad_app (App, OldVsn, Dir) -> {ठीक है, अनजाने} | restart_emulator | {त्रुटि, कारण}

प्रकार

.appup फ़ाइल के अनुसार Dir में स्थित पिछले संस्करण OldVsn के वर्तमान संस्करण से एक App को डाउनग्रेड करता है।

App का नाम है, जिसे शुरू किया जाना चाहिए। OldVsn पिछला अनुप्रयोग संस्करण है और छोड़ दिया जा सकता है यदि Dir "App-OldVsn" प्रारूप का है। Dir App के पिछले संस्करण की लाइब्रेरी डायरेक्टरी है। संबंधित मॉड्यूल और पुरानी .app फ़ाइल को Dir/ebin अंतर्गत स्थित किया जाना है। .appup फ़ाइल को अनुप्रयोग की वर्तमान लाइब्रेरी निर्देशिका ( code:lib_dir(App) ) की ebin निर्देशिका में स्थित किया जाना है।

फ़ंक्शन .appup फ़ाइल को .appup है और downgrade_script/3 का उपयोग करके एप्लिकेशन के पिछले संस्करण में एक डाउनग्रेड स्क्रिप्ट खोजने का प्रयास करता है। इस स्क्रिप्ट का मूल्यांकन eval_appup_script/4 का उपयोग करके किया गया है, ठीक उसी तरह जैसे कि install_release/1 करता है।

निम्न में से एक लौटाता है:

  • {ok, Unpurged} यदि स्क्रिप्ट का मूल्यांकन करना सफल है, जहां Unpurged अनरजिस्टर्ड मॉड्यूल की सूची है
  • यदि यह निर्देश स्क्रिप्ट में है, तो restart_emulator करें
  • {error, Reason} यदि स्क्रिप्ट को खोजने या उसका मूल्यांकन करने में कोई त्रुटि हुई
अपग्रेड_स्क्रिप्ट (App, Dir) -> {ठीक है, NewVsn, स्क्रिप्ट}

प्रकार

वर्तमान संस्करण से App लिए App अपग्रेड स्क्रिप्ट को खोजने के लिए कोशिश करता है कि वह Dir में स्थित एक नए संस्करण में आए।

अपग्रेड स्क्रिप्ट का मूल्यांकन eval_appup_script/4 का उपयोग करके किया जा सकता है। इसके बजाय upgrade_app/2 का उपयोग करने की अनुशंसा की जाती है, लेकिन यह फ़ंक्शन ( upgrade_script ) स्क्रिप्ट की सामग्री का निरीक्षण करने के लिए उपयोगी है।

App का नाम है, जिसे शुरू किया जाना चाहिए। Dir App की नई लाइब्रेरी डायरेक्टरी है। इसी मॉड्यूल के साथ ही .app और .appup फाइलें Dir/ebin अंतर्गत स्थित Dir/ebin

फ़ंक्शन .appup फ़ाइल में दिखता है और वर्तमान एप्लिकेशन संस्करण से अपग्रेड स्क्रिप्ट खोजने का प्रयास करता है। उच्च-स्तरीय निर्देशों का निम्न-स्तरीय निर्देशों में अनुवाद किया जाता है। relup फ़ाइल जनरेट करते समय निर्देशों को उसी तरीके से सॉर्ट किया जाता है।

रिटर्न {ok, NewVsn, Script} यदि सफल है, जहां NewVsn नया एप्लिकेशन संस्करण है। Script बारे में जानकारी के लिए, appup(4)

विफलता: यदि कोई स्क्रिप्ट नहीं मिल सकती है, तो फ़ंक्शन एक उपयुक्त त्रुटि कारण के साथ विफल हो जाता है।

डाउनग्रेड_स्क्रिप्ट (ऐप, ओल्डव्सन, डर) -> {ठीक है, स्क्रिप्ट}

प्रकार

वर्तमान संस्करण से App लिए एक एप्लिकेशन डाउनग्रेड स्क्रिप्ट खोजने की कोशिश करता है जो कि OldVsn स्थित एक पुराने संस्करण OldVsn है।

फिर डाउनग्रेड स्क्रिप्ट का मूल्यांकन eval_appup_script/4 का उपयोग करके किया जा सकता है। इसके बजाय downgrade_app/2,3 का उपयोग करने की अनुशंसा की जाती है, लेकिन यह फ़ंक्शन ( downgrade_script ) स्क्रिप्ट की सामग्री का निरीक्षण करने के लिए उपयोगी है।

App का नाम है, जिसे शुरू किया जाना चाहिए। Dir App की पिछली लाइब्रेरी डायरेक्टरी है। संबंधित मॉड्यूल और पुरानी .app फ़ाइल को Dir/ebin अंतर्गत स्थित किया जाना है। .appup फ़ाइल को अनुप्रयोग की वर्तमान लाइब्रेरी निर्देशिका ( code:lib_dir(App) ) की ebin निर्देशिका में स्थित किया जाना है।

फ़ंक्शन .appup फ़ाइल में दिखता है और वर्तमान एप्लिकेशन संस्करण से डाउनग्रेड स्क्रिप्ट खोजने का प्रयास करता है। उच्च-स्तरीय निर्देशों का निम्न-स्तरीय निर्देशों में अनुवाद किया जाता है। relup फ़ाइल जनरेट करते समय निर्देशों को उसी तरीके से सॉर्ट किया जाता है।

सफल होने पर {ok, Script} लौटाता है। Script बारे में जानकारी के लिए, appup(4)

विफलता: यदि कोई स्क्रिप्ट नहीं मिल सकती है, तो फ़ंक्शन एक उपयुक्त त्रुटि कारण के साथ विफल हो जाता है।

eval_appup_script (App, ToVsn, ToDir, Script) -> {ठीक है, अनजाने} | restart_emulator | {त्रुटि, कारण}

प्रकार

upgrade_script/2 , downgrade_script/3

एक एप्लिकेशन अपग्रेड या डाउनग्रेड स्क्रिप्ट Script मूल्यांकन करता है, जो कॉल upgrade_script/2 या downgrade_script/3 से कॉल करता है, बिल्कुल उसी तरह जैसे कि install_release/1 करता है।

App का नाम है, जिसे शुरू किया जाना चाहिए। ToVsn को उन्नत / डाउनग्रेड किया जाने वाला संस्करण है और ToDir इस संस्करण की लाइब्रेरी निर्देशिका है। इसी मॉड्यूल के साथ ही .app और .appup फाइलें Dir/ebin अंतर्गत स्थित Dir/ebin

निम्न में से एक लौटाता है:

  • {ok, Unpurged} यदि स्क्रिप्ट का मूल्यांकन करना सफल है, जहां Unpurged अनरजिस्टर्ड मॉड्यूल की सूची है
  • यदि यह निर्देश स्क्रिप्ट में है, तो restart_emulator करें
  • {error, Reason} यदि स्क्रिप्ट को खोजने या उसका मूल्यांकन करने में कोई त्रुटि हुई

यदि restart_new_emulator निर्देश स्क्रिप्ट में पाया जाता है, तो eval_appup_script/4 रिटर्न {error,restart_new_emulator} । ऐसा इसलिए है क्योंकि restart_new_emulator को नवीनीकरण के बाकी निर्देशों को निष्पादित करने से पहले एमुलेटर के एक नए संस्करण की आवश्यकता होती है, और यह केवल install_release/1 द्वारा किया जा सकता है।

विशिष्ट त्रुटि कारण

{bad_masters, Masters}

मास्टर नोड्स Masters जीवित नहीं हैं।

{bad_rel_file, File}

निर्दिष्ट .rel फ़ाइल File को पढ़ा नहीं जा सकता है या इसमें एक भी शब्द नहीं है।

{bad_rel_data, Data}

निर्दिष्ट .rel फ़ाइल में एक मान्यताप्राप्त रिलीज़ विनिर्देश नहीं है, लेकिन एक और शब्द Data

{bad_relup_file, File}

निर्दिष्ट relup फ़ाइल Relup में खराब डेटा है।

{cannot_extract_file, Name, Reason}

टार फ़ाइल से निकालने पर समस्याएँ, erl_tar:extract/2 लौटे {error, {Name, Reason}}

{existing_release, Vsn}

निर्दिष्ट रिलीज़ संस्करण Vsn पहले से ही उपयोग में है।

{Master, Reason, When}

कुछ ऑपरेशन, When शब्द से संकेत मिलता है, निर्दिष्ट त्रुटि कारण Reason साथ मास्टर नोड Master पर विफल रहा है।

{no_matching_relup, Vsn, CurrentVsn}

CurrentVsn और Vsn बीच उन्नयन / डाउनग्रेडिंग के लिए कोई स्क्रिप्ट नहीं मिल सकती है।

{no_such_directory, Path}

निर्देशिका Path मौजूद नहीं है।

{no_such_file, Path}

पथ Path (फ़ाइल या निर्देशिका) मौजूद नहीं है।

{no_such_file, {Master, Path}}

पथ नोड (फ़ाइल या निर्देशिका) मास्टर नोड Master में मौजूद नहीं है।

{no_such_release, Vsn}

निर्दिष्ट रिलीज़ संस्करण Vsn मौजूद नहीं है।

{not_a_directory, Path}

Path मौजूद है, लेकिन निर्देशिका नहीं है।

{Posix, File}

फ़ाइल के लिए कुछ फ़ाइल कार्रवाई विफल रही। Posix एक एटम है जिसे enoent एरर कोड्स से नाम दिया गया है, जैसे कि enoent , eacces या eisdir । कर्नेल में file(3) देखें।

Posix

सूची में पिछले आइटम के लिए कुछ फ़ाइल कार्रवाई विफल रही।

यह भी देखें

OTP Design Principles , config(4) , rel(4) , relup(4) , script(4) sys(3) , systools(3) , systools(3)