सिस्टम में r.local के लिए सही विकल्प क्या है r -local को फिर से बनाने के बजाय


25

मैं systemd पर कुछ स्थानीय लिपियों (या बहुत स्थानीय कमांड) को निष्पादित करने का सही तरीका नहीं खोज सकता , मुझे पहले से ही पता है कि मुझे इस प्रकार की स्क्रिप्ट (या मुझे चाहिए?) के लिए एक सेवा (systemd एक इकाई) नहीं बनानी चाहिए ....?

मुझे जो वर्कअराउंड मिला है, वह है rc.local बनाना और इसे एक्जीक्यूटिव परमिशन देना।

printf '#!/bin/bash \n\nexit 0' >/etc/rc.local 
chmod +x /etc/rc.local

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

मैं देख रहा हूँ एक और सवाल के बारे में पूछ जहां rc.local है और जवाब यह बना सकते हैं और निष्पादन अनुमतियाँ देने के लिए, मुझे लगता है कि मेरे सवाल का सच है था नहीं एक नकली है, क्योंकि मैं जानता हूँ कि नहीं करना चाहती कि वह कहाँ है - मुझे विश्वास है, मैं बस चाहता हूँ यह स्वीकार करने के लिए कि यह पदावनत है , लेकिन मुझे इस तरह की चीजों को करने का सही तरीका नहीं मिल रहा है, क्या मुझे वास्तव में इस तरह से कुछ सरल के लिए एक इकाई बनाना चाहिए?


4
systemd "केवल जीतने वाला कदम नहीं खेलना है"; वैकल्पिक रूप से, आप जो चाहते हैं उसके आधार पर, आप एक सिस्टम यूनिट बना सकते हैं। मैं शायद अभी के लिए r.local का उपयोग करूंगा, और जब वह चला जाएगा तो इसकी परवाह करेगा।
रुई एफ रिबेरो

तो आपको लगता है कि आधिकारिक तरीका सेवा की तरह एक इकाई बनाना है? कृपया एक उत्तर के रूप में पोस्ट करें कि यह कैसे करना है।
लुसियानो अंड्रेस मार्टिनी

1
जब मैंने उबंटू की कोशिश की तो मैंने अपने डेस्कटॉप में लगातार ssh- एजेंट कैशिंग करने के लिए एक यूनिट बनाई, जबकि मैंने रिबूट नहीं किया और किसी और चीज़ के लिए जिसे मैं याद नहीं कर सकता; आप /etc/rc.local की ओर एक संकेत भी बना सकते हैं, लेकिन ऐसा लगता है कि सिस्टम इसे अभी के लिए अपने लिए कर रहा है .... मैं इस समय के लिए r इंकलोक करूँगा, और यदि बंद हो जाता है, तो एक नकली की ओर इशारा करें /etc/rc.local फिर।
रुई एफ रिबेरो

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

आपको किस तरह की स्क्रिप्ट को निष्पादित करने की आवश्यकता है? सिस्टमड में कई प्रकार के यूनिट हैं। "सेवा" केवल कई इकाई प्रकारों में से एक है । जैसे माउंट यूनिट, ऑटोमाउंट यूनिट, टाइमर यूनिट, टारगेट यूनिट। क्या उनमें से कोई आपकी समस्या का समाधान कर सकता है?
andcoz

जवाबों:


17

के रूप में कहीं और ने कहा, यह मामूली उपयोग करने के लिए अशुद्ध हो जाता है rc-local.serviceके तहत systemd

  1. यह सैद्धांतिक रूप से संभव है कि आपका वितरण इसे सक्षम नहीं करेगा। (मुझे लगता है कि यह सामान्य नहीं है, उदाहरण के लिए क्योंकि एक ही बिल्ड विकल्प को अक्षम करना भी बहुत सारे लोगों के उपयोग poweroff/ rebootआदेशों को हटा देता है )।
  2. शब्दार्थ पूरी तरह से स्पष्ट नहीं हैं। सिस्टमड rc-local.serviceएक तरह से परिभाषित करता है , लेकिन डेबियन एक ड्रॉप-इन फ़ाइल प्रदान करता है जो कम से कम एक महत्वपूर्ण सेटिंग को बदल देता है।

rc-local.serviceअक्सर अच्छा काम कर सकते हैं। यदि आप उपरोक्त के बारे में चिंतित हैं, तो आपको केवल इसकी प्रतिलिपि बनाने की आवश्यकता है! यहाँ जादू है:

