सिस्टम्ड, परस्परसंवादी स्क्रिप्ट आणि टाइमर

परिचय

लिनक्ससाठी विकसित करताना, सिस्टीम चालू किंवा बंद केल्यावर अंमलात आणल्या जाणार्‍या परस्परसंवादी स्क्रिप्ट तयार करण्याचे कार्य उद्भवते. सिस्टम V मध्ये हे सोपे होते, परंतु systemd सह ते समायोजन करते. पण त्याचे स्वतःचे टाइमर असू शकतात.

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

असे अनेकदा लिहिले जाते की टार्गेट हे सिस्टम 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

जेव्हा multi-user.target लाँच होईल आणि 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

सर्वात महत्वाची गोष्ट म्हणजे final.target निवडणे - सिस्टम स्टार्टअपच्या वेळी ज्या लक्ष्यापर्यंत पोहोचले पाहिजे. स्टार्टअप प्रक्रियेदरम्यान, systemd अवलंबित्वांमधून जाईल आणि आवश्यक असलेल्या सर्व गोष्टी लाँच करेल.
final.target निवडण्याचे वेगवेगळे मार्ग आहेत, यासाठी मी लोडर पर्याय वापरला.

अंतिम प्रक्षेपण असे दिसते:

1. बूटलोडर सुरू होते
2. बूटलोडर final.target पॅरामीटर पार करून फर्मवेअर लाँच करण्यास सुरवात करतो
3. Systemd प्रणाली सुरू करण्यास सुरुवात करते. अनुक्रमे installer.target किंवा base.target वरून work.target वर त्यांच्या अवलंबनांद्वारे जाते (उदाहरणार्थ, multi-user.target). नंतरचे सिस्टमला इच्छित मोडमध्ये कार्य करण्यासाठी आणते

लॉन्चसाठी फर्मवेअर तयार करत आहे

फर्मवेअर तयार करताना, स्टार्टअपच्या वेळी सिस्टम स्थिती पुनर्संचयित करणे आणि बंद करताना ते जतन करण्याचे कार्य नेहमीच उद्भवते. स्टेट म्हणजे कॉन्फिगरेशन फाइल्स, डेटाबेस डंप, इंटरफेस सेटिंग्ज इ.

Systemd समान लक्ष्यामध्ये समांतरपणे प्रक्रिया चालवते. अशी अवलंबित्वे आहेत जी तुम्हाला स्क्रिप्टचा स्टार्टअप क्रम निर्धारित करण्यास परवानगी देतात.

माझ्या प्रकल्पात ते कसे कार्य करते ( https://habr.com/ru/post/477008/ https://github.com/skif-web/monitor)

1. यंत्रणा सुरू होते
2. settings_restore.service सेवा सुरू केली आहे. ती डेटा विभागात settings.txt फाइलची उपस्थिती तपासते. जर ते तेथे नसेल, तर त्याच्या जागी एक संदर्भ फाइल ठेवली जाते. पुढे, सिस्टम सेटिंग्ज पुनर्संचयित केली जातात:
   • प्रशासक पासवर्ड
   • होस्टनाव,
   • वेळ क्षेत्र
   • लोकॅल
   • सर्व माध्यमांचा वापर केला जात आहे की नाही हे निर्धारित करते. डीफॉल्टनुसार, प्रतिमेचा आकार लहान असतो - मीडियावर कॉपी आणि रेकॉर्डिंग सुलभतेसाठी. स्टार्टअपवर, ते अजूनही न वापरलेली जागा आहे का ते तपासते. तेथे असल्यास, डिस्कचे पुनर्विभाजन केले जाते.
   • MAC पत्त्यावरून मशीन-आयडी तयार करत आहे. DHCP द्वारे समान पत्ता प्राप्त करण्यासाठी हे महत्वाचे आहे
   • नेटवर्क सेटिंग्ज
   • लॉगचा आकार मर्यादित करतो
   • बाह्य ड्राइव्ह कामासाठी तयार केली जात आहे (संबंधित पर्याय सक्षम असल्यास आणि ड्राइव्ह नवीन असल्यास)
3. पोस्टग्रेस्क सुरू करा
4. पुनर्संचयित सेवा सुरू होते. zabbix स्वतः आणि त्याचा डेटाबेस तयार करण्यासाठी हे आवश्यक आहे:
   • आधीच zabbix डेटाबेस आहे का ते तपासते. नसल्यास, ते इनिशिएलायझेशन डंपमधून तयार केले जाते (झॅबिक्ससह)
   • टाइम झोनची सूची तयार केली आहे (ते वेब इंटरफेसमध्ये प्रदर्शित करण्यासाठी आवश्यक आहे)
   • वर्तमान IP सापडला आहे, तो समस्येमध्ये प्रदर्शित केला जातो (कन्सोलमध्ये लॉग इन करण्यासाठी आमंत्रण)
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 सुरू होईल.

आणि दुसरी सेवा (zabbix तयारी)

#!/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

हे येथे थोडे अधिक क्लिष्ट आहे. लॉन्च मल्टी-user.target मध्ये देखील आहे, परंतु postgresql DBMS आणि माझे setting_restore सुरू केल्यानंतर. पण zabbix सेवा सुरू करण्यापूर्वी.

लॉगरोटेटसाठी टाइमर सेवा

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 लक्ष्य तयार केले, जे कोणावरही अवलंबून नव्हते:
my_shutdown.target

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

या लक्ष्याकडे जाताना (systemctl isolate 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/रीबूट आणि /tmp/शटडाउन फाइल्स वापरणे. आपण पॅरामीटर्ससह लक्ष्य कॉल करू शकत नाही. फक्त सेवा शक्य आहे.

परंतु मी कामात लवचिकता आणि कृतींचा हमी क्रम मिळवण्यासाठी लक्ष्य वापरतो.

तथापि, सर्वात मनोरंजक गोष्ट नंतर आली. मशीन बंद/रीस्टार्ट करणे आवश्यक आहे. आणि 2 पर्याय आहेत:

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

मी पहिला पर्याय निवडला. systemd मध्ये, रीबूट (पॉवरऑफ सारखे) हे systemd चे सिमलिंक आहेत.

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