私のArchコンピュータには、ユーザーレベルのシステムサービスとして設定されているいくつかのサービス（同期など）があります。にいるときはうまくいきますが、sshを使って接続すると起動してmoshすぐに再び停止するようです。たとえば、moshを接続して実行systemctl --user status syncthing中または終了した後にコマンドを繰り返すと、次のような結果が得られます。
Failed to connect to bus: No such file or directory
$XDG_RUNTIME_DIR他の同様の質問に基づいて、moshセッションの設定を確認しました。
$ echo $XDG_RUNTIME_DIR
/run/user/1000
実際にセッションに接続し続けても、ユーザー管理者が完全に閉じているようです。
$ systemctl status [email protected]
● [email protected] - User Manager for UID 1000
Loaded: loaded (/usr/lib/systemd/system/[email protected]; static; vendor preset: disabled)
Active: inactive (dead)
[...]
Aug 16 18:36:56 ip-172-70-3-138 systemd[7804]: Closed GnuPG cryptographic agent and passphrase cache (restricted).
Aug 16 18:36:56 ip-172-70-3-138 systemd[7804]: Reached target Shutdown.
Aug 16 18:36:56 ip-172-70-3-138 systemd[7804]: Starting Exit the Session...
Aug 16 18:36:56 ip-172-70-3-138 systemd[7804]: Received SIGRTMIN+24 from PID 7877 (kill).
Aug 16 18:36:56 ip-172-70-3-138 systemd[1]: Stopped User Manager for UID 1000.
サービスを引き続き実行するにはどうすればよいですか？
修正する:Tmuxセッション自体は、少なくとも私のシステムでsystemdサービスを開始したりアクティブにしたりしません。これが正しい動作かどうかはわかりませんが、tmuxセッションがsystemdが終了するのを防ぐ必要があるようです。ファイル編集作業をしている状況を考えてみてくださいemacsclient。 mosh を使用するか tmux を使用するかにかかわらず、接続がしばらく中断された場合は、emacs デーモンがアクティブな状態を維持したいと思います。
ベストアンサー1
systemdの概念が再び矛盾しています。ユーザー空間ログインセッションそして、moshのようなプログラムがどのように機能するかを学びましょう。 （これが唯一の紛争ではありません。 新しいデーモンモードでは、tmux、screen、emacs、delugedなどに問題があります。 ただし、これはこの回答の範囲外です。 )
systemdの概念は、bodge PAMプラグインがログインセッションの設定と終了をに渡して、logind最初と最後のログインでユーザー固有のサービス管理の開始と停止を処理することです。去る。
これは、起動に使用したSSHセッションに応じて適用されますmosh-server。ただし、セッションは寿命が短く、mosh-server一度実行すると終了します。 mosh-serverさらに、ログインプログラムでもPAMとも関係がないため、bodge PAMプラグインは機能しません。その結果、logind非常に短いSSHセッションのみが表示されるため、ユーザー固有のサービス管理サブシステムを起動してすぐに停止します。
systemdがこれを処理する唯一の方法は、logindユーザー固有のサービス管理者に、最後のログアウト後に「待機」するように指示することです。このコマンドのサブコマンドを使用してenable-lingerこれを実行できますloginctl。
また、これはモッシュにのみ適用されるものではありません。短期SSHセッションを含むシステム、特に複数のセッションを含むシステムでは、logindユーザー固有のサービス管理を繰り返し開始および停止するという問題があります。