سسٹمڈ، انٹرایکٹو اسکرپٹس اور ٹائمر

تعارف

لینکس کے لیے تیار کرتے وقت، انٹرایکٹو اسکرپٹس بنانے کا کام جو سسٹم کے آن یا بند ہونے پر عمل میں آتا ہے۔ سسٹم 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 یا work.target پر ان کے انحصار کے ذریعے basic.target سے جاتا ہے (مثال کے طور پر، multi-user.target)۔ مؤخر الذکر نظام کو مطلوبہ موڈ میں کام کرنے کے لیے لاتے ہیں۔

لانچ کے لیے فرم ویئر کی تیاری

فرم ویئر بناتے وقت، کام ہمیشہ شروع ہونے پر سسٹم کی حالت کو بحال کرنے اور بند ہونے پر اسے محفوظ کرنے کا ہوتا ہے۔ اسٹیٹ کا مطلب ہے کنفیگریشن فائلز، ڈیٹا بیس ڈمپ، انٹرفیس سیٹنگز وغیرہ۔

Systemd متوازی طور پر ایک ہی ہدف میں عمل چلاتا ہے۔ ایسے انحصار ہیں جو آپ کو اسکرپٹس کے آغاز کی ترتیب کا تعین کرنے کی اجازت دیتے ہیں۔

یہ میرے پروجیکٹ میں کیسے کام کرتا ہے ( https://habr.com/ru/post/477008/ https://github.com/skif-web/monitor)

1. نظام شروع ہوتا ہے۔
2. settings_restore.service سروس شروع کی گئی ہے۔ یہ ڈیٹا سیکشن میں settings.txt فائل کی موجودگی کو چیک کرتی ہے۔ اگر یہ وہاں نہیں ہے، تو اس کی جگہ ایک حوالہ فائل رکھی جاتی ہے، اس کے بعد، نظام کی ترتیبات کو بحال کیا جاتا ہے:
   • ایڈمنسٹریٹر پاس ورڈ
   • میزبان کا نام،
   • ٹائم زون
   • مقامی
   • اس بات کا تعین کرتا ہے کہ آیا تمام میڈیا استعمال ہو رہا ہے۔ پہلے سے طے شدہ طور پر، تصویر کا سائز چھوٹا ہوتا ہے - میڈیا پر کاپی کرنے اور ریکارڈ کرنے میں آسانی کے لیے۔ آغاز پر، یہ چیک کرتا ہے کہ آیا اب بھی غیر استعمال شدہ جگہ موجود ہے۔ اگر وہاں ہے تو، ڈسک کو دوبارہ تقسیم کیا جاتا ہے.
   • میک ایڈریس سے مشین آئی ڈی تیار کرنا۔ DHCP کے ذریعے ایک ہی پتہ حاصل کرنے کے لیے یہ ضروری ہے۔
   • نیٹ ورک کی ترتیبات
   • لاگز کے سائز کو محدود کرتا ہے۔
   • بیرونی ڈرائیو کام کے لیے تیار کی جا رہی ہے (اگر متعلقہ آپشن فعال ہو اور ڈرائیو نئی ہو)
3. پوسٹگریسق شروع کریں۔
4. بحالی سروس شروع ہوتی ہے۔ زبکس خود اور اس کا ڈیٹا بیس تیار کرنے کے لیے ضروری ہے:
   • چیک کرتا ہے کہ آیا پہلے سے زبکس ڈیٹا بیس موجود ہے۔ اگر نہیں، تو یہ ابتدائی ڈمپ سے بنایا گیا ہے (زبکس کے ساتھ شامل ہے)
   • ٹائم زونز کی ایک فہرست بنائی گئی ہے (انہیں ویب انٹرفیس میں ظاہر کرنے کی ضرورت ہے)
   • موجودہ 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 شروع ہوگا۔

اور دوسری سروس (زبکس تیاری)

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

یہ یہاں کچھ زیادہ ہی پیچیدہ ہے۔ لانچ بھی multi-user.target میں ہے، لیکن postgresql DBMS اور my 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/reboot اور /tmp/shutdown فائلوں کا استعمال۔ آپ پیرامیٹرز کے ساتھ ہدف کو کال نہیں کر سکتے ہیں۔ صرف خدمت ممکن ہے۔

لیکن میں ٹارگٹ کا استعمال کام میں لچک اور عمل کی ضمانت شدہ ترتیب کے لیے کرتا ہوں۔

تاہم سب سے دلچسپ بات بعد میں سامنے آئی۔ مشین کو بند/دوبارہ شروع کرنے کی ضرورت ہے۔ اور 2 اختیارات ہیں:

• اپنے اسکرپٹ کے ساتھ ریبوٹ، شٹ ڈاؤن اور دیگر کمانڈز (وہ اب بھی سسٹم سی ٹی ایل کے سیملنک ہیں) کو تبدیل کریں۔ اسکرپٹ کے اندر، my_shutdown.target پر جائیں۔ اور ہدف کے اندر موجود اسکرپٹ پھر systemctl کو براہ راست کال کریں، مثال کے طور پر systemctl reboot
• ایک آسان آپشن، لیکن مجھے یہ پسند نہیں ہے۔ تمام انٹرفیس میں، شٹ ڈاؤن/ریبوٹ/دیگر کو کال نہ کریں، بلکہ ٹارگٹ سسٹم سی ٹی ایل آئیسولیٹ 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