סקריפטים וטיימרים מערכתיים ואינטראקטיביים

מבוא

בעת פיתוח עבור לינוקס, מתעוררת המשימה של יצירת סקריפטים אינטראקטיביים המופעלים כאשר המערכת מופעלת או כיבויה. במערכת V זה היה קל, אבל עם systemd זה עושה התאמות. אבל יכול להיות לו טיימרים משלו.

למה אנחנו צריכים מטרות?

לעתים קרובות נכתב שהמטרה משמשת כאנלוגי ל-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). האחרונים מביאים את המערכת לעבודה במצב הרצוי

הכנת הקושחה להפעלה

בעת יצירת קושחה, תמיד מתעוררת המשימה של שחזור מצב המערכת בעת האתחול ושמירתו בעת כיבוי. מצב פירושו קבצי תצורה, dump בסיס נתונים, הגדרות ממשק וכו'.

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. אם לא, הוא נוצר מ-dumps אתחול (כלול עם 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

כפי שאתה יכול לראות, התקנתי תלויות כך שהסקריפט שלי יעבוד קודם, ורק אחר כך הרשת תעלה וה-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 ו-my 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

מה פה:

• תיאור טיימר
• שעת התחלה ראשונה, החל מאתחול המערכת
• תקופה של השקות נוספות
• תלות בשירות הטיימר. למעשה, זו המחרוזת שעושה את הטיימר

סקריפט אינטראקטיבי בעת כיבוי ויעד הכיבוי שלך

בפיתוח אחר, הייתי צריך לעשות גרסה מורכבת יותר של כיבוי המכונה - דרך המטרה שלי, על מנת לבצע פעולות רבות. בדרך כלל מומלץ ליצור שירות oneshot עם אפשרות 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 כדי לקבל גמישות בעבודה וסדר פעולות מובטח.

עם זאת, הדבר המעניין ביותר הגיע מאוחר יותר. יש לכבות/להפעיל מחדש את המכונה. ויש 2 אפשרויות:

• החלף את הפקודות האתחול, הכיבוי ושאר הפקודות (הן עדיין קישורי סימול ל-systemctl) בסקריפט שלך. בתוך הסקריפט, עבור אל my_shutdown.target. והסקריפטים בתוך היעד קוראים ל-systemctl ישירות, למשל, systemctl reboot
• אפשרות פשוטה יותר, אבל אני לא אוהב אותה. בכל הממשקים, אין להתקשר ל-shutdown/reboot/other, אלא לקרוא ישירות למערכת היעד ctl 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