Systemctl और सर्विस कमांड के बीच अंतर

Question

systemdहमें systemctlकमांड सूट देता है जो ज्यादातर बूट समय पर शुरू करने के लिए सेवाओं को सक्षम करने के लिए उपयोग किया जाता है। हम इसकी मदद से सेवाओं की स्थिति को शुरू, बंद, पुनः लोड, पुनः आरंभ और जाँच भी कर सकते हैं systemctl।

हम कर सकते हैं, उदाहरण के लिए sudo systemctl enable service_name, और service_nameस्वचालित रूप से बूट समय पर शुरू होगा। हम बूट समय पर शुरू नहीं करने के लिए सेवाओं को भी अक्षम कर सकते हैं।

क्या रन टाइम पर सेवाओं की शुरुआत को सक्षम करने के लिए serviceऔर systemctlकमांड के बीच एकमात्र अंतर है systemctl? क्या हम systemctlकिसी सेवा पर उपयोग कर सकते हैं ? अन्य महत्वपूर्ण अंतर क्या हैं?

Comments

मुझे लगता है कि आपने खुद गलत जवाब उठाया।

— इवान कैरोल

Answer 1

serviceआदेश एक आवरण स्क्रिप्ट सिस्टम प्रशासक, शुरू रोक, और वास्तविक init प्रणाली का इस्तेमाल किया जा रहा है के बारे में बहुत ज्यादा चिंता किए बिना सेवाओं की स्थिति की जांच करने की अनुमति देता है। सिस्टमड की शुरूआत से पहले, यह /etc/init.dस्क्रिप्ट और अपस्टार्ट की initctlकमांड के लिए एक आवरण था , और अब यह इन दोनों के लिए और systemctl साथ ही साथ एक आवरण है ।

स्रोत का उपयोग करें, ल्यूक!

यह अपस्टार्ट के लिए जाँच करता है:

# Operate against system upstart, not session
unset UPSTART_SESSION
if [ -r "/etc/init/${SERVICE}.conf" ] && which initctl >/dev/null \
   && initctl version 2>/dev/null | grep -q upstart \
   && initctl status ${SERVICE} 2>/dev/null 1>/dev/null
then
   # Upstart configuration exists for this job and we're running on upstart

यदि वह काम नहीं करता है, तो यह systemd के लिए दिखता है:

if [ -d /run/systemd/system ]; then
   is_systemd=1
fi

...

# When this machine is running systemd, standard service calls are turned into
# systemctl calls.
if [ -n "$is_systemd" ]
then

और अगर वह भी विफल रहता है, तो यह सिस्टम V /etc/init.dस्क्रिप्ट पर वापस आता है :

run_via_sysvinit() {
   # Otherwise, use the traditional sysvinit
   if [ -x "${SERVICEDIR}/${SERVICE}" ]; then
      exec env -i LANG="$LANG" LANGUAGE="$LANGUAGE" LC_CTYPE="$LC_CTYPE" LC_NUMERIC="$LC_NUMERIC" LC_TIME="$LC_TIME" LC_COLLATE="$LC_COLLATE" LC_MONETARY="$LC_MONETARY" LC_MESSAGES="$LC_MESSAGES" LC_PAPER="$LC_PAPER" LC_NAME="$LC_NAME" LC_ADDRESS="$LC_ADDRESS" LC_TELEPHONE="$LC_TELEPHONE" LC_MEASUREMENT="$LC_MEASUREMENT" LC_IDENTIFICATION="$LC_IDENTIFICATION" LC_ALL="$LC_ALL" PATH="$PATH" TERM="$TERM" "$SERVICEDIR/$SERVICE" ${ACTION} ${OPTIONS}
   else
      echo "${SERVICE}: unrecognized service" >&2
      exit 1
   fi
}

...
run_via_sysvinit

चूंकि serviceकमांड एक काफी सरल आवरण है, इसलिए यह केवल वास्तविक इनिट सिस्टम प्रदान करने की तुलना में कार्यों के एक सीमित उपसमूह का समर्थन करता है।

उबंटू के विभिन्न संस्करणों पर पोर्टेबिलिटी के लिए, उपयोगकर्ता serviceकिसी सेवा की स्थिति को शुरू करने, रोकने, फिर से शुरू करने या उसकी जांच करने के लिए मज़बूती से कमांड का उपयोग कर सकते हैं । हालांकि, अधिक जटिल कार्यों के लिए, वास्तविक कमांड का उपयोग किया जा रहा है, initctlया तो systemctlया /etc/init.dस्क्रिप्ट को सीधे उपयोग करना पड़ सकता है।

इसके अलावा, एक रैपर होने के नाते, serviceकुछ मामलों में स्क्रिप्ट प्रत्यक्ष समतुल्य कमांड की तुलना में अधिक काम करती है। उदाहरण के लिए:

• यह हमेशा /etc/init.dस्वच्छ वातावरण में स्क्रिप्ट निष्पादित करता है। ( ऊपर दिए गए फ़ंक्शन में लंबी env कमांड मंगलाचरण पर ध्यान दें run_via_sysvinit।)
• यह restartउपस्टार्ट सिस्टम पर stop/ के संयोजन पर मैप करता है start, क्योंकि initctl restartयदि कोई सेवा पहले से ही नहीं चल रही है तो एक सादा त्रुटि करेगा।

• यह सिस्टम सॉकेट्स को रोकते समय सॉकेट्स को रोकता है जिसमें संबद्ध सॉकेट्स हैं:

  case "${ACTION}" in
    restart|status)
       exec systemctl $sctl_args ${ACTION} ${UNIT}
    ;;
    start|stop)
       # Follow the principle of least surprise for SysV people:
       # When running "service foo stop" and foo happens to be a service that
       # has one or more .socket files, we also stop the .socket units.
       # Users who need more control will use systemctl directly.