# /etc/systemd/system/my-startup.service
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/local/libexec/my-startup-script

[Install]
WantedBy=multi-user.target

मुझे नहीं लगता कि आपको हर एक विवरण को समझने की जरूरत है [*], लेकिन यहां दो चीजें हैं जो आपको जानना आवश्यक हैं।

  1. आपको इसे सक्षम करने की आवश्यकता है systemctl enable my-startup.service

  2. यदि आपकी स्क्रिप्ट में किसी भी अन्य सेवा पर निर्भरता है network-online.target, तो आपको इसे घोषित करना होगा। जैसे [Unit]लाइनों के साथ एक खंड जोड़ें Wants=network-online.targetऔर After=network-online.target

    आपको "शुरुआती बूट" सेवाओं पर निर्भरता के बारे में चिंता करने की आवश्यकता नहीं है - विशेष रूप से, ऐसी सेवाएं जो पहले से ही ऑर्डर की जाती हैं basic.target। जब तक वे सेट नहीं करते, तब जैसी सेवाओं my-startup.serviceको स्वचालित रूप से ऑर्डर basic.targetकिया जाता है DefaultDependencies=no

    यदि आप सुनिश्चित नहीं हैं कि आपकी कोई निर्भरता "प्रारंभिक बूट" सेवा है, तो एक दृष्टिकोण उन सेवाओं को सूचीबद्ध करने का है basic.target, जिन्हें चलाने से पहले आदेश दिया गया है systemctl list-dependencies --after basic.target। (ध्यान दें कि --after, नहीं --before)।

कुछ विचार हैं जो मुझे लगता है कि पूर्व-प्रणाली पर भी लागू होते हैं rc.local:

  1. आपको यह सुनिश्चित करने की ज़रूरत है कि आपके आदेश किसी अन्य प्रोग्राम के साथ विरोध नहीं कर रहे हैं जो एक ही चीज़ को नियंत्रित करने की कोशिश करता है।
  2. यह सबसे अच्छा है कि लंबे समय से चल रहे कार्यक्रमों उर्फ ​​डेमन से शुरू न करें rc.local

[*] मैंने Type=oneshot+ का उपयोग किया RemainAfterExit=yesक्योंकि यह अधिकांश एक-शॉट स्क्रिप्ट के लिए अधिक समझ में आता है। यह औपचारिक करता है कि आप कमांड की एक श्रृंखला चलाएंगे, जिसे my-startupपूरा होने के बाद "सक्रिय" के रूप में दिखाया जाएगा, और यह कि आप एक डेमॉन शुरू नहीं करेंगे।


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

1
@ LucianoAndressMartini अगर आप पूछ रहे हैं कि डेमॉन शुरू करने का सही तरीका क्या है, तो आपको वास्तव में इसके लिए एक व्यक्तिगत सेवा को परिभाषित करना चाहिए। यह एक देशी प्रणाली .serviceइकाई हो सकती है , या यदि आप वास्तव में एक एलएसबी इनिट स्क्रिप्ट लिखना चाहते हैं तो आप इसके बजाय ऐसा कर सकते हैं। मैं कई डेमों को rc-local.serviceया उसके बराबर में रखने की सिफारिश नहीं करना चाहता था , मुझे लगता है कि यह शायद काम करता है, लेकिन यह बहुत अच्छा लगता है यदि आप systemctl restart my-daemonकिसी अन्य चीज़ की तरह व्यक्तिगत डेमन को फिर से शुरू कर सकते हैं । यह इरादा है कि आप अपनी स्थानीय सेवाओं को अंदर रखें /etc/systemd/system
sourcejedi

1
@LucianoAndressMartini आपको किसी अन्य सेवा के समान नाम का उपयोग करने से बचना होगा - ठीक उसी तरह जैसे sysvinit में होता है। इसी तरह की स्थितियों में मैंने कभी-कभी अपने नाम के साथ शुरू किया है local-...
sourcejedi

1
धन्यवाद!!! आधे दिन बाद बचाया। ये विवरण मेरे लिए महत्वपूर्ण थे: Type = oneshot, RemainAfterExit = हाँ, Wants = network-online.target, After = network-online.target। बस अपाचे का निर्माण तैनात करना और स्थिर आईपी को 192.168.1.80 पर सेट करना, ताकि राउटर वहां यातायात को निर्देशित कर सके। तुच्छ होना चाहिए। यह डेबियन 9 में कष्टप्रद है। "Apt-get apache", "systemctl start apache" या init.d के निर्देशों के अलावा शायद ही कोई ऑनलाइन सलाह, जिनमें से कोई भी Debian9 के तहत स्रोत-निर्मित Apache के लिए लागू न हो।
माइकल्सनब्रिट

