सिस्टमड सेवा बिना बाहर निकले चलती है

Question

मैंने jekyll के लिए अपनी स्वयं की सेवा बनाई है और जब मैं सेवा शुरू करता हूं तो ऐसा लगता है कि यह एक पृष्ठभूमि प्रक्रिया के रूप में नहीं चलती है क्योंकि मैं इसके बाहर ctrl+ मजबूर हूं c। यह सिर्फ - वॉच के कारण अग्रभूमि में रहता है। मुझे यकीन नहीं है कि इसके चारों ओर कैसे जाना है और इसे बनाना है ताकि यह पृष्ठभूमि में चले। कोई विचार?

# /etc/systemd/system/jekyll-blog.service

[Unit]
Description=Start blog jekyll

[Service]
Type=forking
WorkingDirectory=/home/blog
ExecStart=/usr/local/bin/jekyll build --watch --incremental -s /home/blog -d /var/www/html/blog &
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure
User=root
Group=root

[Install]
WantedBy=multi-user.target

Comments

systemd आपकी प्रक्रिया शुरू कर देगा और यदि आप उपयोग कर रहे हैं तो एक अन्य प्रक्रिया को कांटा करने की अपेक्षा करते हैं Type=forking। इसके अलावा, यह execStartशेल के विस्तार के रूप में नहीं चलेगा , ताकि &अंत में इसे पृष्ठभूमि के झंडे के रूप में कभी नहीं समझा जाएगा।

— grochmal

मेरा बुरा & मुझे यह परीक्षण कर रहा था। तो टाइप सरल होना चाहिए?

— madmanali93

अगर मैं गलती नहीं कर रहा हूँ jekyll एक रेल टाइप चीज़ है, यानी माणिक में एक छोटा सा weby सर्वर। तो हाँ, Type=simpleउचित होगा। इसके अलावा, यह उस तरह का एप्लिकेशन नहीं है जिसे मैं रूट के रूप में चलाऊंगा, कम से कम इंटरनेट फेसिंग मशीन (जो आपका मामला नहीं हो सकता है) पर नहीं।

— grochmal

धन्यवाद हाँ सरल काम किया। इसके अलावा यह कमांड Apache के लिए स्टेटिक html जेनरेट करता है ताकि jekyll सर्वर पर सर्विस न करे। मुझे लगता है कि अगर यह जड़ के रूप में चलता है तो यह ठीक होना चाहिए। यकीन नहीं होता, हालांकि इस पर बहस हो रही थी।

— madmanali93

ओह ठीक है, तो यही है --incremental:)। हाँ, मुझे फ़ाइलों को रूट के रूप में पुनर्जीवित करने में कोई सुरक्षा समस्या नहीं दिख रही है। बेशक, यह देखते हुए कि उन फ़ाइलों की आपूर्ति उपयोगकर्ता नहीं कर रहे हैं।

— grochmal

Answer 1

सिस्टमड विभिन्न प्रकार के विभिन्न प्रकारों को संभालने में सक्षम है, विशेष रूप से निम्न में से एक

• simple - एक लंबी चलने वाली प्रक्रिया जो अपने आप को पृष्ठभूमि नहीं देती है और शेल से जुड़ी रहती है।
• forking - एक विशिष्ट डेमॉन जो खुद को उस प्रक्रिया से अलग करता है जो इसे चलाता है, प्रभावी रूप से खुद को पृष्ठभूमि दे रहा है।
• oneshot - एक अल्पकालिक प्रक्रिया जो बाहर निकलने की उम्मीद है।
• dbus - सरल की तरह, लेकिन स्टार्टअप्स में प्रक्रियाओं की अधिसूचना को डब के ऊपर भेजा जाता है।
• notify - सरल की तरह, लेकिन स्टार्टअप फिनिशिंग की प्रक्रियाओं को नोटिफिकेशन पर भेजा जाता है।
• idle - साधारण की तरह, लेकिन नौकरी शुरू होने के बाद बाइनरी शुरू की गई है।

