लिनक्स में पर्यावरण चर को कैसे डीबग करें

अक्सर ऐसा होता है कि आप मशीन पर आते हैं और एक सप्ताह पहले सिस्टम उपयोगकर्ता के तहत किसी प्रकार की स्क्रिप्ट चला रहे हैं। इसे किसने लॉन्च किया? इस run.php के लिए कहां देखें? या आप / etc / crontab में एक प्रविष्टि जोड़ते हैं, और स्क्रिप्ट वहां "कमांड नहीं मिला" त्रुटि के साथ क्रैश हो जाती है। क्यों? और क्या करना है?

मेरे पास इन सवालों के जवाब हैं।

पर्यावरण चर

लगभग सभी आधुनिक ऑपरेटिंग सिस्टम में, प्रक्रियाओं में पर्यावरण चर होते हैं। तकनीकी रूप से, वे नामित तारों का एक संग्रह हैं। यदि एक उपप्रकार शुरू किया जाता है, तो यह स्वचालित रूप से माता-पिता के वातावरण की एक प्रति विरासत में मिलती है।

दूसरों के बीच, PATH वैरिएबल है, जो निष्पादन योग्य फ़ाइलों की खोज के लिए रास्तों को इंगित करता है, HOME वैरिएबल, जो उपयोगकर्ता के होम डाइरेक्टरी को इंगित करता है, वे वैरिएबल जो उपयोगकर्ता की भाषा वरीयताओं के लिए जिम्मेदार हैं, और कई अन्य।

इन चरों के अर्थ का वर्णन करने वाली कई समीक्षाएं हैं, लेकिन समस्याओं की जांच कैसे की जाए, इस पर व्यावहारिक रूप से कोई लेख नहीं है। इस अंतर को भरें।

प्रक्रिया किसने शुरू की?

इसलिए, हमें एक सप्ताह पहले सिस्टम उपयोगकर्ता के तहत एक स्क्रिप्ट मिली। इसे किसने लॉन्च किया? क्यों? शायद वे उसके बारे में भूल गए? संभावित रूप से 10-15 लोग इसे लॉन्च कर सकते हैं, आपने सभी का साक्षात्कार नहीं लिया है। कैसे पता करें कि यह कौन था? और यह कहाँ चलता है।

$ ps x | grep run.php 10684 ? Ss 472:25 /local/php/bin/php run.php 

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

किसी भी चल रही प्रक्रिया के लिए पर्यावरण चर (और बहुत कुछ) / खरीद में पाया जा सकता है। देखा:

 $ cat /proc/10684/environ | tr '\0' '\n' | grep SUDO_USER SUDO_USER=alexxz $ cat /proc/10684/environ | tr '\0' '\n' | grep PWD PWD=/home/etlmaster 

अहम, मैंने इसे खुद लॉन्च किया। खैर, कौन नहीं होता है?

सामान्य तौर पर, सरल स्थितियों में इस तरह की एक सरल विधि का उपयोग करके, आप प्रक्रिया के बारे में जानकारी पा सकते हैं, जो आमतौर पर उपलब्ध नहीं है।

स्क्रिप्ट कमांड लाइन से काम करती है, लेकिन क्रोन से काम नहीं करती है

ऐसे मामलों में से एक जब आपको पर्यावरण चर के बारे में सोचना पड़ता है, जब एक स्क्रिप्ट को / etc / crontab में जोड़ा जाता है एक त्रुटि के साथ। आप एसएसएच के माध्यम से सर्वर पर जाते हैं, कमांड चलाते हैं, सब कुछ काम करता है जैसा कि यह होना चाहिए। और जब यह स्वचालित रूप से शुरू होता है, तो यह "हाइव: कमांड नहीं मिला" जैसे कुछ दिखाता है।

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

इस तरह के जोड़तोड़ के बाद, एक असली इंजीनियर की आत्मा में एक तलछट बनी हुई है। हाँ, समस्या हल हो गई है। लेकिन मुझे समझ नहीं आया कि क्या चल रहा था! एक दृष्टिकोण दूसरे की तुलना में बेहतर कैसे है? इन सभी सेटिंग्स को कहाँ संग्रहीत किया जाता है और किसके द्वारा इन्हें बदला जाता है?

