Kerfisbundin, gagnvirk forskrift og tímamælir

Kerfisbundin, gagnvirk forskrift og tímamælir

Inngangur

Þegar verið er að þróa fyrir Linux kemur upp það verkefni að búa til gagnvirka forskriftir sem eru keyrðar þegar kveikt er á kerfinu eða það lokað. Í kerfi V var þetta auðvelt, en með systemd gerir það breytingar. En það getur haft sína eigin tímamæla.

Af hverju þurfum við markmið?

Það er oft skrifað að skotmark virki sem hliðstæða runlevel í kerfi V -init. Ég er í grundvallaratriðum ósammála. Þær eru fleiri og hægt er að skipta pökkum í hópa og td ræsa þjónustuhóp með einni skipun og framkvæma viðbótaraðgerðir. Þar að auki hafa þeir ekkert stigveldi, aðeins ósjálfstæði.

Dæmi um markmið þegar það er virkt (eiginleikayfirlit) með gagnvirku skriftu í gangi

Lýsing á skotmarkinu sjálfu:

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

Þetta mark mun hefjast þegar multi-user.target er ræst og kallar installer.service. Hins vegar getur verið um nokkrar slíkar þjónustur að ræða.

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

Og að lokum, dæmi um handritið sem er keyrt:

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

Mikilvægast er að velja final.target - markmiðið sem kerfið á að ná til við ræsingu. Meðan á ræsingarferlinu stendur mun systemd fara í gegnum ósjálfstæðin og ræsa allt sem það þarf.
Það eru mismunandi leiðir til að velja final.target, ég notaði hleðsluvalkostinn fyrir þetta.

Lokakynningin lítur svona út:

  1. Bootloader byrjar
  2. Bootloader byrjar að ræsa fastbúnaðinn með því að senda final.target færibreytuna
  3. Systemd byrjar að ræsa kerfið. Fer í röð til installer.target eða work.target frá basic.target í gegnum ósjálfstæði þeirra (til dæmis multi-user.target). Síðarnefndu koma kerfinu til að vinna í æskilegum ham

Undirbýr vélbúnaðinn fyrir ræsingu

Þegar þú býrð til fastbúnað kemur alltaf upp það verkefni að endurheimta kerfisstöðu við ræsingu og vista það þegar slökkt er á. Ríki þýðir stillingarskrár, gagnagrunnsupplýsingar, viðmótsstillingar osfrv.

Systemd keyrir ferla í sama markmiði samhliða. Það eru ósjálfstæði sem gera þér kleift að ákvarða ræsingarröð skrifta.