आपके मामले में आपने उठाया है Type=forkingजिसका अर्थ है कि systemd खुद को कांटे की प्रक्रिया के लिए इंतजार कर रहा है और मूल प्रक्रिया समाप्त होने के लिए, जिसे यह एक संकेत के रूप में लेता है कि प्रक्रिया सफलतापूर्वक शुरू हो गई है। हालांकि, आपकी प्रक्रिया ऐसा नहीं कर रही है - यह अग्रभूमि में बनी हुई है और इसलिए systemctl startअनिश्चित काल तक या प्रक्रियाओं के दुर्घटनाग्रस्त होने तक लटका रहेगा।

इसके बजाय, आप चाहते हैं Type=simple, जो डिफ़ॉल्ट है ताकि आप समान प्रभाव प्राप्त करने के लिए पूरी तरह से लाइन को हटा सकें। इस मोड में सिस्टमैड प्रक्रियाओं के शुरू होने का इंतजार नहीं करता है (क्योंकि यह पता नहीं होता है कि ऐसा कब हुआ है) और इसलिए अभी सीधे निष्पादन और निर्भर सेवाओं को जारी रखता है। आपके मामले में कोई भी नहीं है इसलिए यह कोई मायने नहीं रखता।

सुरक्षा पर एक छोटा नोट:

आप सेवा को रूट के रूप में चला रहे हैं, यह हतोत्साहित किया जाता है क्योंकि यह एक अनपेक्षित उपयोगकर्ता के रूप में चलाने से कम सुरक्षित है। इसका कारण यह है कि अगर जेकिल में भेद्यता है जो किसी तरह आदेशों को निष्पादित करने की अनुमति देता है (संभवतः कोड के माध्यम से इसे पार्स कर रहा है) तो हमलावर को आपके सिस्टम को पूरी तरह से चलाने के लिए और कुछ नहीं करना होगा। यदि, दूसरी ओर, यह एक गैर-विशेषाधिकार प्राप्त उपयोगकर्ता के रूप में चलाया जाता है, तो हमलावर केवल उस उपयोगकर्ता के रूप में अधिक नुकसान करने में सक्षम है और अब आपको अपने सिस्टम को पूरी तरह से चलाने के लिए रूट विशेषाधिकार प्राप्त करने का प्रयास करना चाहिए। यह बस एक अतिरिक्त परत हमलावर जोड़ता है, हालांकि जाना चाहिए।

आप इसे केवल उसी उपयोगकर्ता के रूप में चला सकते हैं जो आपका वेब सर्वर चला रहा है, लेकिन यह आपको एक और संभावित हमले के लिए खुला छोड़ देता है। यदि आपके वेब सर्वर में कोई भेद्यता है, जो उपयोगकर्ता को आपके सिस्टम की फाइलों में हेरफेर करने की अनुमति देता है, तो वे उत्पन्न HTML फ़ाइलों को संशोधित कर सकते हैं, या स्रोत फ़ाइलों को सबसे खराब कर सकते हैं और आपके सर्वर को वे जो भी चाहें सेवा दे सकते हैं। हालाँकि, यदि उत्पन्न की गई फ़ाइलें और स्रोत फ़ाइलें केवल वेबसर्वर द्वारा पठनीय हैं और लिखने योग्य एक अन्य गैर-विशेषाधिकार प्राप्त उपयोगकर्ता हैं, जो वे आसानी से, वेब सर्वर पर हमला करके उन्हें संशोधित नहीं कर पाएंगे।

हालाँकि, यदि आप केवल इस सर्वर से स्थिर फ़ाइलों की सेवा कर रहे हैं और सर्वर को अद्यतित रखते हैं तो इन हमलों की संभावना बहुत कम है - लेकिन फिर भी संभव है। यह आपकी ज़िम्मेदारी है कि आप अपने सिस्टम को कितना गंभीर बना सकते हैं, इसके आधार पर इसे स्थापित करने के जोखिमों को तौलना है। इन दोनों युक्तियों को स्थापित करना बहुत आसान है और बिना रखरखाव ओवरहेड के बगल में।

