2011-01-17 2 views
10

मुझे एक प्रोग्राम लिखना होगा जो उस मशीन पर चलने के अपने दूसरे उदाहरण के बारे में अवगत होना चाहिए, और इसके साथ संवाद करें, फिर मर जाएं। मैं जानना चाहता हूं कि लिनक्स में ऐसा करने का एक कैननिक तरीका है या नहीं।एक ही प्रोग्राम की अन्य प्रक्रियाओं के बारे में जागरूक प्रक्रिया कैसे करें

मेरी पहली सोचा somewere प्रक्रिया के पीआईडी ​​वाली फ़ाइल हर बार कार्यक्रम कार्यान्वित लिखते हैं, और उस फ़ाइल के लिए देखने के लिए गया था, लेकिन जहां "सही" जगह और उस फ़ाइल के लिए नाम क्या है? क्या कोई बेहतर, या अधिक "सही" तरीका है?

तो मुझे यह कहना चाहिए कि उपयोगकर्ता इसे चलाने की कोशिश कर रहा है, लेकिन चूंकि एक और उदाहरण है, यह नौकरी और बाहर निकल जाएगा। मैंने सिग्सआरआर 1 की तरह सिग्नल भेजने का सोचा, लेकिन इससे मुझे एक्स 11 डिस्प्ले की तरह अधिक जानकारी भेजने की इजाजत नहीं दी जाएगी, जहां से उपयोगकर्ता ने दूसरी प्रक्रिया को निष्पादित किया था। यह जानकारी कैसे भेजें?

कार्यक्रम जीटीके के खिलाफ जुड़ा हुआ है, इसलिए ग्लिब का उपयोग करने वाला एक समाधान ठीक है।

उत्तर

10

फ़ाइल में पिड डालने से यह प्राप्त करने का एक आम तरीका है। डेमन्स ("सिस्टम प्रोग्राम्स") के लिए, ऐसी फाइल रखने के लिए आम जगह /var/run/PROGRAM.pid है। उपयोगकर्ता प्रोग्राम के लिए, उपयोगकर्ता के होमएडर में छिपी हुई पिड फ़ाइल डालें (यदि प्रोग्राम में कॉन्फ़िगरेशन फ़ाइलें भी हैं, तो दोनों कॉन्फ़िगरेशन फ़ाइलें और पीआईडी ​​फ़ाइल को घर डीआईआर के उपदिर में रखें)।

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

+3

अकेले एक पिड फ़ाइल बहुत बेकार है। यदि एप्लिकेशन क्रैश हो जाता है तो यह उसकी पिड फ़ाइल को हटा नहीं सकता है ताकि इसे मैन्युअल रूप से हटा दिया जाए। एक बेहतर विकल्प है कि पिड फ़ाइल को लॉक करना, क्योंकि ओएस हमेशा लॉक को रिलीज़ करता है जब प्रक्रिया किसी भी तरह समाप्त हो जाती है। आप 'ls -la' कर कर हालांकि लॉक नहीं देख सकते हैं। एक यूनिक्स डोमेन सॉकेट अकेला है। –

+0

@ मैक्सिम: झूठी। 'अनलिंक (...) फ़ाइल बंद होने के बाद फ़ाइल हटा देता है। तो 'एफडी = खुला (पथ, ...); अनलिंक (पथ); 'एक अस्थायी फ़ाइल रखने के लिए सामान्य चाल है। – Alexandru

+0

@Alexandru: लगभग सही, आप इस तथ्य से चूक गए कि हम पिड फाइलों पर चर्चा कर रहे थे, अस्थायी फाइल नहीं। आवेदन समाप्त होने से पहले पीआईडी ​​फ़ाइल को हटाया नहीं जाना चाहिए। –

9

यूनिक्स डोमेन सॉकेट। पहले उदाहरण को एक अस्थायी निर्देशिका में बनाएं, उसके बाद अन्य उदाहरण इसके माध्यम से इसके साथ संवाद करें।

+2

