
私は最近、コンピュータの起動順序の最初にスクリプトを実行するための最初のカスタムsystemdサービスを作成しました。カスタム.service
ファイルがにコピーされていますが/etc/systemd/system
、私が知っている限り、この場所はパッケージを介して、またはオペレーティングシステムの展開の一部として展開されていないカスタムサービスの正しい場所です。
oneshot
ネットワークスタックとdhcpcdを起動する前にシェルスクリプトを呼び出してホスト名を動的に設定するタイプサービス。サービス定義は次のとおりです。
[Unit]
Description=Set hostname on startup, based on hardware serial number
Wants=local-fs.target
After=local-fs.target
Before=systemd-hostnamed.service network.target
[Service]
Type=oneshot
ExecStart=/SOMEPATH/hostname-from-serialnumber.sh
[Install]
WantedBy=systemd-hostnamed.service network.target
シェルスクリプトのための最良の場所がどこにあるのかわからないので、上記SOMEPATH
のコードブロックにプレースホルダを配置しました。このシェルスクリプトの正しい場所は何ですか?なぜ?
答え1
/etc/systemd/system/*.service
カスタムサービスファイルの適切な場所が何であるかについてのあなたの意見は絶対に正しいです。
スクリプトは次のように入力します。/usr/local/...
変える/usr/...
。それはあなたが台本を書いたからです。このルールが存在する理由のいくつかは次のとおりです。
- のファイルは
/usr/{bin,lib,share}/
パッケージマネージャが所有します。どのパッケージがそれを所有しているdpkg -S <file>
のかpacman -Qs <file>
、rpm -q --whatprovides <file>
どのファイルでも見つけることができるはずです。 - どのファイルが「自分のもの」かを覚えておくことができます(つまり、このシステムを再構築すると、コピーする必要があるものやパッケージから入手できるものを簡単に確認できます)。
- パッケージがインストールされている場合、通常名前付きスクリプトはパッケージで上書きされません。
次に、次のディレクトリを選択する必要があります。オプションは次のとおりです。
/usr/local/bin
#!/bin/bash
:スクリプトが実行可能で(たとえば、コンパイルされたバイナリやorなどのshebangを使用して#!/usr/bin/python3
)、すべてのユーザーが実行できる場合に適用されます。とても簡単なので、たくさん使っています。/usr/local/sbin
:スクリプトが要件を満たしている場合は適しています/usr/local/bin
が、ユーザーは実行しないでください。代わりにシステム管理者だけを実行する必要があります。通常、環境/usr/local/sbin
にのみ含まれます。$PATH
sudo
/usr/local/lib
:一部のシステム(Debianベースのシステムなど)では、このディレクトリにユーザーまたはシェルスクリプトが直接実行できない内部バイナリが含まれる場合があります。ただし、他のシステム(Redhatベースのシステムなど)では、lib
オブジェクトファイルとライブラリのみが含まれています。/usr/local/libexec
:このディレクトリには、ユーザーまたはシェルスクリプトが直接実行できない内部バイナリが含まれています。この機能は一部のディストリビューションでのみサポートされます。/usr/local/share/<ServiceName>/
。これは、スクリプトが実行可能ではなく、アーキテクチャに依存しない場合(つまり、コンパイルされていない場合)にのみ適用されます。スクリプトがあるが実行可能で*.sh
ないshebang
場合は、インタプリタを呼び出し、パスをスクリプトの引数として渡してスクリプトを実行する必要があります。/bin/bash /path/to/script.sh
。この場合、スクリプトは読み取り専用のアーキテクチャに依存しないデータファイルと見なすことができ、/usr/local/share
混乱を避けるために別のサブディレクトリに配置する必要があります/usr/local/share
。あなたのサービスのために書くことを選択したすべての文書も統合することができますshare
。
答え2
うーん…難しい質問ですね。これが非OSコードであり、ディストリビューションの一部ではないと仮定すると、通常は/usr/local/lib/systemに移動し、/etc/systemd/systemでリンクする必要があると言います。問題は、システムの起動時にすべてのファイルシステムがマウントされていないと問題が発生する可能性があることです。したがって、幸運な場合は、アップグレードで上書きする可能性が低い名前を指定し、ほとんどのエントリを含む同じディレクトリである/lib/systemd/systemに適切なリンクを指定してみてください。 IMHO。