这是我遇到过的一种奇怪的情况。我们有一个异地测试服务器（或我工作地点的异地服务器）。要访问该服务器，我需要通过 VPN 接入其网络。
我运行 screen 来执行一个长时间运行的进程。启动该进程后，我做了以下操作来检查 screen 的可行性：
- 我退出了会议
- 执行 screen -ls 检查 PID
- ps -ef | grep 屏幕
- 屏幕-r PID
运行这些命令并重新连接/分离会话后，我可以看到有一个屏幕会话。
奇怪的是，第二天我回来时，没有屏幕会话。我运行了上述命令进行检查，但什么都没有。但是，我的进程仍在运行。我没有使用 nohup 来运行我的进程，但幸运的是，我的进程没有随着会话而消失。
有人知道发生了什么吗？为什么我丢失了 screen 会话，为什么我很幸运，进程还能继续运行？
谢谢您的启发。=)
答案1
您可能想要使用 grep 来SCREEN验证您的屏幕确实没有运行。
某些系统有 tmp 清理程序，可删除/tmp、/var/tmp、/var/run或类似目录中的文件。这可能会导致screen无法找到其套接字文件。如果您可以识别会话的 PID，则可以执行kill -CHLD <PID>以指示screen重写其套接字文件。screen -r然后应该可以再次工作。
如果发生这种情况，您可能应该配置screen使用另一个目录作为其套接字。
答案2
最近我和我的同事又遇到了这种情况，他提出这可能是导致这种情况发生的原因。他认为这是由于公司超时导致屏幕死机。
我们运行了多个屏幕会话，每个会话都有自己的长时间运行的作业（为简单起见，我们将其称为会话 A 和 B）。会话 A 上的作业提前完成，该会话返回到提示符。当由于不活动而超时时，它会将我们从会话 A 中注销。当发生这种情况时，会话 B 仍在运行其作业，但我们认为当父进程（在本例中为屏幕）死亡时，它会带走所有会话。
在会话 B 上运行的进程现在由 screen 的父进程（即 init 进程或进程 1）继承，因此当我们第二天早上检查时它仍在运行。
这个假设在某种程度上得到了一个实验的支持。这个实验是在 Centos 上运行的。我们启动了 screen 并打开了两个会话。我们定期在一个会话中运行 cmd 以使其保持活动状态。另一个我们忽略了。大约 10 分钟后，screen 被终止，同时我们打开的两个会话也终止了。