सिस्टमडी, इंटरैक्टिव स्क्रिप्ट और टाइमर

परिचय

लिनक्स के लिए विकास करते समय, इंटरैक्टिव स्क्रिप्ट बनाने का कार्य सामने आता है जो सिस्टम चालू या बंद होने पर निष्पादित होती हैं। सिस्टम V में यह आसान था, लेकिन सिस्टमडी के साथ यह समायोजन करता है। लेकिन इसके अपने टाइमर हो सकते हैं।

हमें लक्ष्य की आवश्यकता क्यों है?

यह अक्सर लिखा जाता है कि लक्ष्य सिस्टम V-init में रनलेवल के एनालॉग के रूप में कार्य करता है। मैं बुनियादी तौर पर असहमत हूं. उनमें से अधिक हैं और आप पैकेजों को समूहों में विभाजित कर सकते हैं और, उदाहरण के लिए, एक कमांड के साथ सेवाओं का एक समूह लॉन्च कर सकते हैं और अतिरिक्त क्रियाएं कर सकते हैं। इसके अलावा, उनमें कोई पदानुक्रम नहीं है, केवल निर्भरताएँ हैं।

इंटरैक्टिव स्क्रिप्ट चलाने के साथ सक्षम होने पर लक्ष्य का उदाहरण (सुविधा अवलोकन)।

स्वयं लक्ष्य का विवरण:

cat installer.target
[Unit]
Description=My installer
Requires=multi-user.target 
Conflicts=rescue.service rescue.target
After=multi-user.target rescue.service rescue.target 
AllowIsolate=yes
Wants=installer.service

यह लक्ष्य तब प्रारंभ होगा जब मल्टी-यूजर.टारगेट लॉन्च किया जाएगा और इंस्टॉलर.सर्विस को कॉल किया जाएगा। हालाँकि, ऐसी कई सेवाएँ हो सकती हैं।

cat installer.service
[Unit]
# описание
Description=installer interactive dialog

[Service]
# Запустить один раз, когда остальное будет запущенно
Type=idle
# Команда запуска - вызов скрипта
ExecStart=/usr/bin/installer.sh
# Интерактивное взаимодействие с пользователем через tty3
StandardInput=tty
TTYPath=/dev/tty3
TTYReset=yes
TTYVHangup=yes

[Install]
WantedBy=installer.target

और अंत में, निष्पादित की जा रही स्क्रिप्ट का एक उदाहरण:

#!/bin/bash
# Переходим в tty3
chvt 3
echo "Install, y/n ?"
read user_answer

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

अंतिम लॉन्च इस तरह दिखता है:

1. बूटलोडर प्रारंभ होता है
2. बूटलोडर फाइनल.टारगेट पैरामीटर पास करके फर्मवेयर लॉन्च करना शुरू करता है
3. Systemd सिस्टम प्रारंभ करना प्रारंभ करता है. क्रमिक रूप से उनकी निर्भरता (उदाहरण के लिए, मल्टी-यूजर.टार्गेट) के माध्यम से basic.target से installer.target या Work.target पर जाता है। उत्तरार्द्ध सिस्टम को वांछित मोड में काम करने के लिए लाता है

लॉन्च के लिए फर्मवेयर तैयार करना

फ़र्मवेयर बनाते समय, स्टार्टअप पर सिस्टम स्थिति को पुनर्स्थापित करने और बंद होने पर इसे सहेजने का कार्य हमेशा उठता है। राज्य का अर्थ है कॉन्फ़िगरेशन फ़ाइलें, डेटाबेस डंप, इंटरफ़ेस सेटिंग्स इत्यादि।

Systemd समान लक्ष्य में समानांतर में प्रक्रियाएँ चलाता है। ऐसी निर्भरताएँ हैं जो आपको स्क्रिप्ट के स्टार्टअप अनुक्रम को निर्धारित करने की अनुमति देती हैं।

