環境によって設定された実行パスを使用してシステム単位ファイルを作成します。

環境によって設定された実行パスを使用してシステム単位ファイルを作成します。

私はJavaアプリケーション用のシステム単位ファイルを作成しており、それを実行するために使用されるJavaのバージョンを制御したいと思います。私の(単純化された)サービスファイルは次のとおりです。

[Service]
Type=simple
EnvironmentFile=%h/Documents/apps/app/app-%i/app.cfg
ExecStart=${JAVA_HOME}/bin/java ${JAVA_OPTS} -jar %h/Documents/apps/app/app-%i/myapp.jar
SuccessExitStatus=143

起動しようとすると、エラーメッセージが表示されます。

Apr 28 12:43:37 rombert systemd[1613]: [/home/robert/.config/systemd/user/[email protected]:7] Executable path is not absolute, ignoring: ${JAVA_HOME}/bin/java ${JAVA_OPT
Apr 28 12:43:37 rombert systemd[1613]: [email protected] lacks both ExecStart= and ExecStop= setting. Refusing.

私はJAVA_HOMEそれが正しく設定されていることを知っています。行ExecStartの始まりを変更してこのような/usr/bin/javaものを追加すると、-DsomeOption=${JAVA_HOME}それを見ることができます。

確かな解決策はラッパースクリプトを作成することですが、サービスファイルを使用する目的に反しているようです。

ユニットファイルを使用してJavaアプリケーションのJAVA_HOMEをどのように設定しますか?

ベストアンサー1

systemd.service(5) の「コマンドライン」セクションで:

最初の引数(つまり実行されるプログラム)は変数にすることはできません。

インスタンス指定子を使用することをお勧めします%i(これについての詳細はsystemd.unit(5)で読むことができます)。しかし(今はsystemd.service(5)に戻ります):

コマンドラインの最初の引数(つまり、実行されるプログラム)に指定子を含めることはできません。

この時点で最良のオプションは、Warren Youngが提案したようにJavaバイナリの実行をラップするシェルスクリプトを生成することです。または、「コマンドライン」のシェルコマンドラインの例のように、シェルをExecStartすることもできます。部分。 systemd.service(5) には次の例があります。

ExecStart=/bin/sh -c 'dmesg | tac'

したがって、次のことができます(テストされていません)。

ExecStart=/bin/sh -c '${JAVA_HOME}....'

おすすめ記事