恢复命令在已删除的SSH会话中运行

读了这个问题让我很纳闷。假设screen没有被使用。如果出于任何原因删除了Linux目标上的SSH会话，并且您在服务器由于超时而终止会话之前重新连接，则有可能重新获得对正在运行的命令的控制，以使其不会由于会话中断而被中止？

试图将新终端的当前STD *文件描述符连接到旧的正在运行的进程只是在问麻烦。即使您确实做到了，终端的工作控制也无法按预期工作。如果最终退出接管程序，您将一团糟，而牺牲了其文件描述符以将其交给新后台进程的shell发生了什么情况。当外壳消失时，ssh会保持打开状态吗？可能不会。因此，您需要先将其重定向到其他地方。

无论可能与否，我敢打赌，更希望让被遗弃的进程被“自然地”杀死。如果您做的事情足以证明尝试执行恢复控制所需的所有黑客手段是合理的，并且您处于不稳定的链接上，则您可能应该事先知道这一点，并且只需使用screen（或vnc，或任何使您超脱的对象浮动-控制船）。:)

我知道这是一个古老的问题，但是我认为添加我的发现很重要，以防其他人像我一样遇到这个问题。

我还没有看到这样做的任何异常结果，但这是我使用的方法，效果非常好。有时，当我们在服务器上运行长进程时，它有时会断开ssh会话的连接。该过程以及tty会话似乎仍在运行，但是我们无法重新连接到该会话。我在下面找到了将程序拉到新连接的会话的程序。

https://github.com/nelhage/reptyr

这是更多信息

https://blog.nelhage.com/2011/02/changing-ctty/

通常，处理此问题的正确方法是使用GNU screen或bash nohup或disown机制提前做好准备。如果使用tcsh，shell将在异常退出时放弃后台作业。

如果您不使用screen但设法通过disown方法之一使进程运行，则可以使用gdb（source）伪造重新连接到该进程：

[...]有一些肮脏的骇客，并非不可能重新打开进程的stdout / stderr / stdin。[...]

然后例如使用gdb附加到进程，执行一些调用close（0）
调用close（1）
调用close（2）
调用open（“ / dev / pts / xx”，...）
调用dup（0）
调用dup（0）
分离

现在，您必须针对情况调整此过程。我怀疑它会帮助，如果你没有设法否认的过程。如果您使用bash，看到这个帖子有关使bash的自动不认退出后台进程（基本上，关闭huponexit与禁用了javascript）。对于前台进程，您需要使用nohup。

可能不会。我不能保证这是不可能的，但我真的对此表示怀疑。

一件事是由于ssh连接终止而导致无法终止shell以及可能运行的命令。这并不是那么困难，您应该能够使用nohup以及其他问题中提到的类似机制。

但是，然后假设您开始ssh somehost nuhup vim /some/file并且连接断开。您ssh somehost再次运行登录，可以看到您的vim进程仍在运行。但是，如何再次连接到该过程呢？交互式forground进程具有一个控制tty，并且在启动时为您的vim进程打开的那个已被关闭。我不确定在新的Shell中是否有任何方法可以“重新打开”它（就像在一个Shell中运行了多个后台作业一样，您无法在另一个Shell中进行任何前台工作）。

Screen已明确编写为具有此功能。在启动时，它分叉两个过程，一个终端管理过程和一个客户端过程。交互是客户端<->终端管理器<->应用程序，当您断开连接或断开连接时，客户端进程将在终端管理器继续运行的同时死亡。屏幕有一些特定的支持，以后再附加到终端管理过程中，我认为在一般情况下这是不可能的。

retty也许可以为您提供帮助，但是免责声明非常真实且相关：)

如果会话被丢弃，则意味着TTL已经过期，因此不再有tty供您使用（据我所知）。但是，如果您的网络连接中断，则SSH会话可能不需要断开，并且您应该能够恢复连接并继续。那是你要问的吗？

这个问题中有一些骇客的tty窃取代码的链接。从理论上讲，您应该可以使用它来重新获得对nohup进程的控制。