სისტემური, ინტერაქტიული სკრიპტები და ტაიმერები

შესავალი

Linux-ისთვის შემუშავებისას ჩნდება ინტერაქტიული სკრიპტების შექმნის ამოცანა, რომლებიც შესრულდება სისტემის ჩართვის ან გამორთვისას. V system-ში ეს მარტივი იყო, მაგრამ 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-ის არჩევის სხვადასხვა გზა არსებობს, ამისთვის გამოვიყენე loader ვარიანტი.

საბოლოო გაშვება ასე გამოიყურება:

1. ჩამტვირთველი იწყება
2. ჩამტვირთველი იწყებს firmware-ის გაშვებას 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 ფაილის არსებობას მონაცემთა განყოფილებაში. თუ ის იქ არ არის, მაშინ მის ადგილას მოთავსებულია საცნობარო ფაილი. შემდეგ აღდგება სისტემის პარამეტრები:
   • ადმინისტრატორის პაროლი
   • მასპინძლის სახელი,
   • დროის სარტყელი
   • ლოკალი
   • ადგენს, გამოიყენება თუ არა ყველა მედია. ნაგულისხმევად, სურათის ზომა მცირეა - მედიაში კოპირებისა და ჩაწერის გასაადვილებლად. გაშვებისას ის ამოწმებს, არის თუ არა გამოუყენებელი ადგილი. თუ არსებობს, დისკი გადანაწილდება.
   • აპარატის ID-ის გენერირება MAC მისამართიდან. ეს მნიშვნელოვანია DHCP-ით იგივე მისამართის მისაღებად
   • Ქსელის პარამეტრები
   • ზღუდავს მორების ზომას
   • გარე დისკი მზადდება სამუშაოდ (თუ შესაბამისი ვარიანტი ჩართულია და დისკი ახალია)
3. დაიწყეთ postgresq
4. აღდგენის სერვისი იწყება. საჭიროა თავად zabbix-ისა და მისი მონაცემთა ბაზის მოსამზადებლად:
   • ამოწმებს არის თუ არა უკვე zabbix მონაცემთა ბაზა. თუ არა, ის იქმნება ინიციალიზაციის ნაგავსაყრელებიდან (მოყვება zabbix)
   • იქმნება დროის ზონების სია (საჭიროა ვებ ინტერფეისში მათი ჩვენებისთვის)
   • ნაპოვნია ამჟამინდელი IP, ის ნაჩვენებია გამოშვებაში (მოწვევა კონსოლში შესასვლელად)
5. მოწვევა იცვლება - ჩნდება ფრაზა Ready to work
6. firmware მზად არის გამოსაყენებლად

სერვისის ფაილები მნიშვნელოვანია, სწორედ ისინი ადგენენ მათი გაშვების თანმიმდევრობას

[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

აქ ცოტა უფრო რთულია. გაშვება ასევე არის multi-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

რა არის აქ:

• ტაიმერის აღწერა
• პირველი დაწყების დრო, დაწყებული სისტემის ჩატვირთვიდან
• შემდგომი გაშვების პერიოდი
• დამოკიდებულება ტაიმერის სერვისზე. ფაქტობრივად, ეს არის სტრიქონი, რომელიც ქმნის ტაიმერს

ინტერაქტიული სკრიპტი გამორთვისას და თქვენი გამორთვის მიზანი

სხვა განვითარებაში მე მომიწია აპარატის გამორთვის უფრო რთული ვერსიის გაკეთება - ჩემი საკუთარი სამიზნის მეშვეობით, რათა შემესრულებინა მრავალი მოქმედება. ჩვეულებრივ რეკომენდებულია Oneshot სერვისის შექმნა RemainAfterExit ოფციით, მაგრამ ეს ხელს გიშლით ინტერაქტიული სკრიპტის შექმნაში.

მაგრამ ფაქტია, რომ ExecOnStop ვარიანტის მიერ გაშვებული ბრძანებები შესრულებულია TTY-ს გარეთ! ამის შემოწმება მარტივია - ჩასვით tty ბრძანება და შეინახეთ მისი გამომავალი.

ამიტომ, გამორთვა განვახორციელე ჩემი მიზნის მეშვეობით. მე არ ვამტკიცებ, რომ 100% მართალი ვარ, მაგრამ მუშაობს!
როგორ გაკეთდა ეს (ზოგადად):
მე შევქმენი სამიზნე my_shutdown.target, რომელიც არავისზე არ იყო დამოკიდებული:
my_shutdown.სამიზნე

[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

• ამ სკრიპტის შიგნით ვასრულებ საჭირო მოქმედებებს. თქვენ შეგიძლიათ დაამატოთ მრავალი სკრიპტი მიზანში მოქნილობისა და მოხერხებულობისთვის:

ჩემი_გამორთვა.შ

#!/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 გადატვირთვას
• უფრო მარტივი ვარიანტია, მაგრამ არ მომწონს. ყველა ინტერფეისში ნუ გამოიძახებთ shutdown/reboot/other, არამედ პირდაპირ დარეკეთ სამიზნე სისტემასctl isolate my_shutdown.target

მე ავირჩიე პირველი ვარიანტი. systemd-ში გადატვირთვა (როგორც poweroff) არის symlinks 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