systemd
アプリケーションを公開してサービスとして登録したいです。
アプリケーションに加えて、アプリケーションをsystemd
サービスとして登録するスクリプトも提供したいと思います。
だから私は現在、テンプレートファイルとその値をコピーして更新するスクリプトを使ってmyapp.service
アプリを公開しています。myapp.service
しかし、私はこの解決策が好きではありません。
.service
コマンドラインからファイルを作成できますか?それはまるでsystemd new -name myapp -description "my description" -after network.target -exec path/to/exec
?
答え1
2つの基本的な方法があります。
コンパイル時の設定
これは多くのソフトウェアパッケージャが取るアプローチです。
一つはマクロを使うことです。パッケージの作成時に、構成を表すパラメーターとともに、マクロプリプロセッサーのいくつかの形式がマクロ化されたサービス単位ファイルで実行されます。その後、出力はカスタムサービスユニットファイルであるパッケージに保存されます。
systemd自体が例です。これkmod-static-nodes.service.in
ファイルには次のマクロが含まれています。
ExecStart=@KMOD@ static-nodes --format=tmpfiles --output=/run/tmpfiles.d/static-nodes.conf
systemdを構築する大規模なPythonスクリプト(「Meson」と呼ばれる)には、とりわけ正規表現ベースのマクロプリプロセッサが含まれています。プリプロセッサはで実行され、マクロをkmod-static-nodes.service.in
置き換えて受信パッケージをKMOD
生成します。 replacementは、コンパイル時にPythonスクリプトによって取得されたランチャーイメージkmod-static-nodes.service
ファイルのパスである文字列です。kmod
(大規模なPythonスクリプトシステムについては、この回答の範囲をはるかに超えているので、詳しくは説明しません。)
このシナリオの欠点は、パッケージがインストールされているターゲットコンピュータと同じレイアウトと同じプログラムを含むコンピュータにパッケージを作成する必要があることです。パッケージはオペレーティングシステムによって異なります(またはバージョンも異なる場合があります)。
インストール中の設定
一時挿入
.conf
別のアプローチは、サービスユニットをターゲットシステムに合わせて調整する挿入ファイルを作成して、インストール時に静的サービスユニットファイルを構成することです。もちろん、サービスプロセスとしてエクスポートされるので理想的ではありませんが、この目的のために環境変数を使用できます。
たとえば、静的サービスユニットファイルは次のように/usr/lib/systemd/system/wibble.service
言うことができます。
ExecStart=/usr/bin/wibble $OPTIONS
これパッケージメンテナンススクリプト~のためインストールするその後、タスクは、/usr/lib/systemd/system/wibble.service.d/20-options.conf
パッケージの作成時に他のシステムではなくインストール時に現在のシステムで評価されるカスタムオプションを含むファイルをインストール時に動的に生成します。
環境=オプション=swing --jelly -oボード
このソリューションの欠点は、パッケージメンテナンススクリプトが削除パッケージが完全にクリーンアップされた場合、ジョブはこのファイルを削除し、そのファイルを次にリンクする必要があります。構成コンテンツを再構成または再配置するときにシステム管理者を含むファイルを明示的に強制的に再生成できるようにするアクション。
前処理
上記の変形は、マクロ前処理に戻ることである。実際にマクロサービスユニットファイルを転送し、インストール中に前処理します。
パッケージをまったく作成せずにシステム管理者が手動でインストールできるように、すべてをustarアーカイブに入れると、生成されたプラグインよりもこれがより実現可能です。
欠点は、Mesonのマクロ前処理システムがPythonスクリプトコレクションと密接に結合されているため、独立したツールとして使用できないことです。独立した前処理ツールには、次のものがあります。m4
他のものは、.INIファイルを前処理し、通常決定を下すのには適していません(例:「このシステムでcpp
検出プログラムはどのオプションを使用しますか?」「このシステムのどこにありますか?」)。wibble
kmod
明らかに、ここにはまだ誰も発見していないツールのニッチがあります。少なくとも私が聞いたことです。
あなたはそれで行うことができますcommand -v
ルート検索の実行そしてex
交換はシェルスクリプトで行われます。ただし、(ほとんどの人はそうではありません)パス名にスペース、メタ文字などを避けるため、または不要なマクロ拡張を防ぐためにエスケープメカニズムを許可することが重要です。
Perlの文字列処理はシェルスクリプトよりも安全ですが、すべてのオペレーティングシステムにPerlが含まれているわけではありません(「PerlのないUnixシリーズシステムはありますか?「)、システム管理者にPerlが最初にインストールされていることを確認するように指示する必要があります。変更するということです。破損したPATH変数を再構築した後、apt-getアップデートは機能しなくなりました。「とUbuntuの質問をするすべてのハイパーリンク)。
手をつないで...
場合によっては、この構成は不要な場合があります。 systemd のマクロは@KMOD@
実際には必要ありません。これは(現在)動作します:
ExecStart=kmod static-nodes --format=tmpfiles --output=/run/tmpfiles.d/static-nodes.conf
データベーステーブル(一種)をサービス単位に置き換えますか?発電機を出荷します。
デフォルトの有効化/無効化状態を指定しますか?配送プリセット。
答え2
systemd-run
コマンドラインから新しいシステムサービスを開始するために使用できます。
systemd-run [OPTIONS...] {COMMAND} [ARGS...]
systemd-run --help
報告man systemd-run
これは継続的なシステムサービスではなく、単位ファイルを作成する必要があります。
はいRHELドキュメント: systemd-run を使用して新しいサービスを開始する
systemd-run --unit=toptest --slice=test top -b
ユニットファイル/run/systemd/transient/
はtoptest.service
。