1
@ मिचेलसनब्रिट यह सबसे अच्छा है कि लंबे समय से चलने वाले प्रोग्राम उर्फ ​​डेमॉन को rc.local से शुरू न करें। मैंने इस्तेमाल किया Type=oneshot... यह औपचारिक करता है कि ... आप एक डेमॉन शुरू नहीं करेंगे। यदि आप डेमन शुरू करने के बारे में जानकारी चाहते हैं, तो कृपया एक नया प्रश्न पूछें।
sourcejedi

15

के बारे में भूल जाओ rc.local

जैसा कि मैंने CentOS 7 और डेबियन 8 के बारे में और Ubuntu 15 के बारे में कहा है :

आप एक systemd + Linux ऑपरेटिंग सिस्टम का उपयोग कर रहे हैं। /etc/rc.localsystemd में एक डबल बैकवर्ड कम्पैटिबिलिटी मेकेनिज्म है, क्योंकि यह एक मेकेनिज्म के लिए बैकवर्ड कम्पैटिबिलिटी मेकेनिज्म है जो स्वयं वैन स्मुरेनबर्ग सिस्टम 5 rcक्लोन में कम्पैटिबिलिटी मेकेनिज्म था ।

उपयोग करना /etc/rc.localबुरी तरह से गलत हो सकता है। लोग इस तथ्य से आश्चर्यचकित हो गए हैं कि सिस्टमड rc.localबूटस्ट्रैप में काफी उसी तरह से नहीं चलता है, जैसा कि वे उपयोग में लाए जाते हैं। (या त्रुटिपूर्ण रूप से अपेक्षा करें: यह वास्तव में, पुरानी प्रणाली में अंतिम रूप से नहीं चलता है, जैसा कि ओपनबीएसडी मैनुअल अभी भी बताता है।) अन्य लोग इस तथ्य से आश्चर्यचकित हैं कि वे rc.localचीजों को करने के पुराने तरीकों की अपेक्षा में क्या सेट करते हैं। तो पूरी तरह से नए की पसंद को नष्ट कर दिया udevनियम, NetworkManager, systemd-logind, systemd-resolved, या विभिन्न "किट" रों।

जैसा कि आर्क इंस्टाल पर "एक्सट्रा आर्ग्यूमेंट्स" में " क्यों init 0` परिणाम देता है" के रूप में उदाहरण के लिए , कुछ ऑपरेटिंग सिस्टम पहले से ही पश्चगामी संगतता सुविधाओं के बिना सिस्टमड प्रदान करते हैंsystemd-rc-local-generator जनरेटर जैसेजबकि डेबियन अभी भी पीछे की संगतता सुविधाओं को बरकरार रखता है , आर्क लिनक्स ने उन्हें बंद कर दिया । तो आर्क और ऑपरेटिंग सिस्टम पर जैसे कि इसे /etc/rc.local पूरी तरह से नजरअंदाज करने की उम्मीद है

के बारे में भूल जाओ rc.local। यह रास्ता नहीं है। आपके पास एक systemd + Linux ऑपरेटिंग सिस्टम है। इसलिए एक उचित systemd सेवा इकाई बनाएं, और एक ऐसे बिंदु से शुरू न करें जो पीछे की संगतता के दो स्तरों से दूर हो। (उबंटू और फेडोरा पर, इसे तीन बार हटा दिया गया है, वैन स्मरनबर्ग सिस्टम 5 rcक्लोन जो बाद rc.localमें दो बार सुपरस्टेड हो गया , एक दशक पहले, पहले ऊपर से और फिर सिस्टमड द्वारा।)

सिस्टमैड में माइग्रेट करने के लिए पहला नियम भी याद रखें ।

यह एक नया विचार भी नहीं है जो सिस्टमड के लिए विशिष्ट है। वैन स्मुरेनबर्ग rcऔर अपस्टार्ट सिस्टम पर, एक उचित वैन स्मुरेनबर्ग बनाने के लिए करना थाrc उपयोग के बजाय स्क्रिप्ट या अपस्टार्ट नौकरी फ़ाइलrc.local । यहां तक ​​कि FreeBSD के मैनुअल नोट्स जो आजकल कोई rcभी उपयोग करने के बजाय एक उचित Mewburn स्क्रिप्ट बनाता है /etc/rc.local। मेबर्न rcको 2000 में NetBSD 1.5 द्वारा पेश किया गया था।

