编辑： 这个问题的最初前提是screen在现有的 Debian Jessie 上无法正常工作，我正在寻找解决方法。事实证明，这是样本量较小的产物——我已经验证了新的 Debian Jessie 安装可以screen正确运行，所以显然“Something Else”是错误的。
修改后的问题是：我以某种方式破坏了 Debian Jessie 系统，唯一明显的症状是screen会话在注销时终止，并且有一些间接证据表明可能涉及 dbus 连接。有人可以建议我可能破坏了什么吗？
我意识到这将它变成了一个广泛且可能无法回答的问题，但这就是我现在的处境。
原问题继续这里：
我知道之前已经对此进行了一些讨论，但我似乎无法在一个地方找到所有相关信息，并且组合不同的来源对我来说不起作用。
我有一个 Debian “jessie”系统，无法通过 ssh 进入它，使用“screen”工具运行后台会话，并在退出父 SSH 会话后让它们持续存在。我相信我遇到了 systemd 会话的问题，并且已经采取了一些应该修复它的措施，但它仍然不起作用。
我在这里阅读了错误报告：Debian 错误报告 825394。作为这项研究的结果，我确保用户会话运行 /etc/pam.d/common-session 中的“pam_systemd.so”库，为相关帐户运行“loginctl enable-linger username”，并检查“ KillUserProcesses”在 /etc/systemd/login.defs 中设置为“no”。
我还从之前的 StackExchange 帖子中跟进了屏幕“自动分离”设置：StackExchange 屏幕问题
通过这些设置，我似乎应该能够做到：
systemd-run --scope --user screen
由此产生的问题是 systemd-run --user 想要连接到用户的 dbus 会话以到达用户的服务管理器，并且 ssh 连接不会启动 dbus，在我看来，它们也不应该启动 dbus此操作的重点是执行一些其生命周期比封闭的 SSH 会话的生命周期更长的操作，这可能会（并且应该）在 dbus 会话退出时将其拆除。
我感觉我绕了一圈，又回到了希望子进程在注销后继续存在的问题。
Debian Jessie 目前发布了 systemd 215 版本和 screen 4.2.1 版本，后者在打包时不包括 PAM 支持。
我的第二个目标是最大限度地减少对系统的干预程度——在足够的指导下，我可能可以制作一个 /etc/pam.d/screen 文件，但我希望有一个更简单的解决方案。
在这种情况下，是否有一组针对 Debian Jessie 的已知步骤可以说服 systemd 尊重我的意图？
答案1
首先我们确认您是分离屏幕会话而不仅仅是注销。要分离的默认键绑定是 Control-AD。详细信息是这里。
当您重新登录时，您可以screen -r恢复会话。
答案2
因此，对于这个特定的场景，结果是/etc/pam.d/common-session删除了将会话连接到 systemd 的行。恢复这一行 ( session optional pam_systemd.so) 似乎已经解决了问题。
这可能只针对相当有限的一组情况。