☰

.INIファイル構文の基本

tag-icon • tag-icon centos services
.INIファイル構文の基本

あなたの投稿に基づいて単位ファイルを修正しました。

[Unit]
Description=My Portal Service
After=network.target

[Service]
SyslogIdentifier=my-portal
Environment=SERVICE_NAME=my-portal
Environment=PATH_TO_TARGET=/opt/apps/egp/stage/my-portal/target
ExecStart=/usr/bin/env java -jar ${PATH_TO_TARGET}/${SERVICE_NAME}.jar server ${PATH_TO_TARGET}/${SERVICE_NAME}.yml

[Install]
WantedBy=multi-user.target

また、次のコマンドを実行します。

systemctl daemon-reload

systemd 管理者構成を再ロードします。

すべてがうまくいきます。以下を使用して、サービスを正常に開始、停止し、状態を表示できます。

 systemctl start my-portal
 systemctl status my-portal -l
 systemctl stop my-portal

Java環境変数の問題を解決したら、次のコマンドを実行します。

systemctl enable service-name

起動時にサービスを開始します（サービス - 合計5つ）。

私が経験している問題は、Java環境変数を設定することです。様々なバージョンを試してみました。 .bash_profileに追加し、sourceコマンドを使用して、/etc/profile.dフォルダの別のjavaenv.shファイルにJava環境を作成しました。

export JAVA_HOME=/opt/jdk1.7.0_80
export PATH=/opt/jdk1.7.0_80/bin:$PATH

承認：

chmod +x /etc/profile.d/javaenv.sh

ExecStart行に$ {JAVA_HOME} / binを追加するように単位ファイルを変更しました。 Javaが見つかりませんでした。以前も同じ問題がありましたが、shスクリプトを使用するとエラーが発生しました。

nohup: failed to run command ‘java’: No such file or directory

私はこの問題についてたくさん読んでいましたが、Java変数をある場所で設定し、別のユニットまたはスクリプトファイルで$ {JAVA_HOME}変数として使用するソリューションを見つけることができませんでした。

ロギングなしでどこでも永久に使用できるようにJava環境変数を設定する場所はどこですか？

ベストアンサー1

.INIファイル構文の基本

[単位]
説明=マイポータルサービス
network.target = my-portal.service以降

このセクションのキーはUnit、After値はでなければなりません（例：）network.target my-portal.service。キーAfter network.targetと値がありますmy-portal.service。メッセージが示すように、このキーはsystemdには意味がありません。

徹底したシステム化恐怖の家もの

サービスを開始すること自体が言うべきではありません。しかし、これは氷山の一角に過ぎません。

タイプ=フォーク
ExecStart = /usr/local/bin/my-portal.sh 起動
ExecStop = /usr/local/bin/my-portal.sh 停止
ExecReload = /usr/local/bin/my-portal.sh 再ロード
…
PATH_TO_LOG="/var/log/egp"
…
PID_PATH_NAME=/var/run/${SERVICE_NAME}-pid
いいえ... >> ${PATH_TO_LOG}/${SERVICE_NAME}.out 2>&1&

これらすべては、奇妙なことに、Javaで支配的な典型的なパターンであり、完全に不要で間違った足場を作成して愚かにします。

シェルスクリプトは不要別の言葉。使用しようとする不安定で危険なPIDファイルメカニズムは間違いなく必要ありません。また、不安定なlogrotate / newsyslogメカニズムに依存する手動ロギングメカニズムは必要なく、ディスクボリュームがログ出力（スーパーユーザー権限を持つプロセスによって作成されるため、ログ出力でいっぱいになるのを防ぐ方法はありません。）スーパーユーザー - ほとんどの場合緊急ディスク領域を予約します。

既存のサービスマネージャ機能を使用します。

#/etc/systemd/system/my-portal.service
[単位]
説明=myportalservice
ドキュメント=https://unix.stackexchange.com/a/434726/5132
以降 = network.target

[提供する]
SyslogIdentifier=MyService
環境=SERVICE_NAME=私のサービス
環境 = PATH_TO_TARGET="/opt/apps/egp/stage/my-service/target"
ExecStart=/usr/bin/env java -jar ${PATH_TO_TARGET}/${SERVICE_NAME}.jar サーバー ${PATH_TO_TARGET}/${SERVICE_NAME}.yml

[インストールする]
WantedBy =マルチユーザー。ターゲット

サービスログを読むには、journalctl通常の方法で使用できます。サービス管理者は、プロセスの作成時にプロセスIDを記憶してプロセスを追跡し、不安定で危険なPIDファイルメカニズムは必要ありません。

追加読書

おすすめ記事