/etc/rc.localसातवें संस्करण के यूनिक्स के समय और उससे पहले की तारीखें। इसे AT & T Unix System 3 में /etc/inittabएक रनलेवल-आधारित rcऔर थोड़ा अलग के साथ रखा गया था/etc/inittab 1983 एटी एंड टी यूनिक्स सिस्टम 5 में गया था । यहां तक कि अब यह इतिहास है।

आपकी सेवा प्रबंधन प्रणाली के लिए उचित देशी सेवा परिभाषाओं बनाएँ, कि nosh टूलसेट के लिए एक सेवा बंडल हो कि क्या service-managerऔर system-control, एक /etc/rc.d/Mewburn के लिए स्क्रिप्ट rc, systemd के लिए एक सेवा इकाई फ़ाइल, कल का नवाब के लिए एक नौकरी फ़ाइल, RUNIT / S6 / daemontools के लिए एक सेवा निर्देशिका -नकोर, या /etc/init.d/वैन स्मरनबर्ग के लिए एक स्क्रिप्ट भी rc

सिस्टमड में, ऐसी प्रशासक-जोड़ा सेवा इकाई फाइलें /etc/systemd/system/आमतौर पर (या /usr/local/lib/systemd/system/शायद ही कभी) जाती हैं। नोश सेवा प्रबंधक के साथ, /var/local/sv/स्थानीय सेवा बंडलों के लिए एक पारंपरिक स्थान है। rcFreeBSD पर मेवबर्न का उपयोग करता है /usr/local/etc/rc.d/पैकेज्ड सर्विस यूनिट फाइलें और सर्विस बंडल, यदि आप उन्हें बना रहे हैं, तो अलग-अलग जगहों पर जाएं।

आगे की पढाई


2
@LucianoAndressMartini एक बेहतर सवाल यह होगा कि सिस्टमेटिक सर्विस में rc.local के एक विशिष्ट स्निपेट को कैसे हैंडल किया जाए। तो अगर आपके मन में एक ख़ास ख़ुराक है (आप कुछ सॉफ़्टवेयर के दस्तावेज़ों से निर्देशों का उल्लेख करते हैं), तो शायद उस बारे में एक प्रश्न पोस्ट करें? कुछ सामान्य नियम हैं, जिनका उपयोग रूपांतरण के लिए किया जा सकता है, लेकिन आप अपने द्वारा चलाए जा रहे सॉफ़्टवेयर की सुविधाओं का उपयोग करके अधिक प्राप्त करते हैं (जैसे कि अग्रभूमि में दौड़ना, डामरीकरण करने की कोशिश न करना, आदि) इसलिए किसी विशिष्ट मामले के बारे में पूछें। मददगार हो सकता है।
फिल्मब्रांडेन

4
आपको आश्चर्य होगा कि क्या यह 1983 के बाद से पदावनति से बच गया है, हो सकता है कि इसके लिए कुछ हो रहा हो?
डेन कार्टर

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

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

2

Https://www.linuxbabe.com/linux-server/how-to-enable-etcrc-local-with-systemd का सारांश

/Etc/systemd/system/rc-local.service बनाएं:

# /etc/systemd/system/rc-local.service
[Unit]
 Description=/etc/rc.local Compatibility
 ConditionPathExists=/etc/rc.local

[Service]
 Type=forking
 ExecStart=/etc/rc.local start
 TimeoutSec=0
 StandardOutput=tty
 RemainAfterExit=yes
 SysVStartPriority=99

[Install]
 WantedBy=multi-user.target

फिर:

sudo touch /etc/rc.local
sudo chmod +x /etc/rc.local
sudo systemctl enable rc-local

इससे जाँच करें:

sudo systemctl start rc-local.service
sudo systemctl status rc-local.service

सिस्टम-प्रदान किया हुआ एक उपयोग StandardOutput=journal+console(कंसोल आपके उदाहरण में ट्टी के बराबर है), जो ऐसा लगता है कि यह समस्या निवारण के लिए बहुत अधिक उपयोगी होगा। इसके अलावा SysVStartPriority=कुछ बिंदु पर समर्थन को हटा दिया गया है। शायद आप टिप्पणी कर सकते हैं कि SysVStartPriority=यह कितना महत्वपूर्ण है, या इसे हटा दें। इसके अलावा, यह एक सभ्य जवाब है।
sourcejedi 13
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.