appサーバーにアプリケーションがインストールされており、このアプリケーションがというアプリケーション制御を提供しているとしますappctl。管理者として、次の方法でアプリケーションを起動/停止/再起動できますappctl。
appctl start
appctl stop
appctl restart
その後、次を使用してこれを行う必要があることに気付いたので、1つを作成してsystemctlデーモンapp.serviceを/etc/systemd/system再ロードしてから、次のようにアプリケーションを起動/停止/再起動できますsystemctl。
systemctl start app.service
systemctl stop app.service
systemctl restart app.service
今私の問題が発生します。以下を使用してアプリケーションを停止したappctl restart後systemctl status app.service1時間前から不活性（死）。これはアプリケーションの実際の状態を反映しません。受け入れられますか？
個人的には再起動したことがないので、普通の感じですsystemctl。しかし、ドキュメントの引用、systemctl内部メカニズムの分析など、より多くの主張が必要です。
ベストアンサー1
そうです、予想される結果です。私はappctlこれが起こるのを防ぐことができるとは思わない。しかし、正しい使用を奨励する方法を検討する価値があります。
システム管理者はそれを直接使用してはならないことを知らせる必要があるかもしれませんappctl start/restart。サービスの状態が「アプリケーションの実際の状態を反映しない」だけではありません。 systemdをバイパスして、デーモンがappctl start実行しているすべてのシェルからさまざまな属性を継承するという事実のような利点を失いました。そしてsystemctl stop app.service動作しません：）。また、ExecStop=システムがシャットダウンすると、カスタムシャットダウン処理（例：）は実行されません。
systemdの独自のデーモンは、/usr/binまたは/usr/sbinではなく/usr/libのサブディレクトリにインストールすることをお勧めします。 systemd-udevdたとえば、ユーザーのPATHにはありません。 /usr/libexec/（サブディレクトリがあるかどうか）は同じ操作に使用できます。技術的には、System Vスタイルのinitscriptを提供しても同じことができます。
ただし、たとえば、複雑な構成があり、端末からエラーメッセージを受け取りたい場合は、デーモンへの便利なアクセスを提供するパラメーターがあります。例は次のとおりですapache -t。
開始/再起動/停止（システムサービスはExecReloadも定義できます）、開始/再起動/停止以外の動詞がある場合はreloadそれを分離できます。たとえば、デフォルトのデーモンバイナリを使用してこれら4つを実装し、他のものをappctl。
appdシステム管理者は、パスにあっても直接実行するとかなりの欠点があることを既に理解しておく必要がありますが、appctl端末で実行することは大丈夫です。