Systemd、対話型スクリプトとタイマー

導入

Linux 向けに開発する場合、システムの電源投入時またはシャットダウン時に実行される対話型スクリプトを作成するタスクが発生します。 system V ではこれは簡単でしたが、systemd では調整が必要になります。 ただし、独自のタイマーを持つこともできます。

なぜ目標が必要なのでしょうか?

ターゲットはシステム V -init のランレベルに相当するものとして機能するとよく書かれています。 私は基本的に同意しません。 それらはさらに多くあり、パッケージをグループに分割し、たとえば XNUMX つのコマンドでサービスのグループを起動し、追加のアクションを実行することができます。 さらに、それらには階層がなく、依存関係のみがあります。

対話型スクリプトを実行して有効にした場合のターゲットの例 (機能の概要)

ターゲット自体の説明:

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 がシステムの起動を開始します。 依存関係 (たとえば、multi-user.target) を介して、basic.target から installer.target または work.target に順次移動します。 後者は、システムを希望のモードで動作させます。

ファームウェアの起動準備

ファームウェアを作成するときは、起動時にシステム状態を復元し、シャットダウン時にそれを保存するというタスクが常に発生します。 状態とは、構成ファイル、データベース ダンプ、インターフェイス設定などを意味します。

Systemd は、同じターゲット内のプロセスを並行して実行します。 スクリプトの起動シーケンスを決定できる依存関係があります。

私のプロジェクトではどのように機能しますか( https://habr.com/ru/post/477008/ https://github.com/skif-web/monitor)

1. システムが起動します
2. settings_restore.service サービスが起動され、データ セクションに settings.txt ファイルが存在するかどうかがチェックされます。 そこにない場合は、参照ファイルがその場所に配置され、次にシステム設定が復元されます。
   • 管理者パスワード
   • ホスト名、
   • タイムゾーン
   • ロケール
   • すべてのメディアが使用されているかどうかを判断します。 デフォルトでは、メディアへのコピーや記録を容易にするため、画像サイズは小さくなっています。 起動時に、未使用のスペースがまだあるかどうかを確認します。 存在する場合、ディスクは再パーティション化されます。
   • MAC アドレスからマシン ID を生成します。 これは、DHCP 経由で同じアドレスを取得するために重要です。
   • ネットワーク設定
   • ログのサイズを制限します
   • 外部ドライブは作業用に準備中です (対応するオプションが有効で、ドライブが新しい​​場合)
3. postgresqを開始する
4. 復元サービスが開始されます。 zabbix 自体とそのデータベースを準備する必要があります。
   • zabbix データベースがすでに存在するかどうかを確認します。 そうでない場合は、初期化ダンプ (zabbix に含まれる) から作成されます。
   • タイムゾーンのリストが作成されます (Web インターフェイスにタイムゾーンを表示するために必要です)
   • 現在の 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 が起動するようにしました。

そしてXNUMXつ目のサービス（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 と settings_restore を起動した後です。 ただし、zabbix サービスを開始する前に。

logrotate のタイマー サービス

Systemd は CRON を置き換えることができます。 真剣に。 さらに、精度は分単位ではなく秒単位です (必要な場合) または、イベントからのタイムアウトによって呼び出される単調なタイマーを作成することもできます。
それは、私が作ったマシンの起動から時間をカウントする単調なタイマーでした。
これには 2 つのファイルが必要です
logrotateTimer.service - サービスの実際の説明:

[Unit]
Description=run logrotate

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

簡単です - 起動コマンドの説明です。
XNUMX 番目のファイル 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 を呼び出すことはできません。 サービスのみ可能です。

ただし、私は作業の柔軟性とアクションの順序を保証するためにターゲットを使用しています。

しかし、最も興味深いことはその後に起こりました。 マシンの電源を切るか再起動する必要があります。 そして、オプションは 2 つあります。

• reboot、shutdown、およびその他のコマンド (これらは依然として systemctl へのシンボリックリンクです) をスクリプトに置き換えます。スクリプト内で、my_shutdown.target に移動します。 そして、ターゲット内のスクリプトは systemctl を直接呼び出します (たとえば、systemctl reboot)。
• よりシンプルなオプションですが、私は好きではありません。 すべてのインターフェイスで、shutdown/reboot/other を呼び出さず、ターゲット systemctl isolate my_shutdown.target を直接呼び出します。

私は最初のオプションを選択しました。 systemd では、再起動 (電源オフなど) は 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

出所： habr.com