यह मेरे प्रोजेक्ट में कैसे काम करता है ( https://habr.com/ru/post/477008/ https://github.com/skif-web/monitor)

1. सिस्टम शुरू होता है
2. सेटिंग्स_रिस्टोर.सर्विस सेवा लॉन्च की गई है। यह डेटा अनुभाग में सेटिंग्स.txt फ़ाइल की उपस्थिति की जाँच करता है। यदि यह वहां नहीं है, तो इसके स्थान पर एक संदर्भ फ़ाइल रखी जाती है। इसके बाद, सिस्टम सेटिंग्स पुनर्स्थापित की जाती हैं:
   • पासवर्ड व्यवस्थापक
   • होस्टनाम,
   • समय क्षेत्र
   • स्थान
   • यह निर्धारित करता है कि क्या सभी मीडिया का उपयोग किया जा रहा है। डिफ़ॉल्ट रूप से, छवि का आकार छोटा होता है - मीडिया में कॉपी करने और रिकॉर्ड करने में आसानी के लिए। स्टार्टअप पर, यह यह देखने के लिए जाँच करता है कि क्या अभी भी अप्रयुक्त स्थान है। यदि है, तो डिस्क पुनः विभाजित हो जाती है।
   • मैक पते से मशीन-आईडी उत्पन्न करना। डीएचसीपी के माध्यम से समान पता प्राप्त करने के लिए यह महत्वपूर्ण है
   • नेटवर्क सेटिंग
   • लॉग का आकार सीमित करता है
   • बाहरी ड्राइव को काम के लिए तैयार किया जा रहा है (यदि संबंधित विकल्प सक्षम है और ड्राइव नई है)
3. पोस्टग्रैस्क प्रारंभ करें
4. पुनर्स्थापना सेवा प्रारंभ होती है. ज़ैबिक्स और उसके डेटाबेस को तैयार करने के लिए इसकी आवश्यकता है:
   • जाँचता है कि क्या पहले से ही ज़ैबिक्स डेटाबेस मौजूद है। यदि नहीं, तो इसे इनिशियलाइज़ेशन डंप (ज़ैबिक्स के साथ शामिल) से बनाया गया है
   • समय क्षेत्रों की एक सूची बनाई गई है (उन्हें वेब इंटरफ़ेस में प्रदर्शित करने की आवश्यकता है)
   • वर्तमान आईपी मिल गया है, इसे अंक में प्रदर्शित किया गया है (कंसोल में लॉग इन करने के लिए निमंत्रण)
5. निमंत्रण बदल जाता है - काम करने के लिए तैयार वाक्यांश प्रकट होता है
6. फ़र्मवेयर उपयोग के लिए तैयार है

सेवा फ़ाइलें महत्वपूर्ण हैं, वे ही उनके लॉन्च का क्रम निर्धारित करती हैं

[Unit]
Description=restore system settings
Before=network.service prepare.service postgresql.service systemd-networkd.service systemd-resolved.service

[Service]
Type=oneshot
ExecStart=/usr/bin/settings_restore.sh

[Install]
WantedBy=multi-user.target

जैसा कि आप देख सकते हैं, मैंने निर्भरताएँ स्थापित कीं ताकि मेरी स्क्रिप्ट पहले काम करे, और उसके बाद ही नेटवर्क ऊपर जाए और DBMS शुरू हो।

और दूसरी सेवा (ज़ैबिक्स तैयारी)

#!/bin/sh
[Unit]
Description=monitor prepare system
After=postgresql.service settings_restore.service
Before=zabbix-server.service zabbix-agent.service

[Service]
Type=oneshot
ExecStart=/usr/bin/prepare.sh

[Install]
WantedBy=multi-user.target

यहां यह थोड़ा अधिक जटिल है। लॉन्च मल्टी-यूजर.टारगेट में भी है, लेकिन पोस्टग्रेस्क्ल डीबीएमएस और मेरी सेटिंग_रेस्टोर शुरू करने के बाद। लेकिन ज़ैबिक्स सेवाएँ शुरू करने से पहले।

लॉगरोटेट के लिए टाइमर सेवा

Systemd CRON की जगह ले सकता है। गंभीरता से। इसके अलावा, सटीकता मिनट तक नहीं, बल्कि सेकंड तक होती है (यदि इसकी आवश्यकता हो तो क्या होगा)। या आप एक नीरस टाइमर बना सकते हैं, जिसे किसी ईवेंट से टाइमआउट द्वारा बुलाया जाता है।
यह नीरस टाइमर था जो मेरे द्वारा बनाई गई मशीन की शुरुआत से समय की गणना करता है।
इसके लिए 2 फाइलों की आवश्यकता होगी
logrotateTimer.service - सेवा का वास्तविक विवरण:

[Unit]
Description=run logrotate

[Service]
ExecStart=logrotate /etc/logrotate.conf
TimeoutSec=300

यह सरल है - लॉन्च कमांड का विवरण।
दूसरी फ़ाइल logrotateTimer.timer वह जगह है जहां टाइमर काम करते हैं:

[Unit]
Description=Run logrotate

[Timer]
OnBootSec=15min
OnUnitActiveSec=15min

[Install]
WantedBy=timers.target

यहां क्या है:

• टाइमर विवरण
• पहला प्रारंभ समय, सिस्टम बूट से प्रारंभ करते हुए
• आगे के प्रक्षेपण की अवधि
• टाइमर सेवा पर निर्भरता। वास्तव में, यह वह स्ट्रिंग है जो टाइमर बनाती है

शट डाउन करते समय इंटरएक्टिव स्क्रिप्ट और आपका शटडाउन लक्ष्य

एक अन्य विकास में, मुझे कई कार्य करने के लिए, अपने लक्ष्य के माध्यम से - मशीन को बंद करने का एक और अधिक जटिल संस्करण करना पड़ा। आमतौर पर RemainAfterExit विकल्प के साथ वनशॉट सेवा बनाने की अनुशंसा की जाती है, लेकिन यह आपको एक इंटरैक्टिव स्क्रिप्ट बनाने से रोकता है।

लेकिन तथ्य यह है कि ExecOnStop विकल्प द्वारा लॉन्च किए गए कमांड TTY के बाहर निष्पादित होते हैं! इसे जांचना आसान है - tty कमांड पेस्ट करें और उसका आउटपुट सेव करें।

इसलिए, मैंने अपने लक्ष्य के माध्यम से शटडाउन लागू किया। मैं 100% सही होने का दावा नहीं करता, लेकिन यह काम करता है!
यह कैसे किया गया (सामान्य शब्दों में):
मैंने एक लक्ष्य my_shutdown.target बनाया, जो किसी पर निर्भर नहीं था:
मेरा_शटडाउन.लक्ष्य

[Unit]
Description=my shutdown
AllowIsolate=yes
Wants=my_shutdown.service 

इस लक्ष्य पर जाने पर (systemctl isolat my_shutdwn.target के माध्यम से), इसने my_shutdown.service सेवा लॉन्च की, जिसका कार्य सरल है - my_shutdown.sh स्क्रिप्ट को निष्पादित करना:

[Unit]
Description=MY shutdown

[Service]
Type=oneshot
ExecStart=/usr/bin/my_shutdown.sh
StandardInput=tty
TTYPath=/dev/tty3
TTYReset=yes
TTYVHangup=yes

WantedBy=my_shutdown.target

• इस स्क्रिप्ट के अंदर मैं आवश्यक क्रियाएं निष्पादित करता हूं। लचीलेपन और सुविधा के लिए आप लक्ष्य में कई स्क्रिप्ट जोड़ सकते हैं:

my_shutdown.sh

#!/bin/bash --login
if [ -f /tmp/reboot ];then
    command="systemctl reboot"
elif [ -f /tmp/shutdown ]; then
    command="systemctl poweroff"
fi
#Вот здесь нужные команды
#Например, cp /home/user/data.txt /storage/user/
    $command

टिप्पणी। /tmp/reboot और /tmp/shutdown फ़ाइलों का उपयोग करना। आप पैरामीटर के साथ लक्ष्य को कॉल नहीं कर सकते। सेवा ही संभव है.

लेकिन मैं काम में लचीलेपन और कार्यों के गारंटीकृत क्रम के लिए लक्ष्य का उपयोग करता हूं।

हालाँकि, सबसे दिलचस्प बात बाद में आई। मशीन को बंद/पुनः चालू करने की आवश्यकता है। और 2 विकल्प हैं:

• रिबूट, शटडाउन और अन्य कमांड (वे अभी भी systemctl के लिए सिम्लिंक हैं) को अपनी स्क्रिप्ट से बदलें। स्क्रिप्ट के अंदर, my_shutdown.target पर जाएं। और लक्ष्य के अंदर की स्क्रिप्ट सीधे systemctl को कॉल करती हैं, उदाहरण के लिए, systemctl रिबूट
• एक आसान विकल्प, लेकिन मुझे यह पसंद नहीं है. सभी इंटरफ़ेस में, शटडाउन/रिबूट/अन्य को कॉल न करें, बल्कि सीधे लक्ष्य systemctl को कॉल करें, अलग करें my_shutdown.target

मैंने पहला विकल्प चुना. सिस्टमडी में, रीबूट (पॉवरऑफ़ की तरह) सिस्टमडी के प्रति सहानुभूति है।

ls -l /sbin/poweroff 
lrwxrwxrwx 1 root root 14 сен 30 18:23 /sbin/poweroff -> /bin/systemctl

इसलिए, आप उन्हें अपनी स्क्रिप्ट से बदल सकते हैं:
रिबूट

#!/bin/sh
    touch /tmp/reboot
    sudo systemctl isolate my_shutdown.target
fi

स्रोत: www.habr.com