进一步阅读

进一步阅读

我在我的 Arch 机器上设置了一些服务(例如syncthing)作为用户级systemd 服务。当我进入时它们工作得很好ssh,但是当我使用 进行连接时mosh,它们似乎启动然后立即再次停止。例如,我可以连接 mosh,然后执行systemctl --user status syncthing并返回它正在运行或关闭;然后,重复该命令,我得到

Failed to connect to bus: No such file or directory

基于其他类似的问题,我检查了$XDG_RUNTIME_DIRmosh 会话中的设置:

$ 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

此外,这不仅仅适用于 mosh。任何涉及短期 SSH 会话的系统,尤其是涉及大量会话的系统,都存在logind反复启动和停止每用户服务管理的问题。

进一步阅读

相关内容