अपस्टार्ट सेवाओं को सीधे सेवा कॉन्फ़िगरेशन फ़ाइल (या ओवरराइड्स के माध्यम से अक्षम) में सक्षम किया गया था, और सिस्टम वी स्क्रिप्ट को update-rc.dकमांड के साथ सक्षम या अक्षम किया गया था (जो /etc/rc*निर्देशिकाओं में सहानुभूति प्रबंधित करता serviceथा ), इसलिए कमांड कभी भी बूट के लिए सेवाओं को सक्षम या अक्षम करने में शामिल नहीं था। ।

Answer 2

• systemd SysV के साथ पीछे की ओर संगत है।
• स्टार्टअप पर समानांतर सेवाओं को लोड करता है
• यह एक सेवा की मांग पर सक्रियण प्रदान करता है
• यह निर्भरता आधारित है
• और बहुत कुछ मुझे लगता है ...

आपके द्वारा उल्लेखित की तुलना में बहुत अधिक हैं जो systemctlसक्षम हैं।

systemd इकाइयों के साथ काम करता है, विभिन्न प्रकार की इकाइयाँ हैं: लक्ष्य, सेवाएं, सॉकेट, आदि लक्ष्य रनवेल्स के समान अवधारणा हैं, वे एक साथ इकाइयों का एक समूह हैं।

आप systemctlडिफ़ॉल्ट सिस्टम लक्ष्य को सेट या प्राप्त करने के लिए उपयोग कर सकते हैं ।

systemctl get-default

आप अन्य लक्ष्यों में जा सकते हैं:

systemctl isolate multiuser.target

अन्य लक्ष्य हैं: बहुउपयोगी, चित्रमय, सुनहरा, आपातकालीन, रिबूट, पॉवरऑफ।

जैसा कि आपने कहा, आप systemctlसेवाओं का प्रबंधन करने के लिए उपयोग कर सकते हैं , सेवा प्रबंधन से संबंधित कुछ अन्य आदेश जो मुझे ज्ञात हैं:

# Restarts a service only if it is running.
systemctl try-restart name.service

# Reloads configuration if it's possible.
systemctl reload name.service

# try to reload but if it's not possible restarts the service
systemctl reload-or-restart name.service

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

systemctl status name.service

systemctl is-active name.service # running
systemctl is-enabled name.service # will be activated when booting
systemctl is-failed name.service # failed to load

आप एक सेवा को मास्क या अनमास्क कर सकते हैं:

systemctl mask name.service
systemctl unmask name.service

वेन आप एक ऐसी सेवा को मास्क करते हैं /dev/null, जिससे इसे लिंक किया जाएगा , इसलिए मैन्युअल रूप से या स्वचालित रूप से अन्य सेवाएं इसे सक्रिय / सक्षम नहीं कर सकती हैं। (आपको पहले इसे अनमस्क करना चाहिए)।

Systemctl का एक अन्य उपयोग इकाइयों को सूचीबद्ध करना है:

systemctl list-units

जो सभी प्रकार की इकाइयों को लोड और सक्रिय सूची देते हैं।

सूची सेवा इकाइयाँ:

systemctl list-units --type=service

या उन सभी उपलब्ध इकाइयों को सूचीबद्ध करने के लिए जो केवल लोड और सक्रिय नहीं हैं:

systemctl list-unit-files

आप उपनाम बना सकते हैं या दूरस्थ मशीनों को भी नियंत्रित कर सकते हैं

systemctl --host ravexina@192.168.56.4 list-units

दूसरी ओर serviceयह क्या करना है, सेवाओं का प्रबंधन और अन्य लोगों के व्यापार के साथ कुछ नहीं करना है;)

Comments

यह एक सही जवाब था, क्या ऐसा कुछ है जो serviceकर सकता है लेकिन नहीं systemctl?

— luv.preet

ऐसा कुछ भी नहीं जो मुझे पता है, मुझे लगता है कि सर्विस मैन पेज पर एक नज़र रखना मददगार होगा।

— रवेक्सिना

कुछ स्पष्ट अंतर हैं। सिंटेक्स एक है। एक और यह है कि सिस्टमव स्क्रिप्ट कभी भी सॉकेट्स से नहीं निपटती है, जहां तक ​​मुझे पता है। तथ्य यह है कि सिस्टमड नेटवर्क प्रकार के सामान से निपटने की कोशिश कर रहा है, और यह समालोचना का लगातार बिंदु है। सब से अधिक, सिस्टमड बस सेवाओं को शुरू करने से अधिक करने की कोशिश कर रहा है

— सर्जियो कोलोडियाज़नी

मैं यहां असफल संदेशों से लॉग संदेश को छिपाने के बारे में शिकायत करना चाहता हूं service start। प्री-सिस्टमड, service startमुझे तुरंत देखने देगा कि मेरी सेवा शुरू क्यों नहीं होगी। पोस्ट-सिस्टमड, मुझे खोजने से पहले चार या पांच अलग-अलग लॉग को देखना होगा। उस सभी ने कहा, मेरी टिप्पणी निस्संदेह विषय से हटकर है और शायद हटा दी जाएगी।

— रॉस प्रेसर

AFAICS यह जवाब serviceकमांड के बारे में कुछ भी बताने के लिए नहीं लगता है , क्या यह सवाल का हिस्सा नहीं था?

— इल्काचू