$ systemd-run sleep 1000
Running as unit: run-u635.service
睡眠プロセスを終了したり、次のようにサービスを正しく終了した場合でも、
$ systemctl kill run-u635.service
プロセスが終了したか正常に終了したかを示すデバイスの属性が見つかりません。例えば。
$ systemctl show --property=ExecMainStatus run-u635.service
ExecMainStatus=0
正常にシャットダウンされたサービスとシャットダウンまたは競合したサービスの違いをどのように理解できますか？
答え1
--service-type=oneshot（ ）でサービスを実行すると、シャットダウンがType=oneshot失敗SIGTERMしたと見なされます。
これは実際には、このようなシェルコマンドまたはシェルスクリプトを実行する一般的な種類のサービスです。 （通常は「永久に」または少なくともシステムがシャットダウンするまで実行される「デーモン」とは反対です。）コマンドが実行されると、サービスは「開始済み」ではなく「開始中」と表示されます。--remain-after-exit（）を使用すると、コマンドが完了した時刻RemainAfterExit=yesとして表示されます。startedそれ以外の場合は、stoppedコマンドが完了するまで考慮されません。 「一時的」ユニットを作成しているため、停止すると消えます。
systemd-runはコマンドが完了するのを待たず、幸いです。 （これを使用すると終了--waitコマンドが表示されることがわかりましたSIGKILL）。この場合、次のコマンドを使用できます。
systemd-run --service-type=oneshot --no-block sleep 1000
エラーが発生すると、ログメッセージに表示されます。 Journalctlを使って見ることができます。たとえば、
journalctl -b -u run-u635.service
この方法をスクリプトで使用しようとすると、好きなようにうまく機能しないようです。おそらくより良い機能の組み合わせが利用可能になるでしょう。達成しようとする目標についてもっと知ることが重要だと思います。
systemd-run --user ...ユーザー単位（）を使用すると、以前のログインセッションで別のインスタンスが発生する可能性があります。run-u635.service
ここにある文書は、少なくとも私のシステムでは不完全なようです。ドキュメントにはman systemd.service動作を変更する可能性が記載されていないようですSIGTERM。私が特に注目した定義には、SuccessExitStatus=これらの可能性についての言及はありません。
通常、systemd は、サービスが SIGTERM をキャプチャすると仮定しません。一部のサービスは、シャットダウン要求時に何らかのアクションを実行する必要がない場合があります。したがって、正常に存在するサービスは、異常終了したWTERMSIG() == SIGTERMと記録されません。 （実際には、歴史的な場所systemdの文書によると、SIGTERMを使用してサービスを終了した場合、そのサービスが終了してもWTERMSIG() == SIGTERM終了する必要があります。したキャプチャ信号）。
これは驚くほど聞こえるかもしれません。覚えておいて、UnixとLinuxは何十年も使用されてきました。いいえすべてのサービス監督。サービスの終了ステータスは監視されていないため、SIGTERM正常に停止しても一部のサービスはまだ生きていることがほとんど確実です。
サービスが終了した後は使用できなくなります。
Unit run-u635.service could not be found.
正しい。実はsystemctl show 登場この場合は動作します。混乱した例ですsystemctl show。 :-(. 実際に存在しないサービスの属性 (現在ロードされていないサービスも含む) を照会しようとすると、エラー メッセージはありません。属性以外のデフォルト/空の属性値が表示されます。LoadStateこれが提供する唯一の手がかりです。
$ systemctl show --property=LoadState run-u635.service
LoadState=not-found