आइए पर्यावरण वेरिएबल्स की तुलना करें जो कि प्रक्रिया है जब इसे मुकुट से लॉन्च किया जाता है और पर्यावरण चर जो हमारे पास कमांड लाइन पर है। हम ताज और हमारे वर्तमान वातावरण से env कमांड के आउटपुट को लॉग करते हैं:

 $ echo "* * * * * env > ~/crontab.env" | crontab; sleep 60; echo "" | crontab; $ env > my.env 

पाथ चर में देखें:

 > grep ^PATH= crontab.env my.env Crontab.env: PATH=/usr/bin:/bin My.env: PATH=/local/hive/bin:/local/python/bin:/local/hadoop/bin:/local/hadoop/bin:/local/hive/bin:/local/hadoop/bin:/usr/local/bin:/usr/bin:/bin 

मामा मिया! तो वहाँ मुकुट के तहत केवल बहुत ही कम! बेशक, आपको सामान्य पर्यावरण चर को लोड करने की आवश्यकता है।

आइए देखें कि अगर हम बैश-एल जोड़ते हैं तो पर्यावरण क्या होगा:

 $ echo "* * * * * bash -l env > ~/crontab.env" | crontab; sleep 60; echo "" | crontab; alexxz@bi1.mlan:~> grep ^PATH= crontab.env my.env Crontab.env: PATH=/local/hive/bin:/local/python/bin:/local/hadoop/bin:/local/hadoop/bin:/local/hadoop/bin:/local/hive/bin:/usr/local/bin:/usr/bin:/bin My.env: PATH=/local/hive/bin:/local/python/bin:/local/hadoop/bin:/local/hadoop/bin:/local/hive/bin:/local/hadoop/bin:/usr/local/bin:/usr/bin:/bin 

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

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

लॉगिन स्क्रिप्ट का डीबग इनिशियलाइज़ेशन

समस्या को हल करने के लिए लगता है, ताज से सब कुछ काम करता है। लेकिन यह कैसे है कि पाथ चर में कुछ रास्तों की नकल की जाती है? इसलिए सर्वर सेटअप में किसी प्रकार की गड़बड़ी है। आइए इसे जानने की कोशिश करते हैं।

हम पर्यावरण को शुरू करने के लिए कुछ लोगों को खोलते हैं, हम पढ़ते हैं कि कौन सी स्क्रिप्ट और किस क्रम में निष्पादित की जाती हैं, उत्साह के साथ हम उनकी आंखों के माध्यम से चलना शुरू करते हैं - और कुछ मिनटों के बाद निराशा की भावना आती है। एलएस कमांड के लिए आर्किटेक्चर, टर्मिनलों और अविश्वसनीय रूप से महत्वपूर्ण रंग सेटिंग्स के कुछ विशेष मामलों के बारे में स्थितियों की कुछ अंतहीन धारा। पीड़ा, निराशा, घृणा! हम एक लानत चर पैठ में रुचि रखते हैं!

वास्तव में, सब कुछ कुछ सरल है। मिलना

 env -i bash -x -l -c 'echo 123' > login.log 2>&1 

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

मैं परिणामी लॉग को पढ़ने के तरीके का विस्तार से विश्लेषण नहीं करूंगा। वहां सब कुछ लगभग तुच्छ है। मैं केवल उल्लेख करता हूं कि एक हिट / etc / प्रोफाइल से आया और दो /etc/bash.bashrc से। हां, कहीं न कहीं वे बहुत स्मार्ट थे जब एक पपेट में पैकेज सेट करते थे। खैर, कुछ भी नहीं, यह मुझे काम करने के लिए परेशान नहीं करता है।

लेकिन अब मुझे पता है और कर सकते हैं!

PS बहुत मुश्किल मामलों में और हर चीज को समझने के लिए, आप स्ट्रेस में कमांड को लपेट सकते हैं:

  strace -f env -i bash -x -l -c 'echo 123' > login.log 2>&1