Hvernig virkar það í verkefninu mínu ( https://habr.com/ru/post/477008/ https://github.com/skif-web/monitor)

  1. Kerfið fer í gang
  2. Settings_restore.service þjónustan er opnuð. Hún athugar hvort settings.txt skráin sé til staðar í gagnahlutanum. Ef það er ekki til staðar þá er tilvísunarskrá sett í staðinn. Næst eru kerfisstillingar endurheimtar:
    • lykilorð stjórnanda
    • hýsingarheiti
    • Tímabelti
    • staðsetning
    • Ákveður hvort allir miðlar séu notaðir. Sjálfgefið er að myndastærðin er lítil - til að auðvelda afritun og upptöku á miðil. Við ræsingu athugar það hvort það sé enn ónotað pláss. Ef svo er er diskurinn skipt í skiptingu aftur.
    • Býr til vélauðkenni frá MAC vistfangi. Þetta er mikilvægt til að fá sama heimilisfang í gegnum DHCP
    • Netstillingar
    • Takmarkar stærð annála
    • Verið er að undirbúa ytri drifið fyrir vinnu (ef samsvarandi valkostur er virkur og drifið er nýtt)
  3. Byrjaðu á postgresq
  4. Endurheimtunarþjónustan byrjar. Það er nauðsynlegt til að undirbúa zabbix sjálft og gagnagrunn þess:
    • Athugar hvort það sé nú þegar zabbix gagnagrunnur. Ef ekki, þá er það búið til úr frumstillingardumpum (fylgir með zabbix)
    • listi yfir tímabelti er búinn til (þarf til að birta þau í vefviðmótinu)
    • Núverandi IP er fundin, hún birtist í útgáfu (boð um að skrá þig inn á stjórnborðið)
  5. Boðið breytist - setningin Tilbúinn til vinnu birtist
  6. Fastbúnaðurinn er tilbúinn til notkunar

Þjónustuskrárnar eru mikilvægar, þær eru þær sem stilla röð ræsingar þeirra

[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

Eins og þú sérð setti ég upp ósjálfstæði svo að handritið mitt myndi fyrst virka, og aðeins þá myndi netið fara upp og DBMS myndi byrja.

Og önnur þjónustan (zabbix undirbúningur)

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

Þetta er aðeins flóknara hér. Opnunin er líka í multi-user.target, en EFTIR að postgresql DBMS og setting_restore mínar eru ræstir. En ÁÐUR en þú byrjar zabbix þjónustu.

Tímamælirþjónusta fyrir logrotate

Systemd getur komið í stað CRON. Í alvöru. Þar að auki er nákvæmnin ekki allt að mínútu heldur allt að sekúndu (hvað ef það er þörf) Eða þú getur búið til einhæfan tímamæli sem hringt er í með tímamörkum frá atburði.
Það var einhæfi tímamælirinn sem telur tímann frá upphafi vélarinnar sem ég bjó til.
Þetta mun þurfa 2 skrár
logrotateTimer.service - raunveruleg lýsing á þjónustunni:

[Unit]
Description=run logrotate

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

Það er einfalt - lýsing á sjósetningarskipuninni.
Önnur skráin logrotateTimer.timer er þar sem tímamælarnir virka:

[Unit]
Description=Run logrotate

[Timer]
OnBootSec=15min
OnUnitActiveSec=15min

[Install]
WantedBy=timers.target

Hvað er hér:

  • lýsing á tímamæli
  • Fyrsti upphafstími, frá ræsingu kerfisins
  • tímabil frekari kynninga
  • Háð tímamælisþjónustunni. Í raun er þetta strengurinn sem gerir tímamælirinn

Gagnvirkt handrit þegar slökkt er á og lokunarmarkmiðið þitt

Í annarri þróun þurfti ég að gera flóknari útgáfu af því að slökkva á vélinni - í gegnum mitt eigið skotmark, til að framkvæma margar aðgerðir. Venjulega er mælt með því að búa til oneshot þjónustu með valkostinum RemainAfterExit, en þetta kemur í veg fyrir að þú búir til gagnvirkt handrit.

En staðreyndin er sú að skipanirnar sem ExecOnStop valkosturinn hefur sett af stað eru keyrðar utan TTY! Það er auðvelt að athuga það - límdu tty skipunina og vistaðu úttak hennar.

Þess vegna innleiddi ég lokunina í gegnum markmið mitt. Ég segist ekki vera 100% rétt, en það virkar!
Hvernig það var gert (almennt séð):
Ég bjó til target my_shutdown.target, sem var ekki háð neinum:
my_shutdown.target

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

Þegar farið er að þessu markmiði (í gegnum systemctl isolate my_shutdwn.target), ræsti það þjónustuna my_shutdown.service, en verkefni hennar er einfalt - að keyra my_shutdown.sh forskriftina:

[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

  • Inni í þessu handriti framkvæmi ég nauðsynlegar aðgerðir. Þú getur bætt mörgum skriftum við markið fyrir sveigjanleika og þægindi:

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

Athugið. Notaðu /tmp/reboot og /tmp/shutdown skrárnar. Þú getur ekki hringt í target með breytum. Aðeins þjónusta er möguleg.

En ég nota target til að hafa sveigjanleika í vinnu og tryggða röð aðgerða.

Það áhugaverðasta kom þó síðar. Það þarf að slökkva/endurræsa vélina. Og það eru 2 valkostir:

  • Skiptu um endurræsingu, shutdown og aðrar skipanir (þær eru enn tákntenglar á systemctl) fyrir skriftuna þína. Inni í scriptinu skaltu fara á my_shutdown.target. Og forskriftirnar inni í markinu kalla síðan systemctl beint, til dæmis, systemctl endurræsa
  • Einfaldari kostur, en mér líkar hann ekki. Í öllum viðmótum skaltu ekki hringja í shutdown/reboot/other, heldur hringja beint í markkerfið ctl isolate my_shutdown.target

Ég valdi fyrsta kostinn. Í systemd, endurræsa (eins og poweroff) eru tákntenglar á systemd.

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

Þess vegna geturðu skipt þeim út fyrir eigin forskriftir:
endurræsa

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

Heimild: www.habr.com

Bæta við athugasemd