Systemd, интерактивни скриптове и таймери

въведение

При разработката за Linux възниква задачата за създаване на интерактивни скриптове, които се изпълняват при включване или изключване на системата. В system V това беше лесно, но със systemd прави корекции. Но може да има свои собствени таймери.

Защо се нуждаем от цели?

Често се пише, че target служи като аналог на runlevel в системата 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 в секцията с данни. Ако не е там, тогава на мястото му се поставя референтен файл След това системните настройки се възстановяват:
   • администраторска парола
   • име на хост,
   • часова зона
   • локал
   • Определя дали се използват всички носители. По подразбиране размерът на изображението е малък - за лесно копиране и запис на носител. При стартиране той проверява дали все още има неизползвано място. Ако има, дискът се преразделя.
   • Генериране на идентификатор на машина от MAC адрес. Това е важно за получаване на същия адрес чрез DHCP
   • Мрежови настройки
   • Ограничава размера на трупите
   • Външното устройство се подготвя за работа (ако съответната опция е активирана и устройството е ново)
3. Стартирайте postgresq
4. Услугата за възстановяване стартира. Необходимо е да подготвите самия zabbix и неговата база данни:
   • Проверява дали вече има zabbix база данни. Ако не, той се създава от дъмпове за инициализация (включени със zabbix)
   • създава се списък с часови зони (необходими за показването им в уеб интерфейса)
   • Текущият IP е намерен, той се показва в проблем (покана за влизане в конзолата)
5. Поканата се променя - появява се фразата Ready to work
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

Както можете да видите, инсталирах зависимости, така че моят скрипт първо да работи и едва след това мрежата да се качи и СУБД да стартира.

И втората услуга (подготовка на 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.

Таймер услуга за logrotate

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. Не можете да извиквате target с параметри. Възможен е само сервиз.

Но използвам target, за да имам гъвкавост в работата и гарантиран ред на действията.

Най-интересното обаче дойде по-късно. Машината трябва да се изключи/рестартира. И има 2 опции:

• Заменете командите за рестартиране, изключване и други (те все още са символни връзки към systemctl) с вашия скрипт. Вътре в скрипта отидете на my_shutdown.target. И скриптовете вътре в целта след това извикват директно systemctl, например systemctl reboot
• По-прост вариант, но не ми харесва. Във всички интерфейси не извиквайте shutdown/reboot/other, а директно извикайте целевия systemctl isolate my_shutdown.target

Избрах първия вариант. В systemd рестартирането (като poweroff) са символни връзки към 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