संभवतः एक अस्थायी निर्देशिका नहीं -/var/run सॉकेट फ़ाइलों के लिए काफी आम है। –

5

एक पीआईडी ​​फ़ाइल लिखना एक आम दृष्टिकोण है। pidfile(3) लाइब्रेरी देखें।

1

ऐसा करने के कई तरीके हैं। जिस तरह से आपने प्रस्तावित किया है (पीआईडी ​​युक्त फाइल का उपयोग करना) एक वैध है और इसका उपयोग कई अनुप्रयोगों द्वारा किया जाता है।

कुछ बार एप्लिकेशन की कॉन्फ़िगरेशन फ़ाइल में पीआईडी ​​फ़ाइल के लिए पथ होता है, अन्य बार हार्डकोडेड पथ का उपयोग किया जाता है। आम तौर पर आवेदन /tmp में /var (यदि वे यूआईडी 0 के साथ चलते हैं) में या अपनी स्थानीय निर्देशिका (~/.application/) में पीआईडी ​​फ़ाइल डालते हैं।

आपके पीआईडी ​​फ़ाइल को कहां रखना है, इस बारे में कोई सामान्य सुझाव नहीं है, बस अपनी पसंदीदा जगह चुनें।

2

क्या लिनक्स के पास नामित म्यूटेक्स या सेमफोर के बराबर है? तो आप यह देखने के लिए जांच सकते हैं कि यह 'लॉक' है या फिर उपयोगकर्ता को चेतावनी दी गई है कि उनके पास पहले से एक है और इसे बंद कर दें?

क्या यह इस लिंक से समझ में आता है? http://www.linuxquestions.org/questions/programming-9/named-mutex-in-linux-296816/

+0

नामांकित सेमफोर कई उदाहरणों की समस्या का समाधान करने के तरीके के रूप में काम करते हैं, हालांकि यह एक अपरंपरागत है। – lvella

+2

हालांकि यह काम करेगा, यह बदसूरत है कि नामस्थान को मशीन पर सभी प्रक्रियाओं के बीच साझा किया जाता है, और कोई अन्य उपयोगकर्ता एक ही नाम से नामित सेमफोर खोलकर अपना प्रोग्राम कर सकता है। निजी तौर पर मैं कभी भी यादृच्छिक नामों के बिना सेमफोर/साझा मेमोरी नामक पॉज़िक्स का उपयोग नहीं करता, और सही विशेषाधिकारों के साथ एक प्रक्रिया को छोड़कर किसी अन्य सुरक्षित चैनल के माध्यम से नाम को संचारित नहीं करता। –

1

आप निश्चित रूप से यूनिक्स डोमेन सॉकेट का उपयोग कर सकते हैं; मुझे लगता है कि अधिकांश एप्लिकेशन (जो डीसीओपी या डीबीयूएस जैसे उच्च स्तरीय सिस्टम का उपयोग नहीं करते हैं) इनका उपयोग करते हैं।

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

यदि आपका प्रोग्राम उपयोगकर्ता उन्मुख है, तो यह शायद बहुउद्देशीय होना चाहिए; एक उपयोगकर्ता को किसी अन्य उपयोगकर्ता की ऐप की प्रतिलिपि में व्यवहार को ट्रिगर करने में सक्षम नहीं होना चाहिए, और यह सुनिश्चित करने के लिए सुरक्षा की आवश्यकता है कि उपयोगकर्ता आसानी से एक-दूसरे को नहीं कर सकें (उदाहरण: यदि उपयोगकर्ता ए की प्रोग्राम की प्रतिलिपि लगी है, तो क्या यह उपयोगकर्ता को रोकती है बी शुरू से ही?)।

+0

मुझे लगता है कि उपयोगकर्ता के घर के अंदर फ़ाइलों को रखने से किसी अन्य उपयोगकर्ता के साथ हस्तक्षेप करने से रोका जा सकता है। – lvella

+0

हाँ यह एक संभावित कार्यान्वयन है। – MarkR

संबंधित मुद्दे

 संबंधित मुद्दे