Answer 2

@ माइकल डफ़िन के समाधान के अलावा, आप निम्न उदाहरण में दिखाए गए उपयोग को प्राप्त करने के लिए डेमनीज़ टूल का भी उपयोग कर सकते हैं forking।

एक छोटी सी शेल स्क्रिप्ट को देखते हुए जिसे मैं डीमॉनेटाइज करना चाहता हूं और जिसे मैं सिस्टमड पर नियंत्रण करना चाहता हूं, मैंने इसे इस प्रकार सहेजा है /home/pi/testscript.sh:

#!/bin/bash

while true;
do
    sleep 1
    echo -n "."
done

यदि आपके पास यह अभी तक नहीं है, तो डेमनीज़ स्थापित करें, जैसे:

sudo apt install daemonize

अब फ़ाइल सेवा परिभाषा फ़ाइल बनाएँ:

sudo vi /etc/systemd/system/testomat.service

# It is not recommended to modify this file in-place, because it will
# be overwritten during package upgrades. If you want to add further
# options or overwrite existing ones then use
# $ systemctl edit testomat.service
# See "man systemd.service" for details.

# copied from https://github.com/bitcoin/bitcoin/blob/master/contrib/init/bitcoind.service and modified by Michael 

[Unit]
Description=Test service
After=network.target

[Service]
ExecStart=daemonize -p /run/testomat/testomat.pid -o /home/pi/testscript.log /home/pi/testscript.sh
TimeoutSec=1200

# Make sure the config directory is readable by the service user
PermissionsStartOnly=true

# Process management
####################
Type=forking
PIDFile=/run/testomat/testomat.pid
Restart=on-failure
GuessMainPID = true

# Directory creation and permissions
####################################

# Run as pi:pi
User=pi
Group=pi

# /run/testomat
RuntimeDirectory=testomat
RuntimeDirectoryMode=0710

# /var/lib/testomat
StateDirectory=testomat
StateDirectoryMode=0710

# Hardening measures
####################

# Provide a private /tmp and /var/tmp.
PrivateTmp=true

# Mount /usr, /boot/ and /etc read-only for the process.
ProtectSystem=full

# Allow access to /home, /root and /run/user
# Chosing "false" is actually no hardening, this is just to demonstrate the usage of a service. Well, I could have omitted it. True. :)
ProtectHome=false

# Disallow the process and all of its children to gain
# new privileges through execve().
NoNewPrivileges=true

# Use a new /dev namespace only populated with API pseudo devices
# such as /dev/null, /dev/zero and /dev/random.
PrivateDevices=true

# Deny the creation of writable and executable memory mappings.
MemoryDenyWriteExecute=true

[Install]
WantedBy=multi-user.target

नई बनाई गई सेवा को सिस्टमड में घोषित करना होगा:

systemctl daemon-reload

अब आप सेवा और स्क्रिप्ट कांटे शुरू कर सकते हैं। जैसा कि अपेक्षित था, सेवा प्रारंभ तुरंत शेल में वापस आती है। परिणाम स्पष्ट है:

$ tail -f testscript.log 
.....................

Comments

सिस्टम शुरू करने और सेवा शुरू करने का ध्यान रखने के बजाय daemonize+ का उपयोग Type=forkingकरने का क्या फायदा है Type=simple? Type=forkingविरासत के समर्थन के लिए systemd में संगतता सेटिंग की तरह है जो कि कांटे पर लिखी जाती है।

— जोहान मायरेन

मुझे लगता है कि यह एक समान समाधान है; मैं सिर्फ ओपी को एक वैकल्पिक समाधान प्रदान करना चाहता था और उसे इस उपकरण से अवगत कराना चाहता था जिसे मैंने /etc/init.d समय में पहले ही उपयोग कर लिया है क्योंकि सवाल यह भी है कि किसी प्रक्रिया को कैसे निपटाया जाए।

— माइकल