Answers:
在断开与活动屏幕的连接然后重新连接时,我已经看到了这一点。 错误#27462(“丢失原始会话时重新连接停顿”)描述了我所看到的问题。似乎发生的情况是屏幕正在尝试通知持有该屏幕的tty即将离开,但是由于tty由于连接断开而挂起,因此它必须等待超时发生(长达五分钟)在某些情况下)。
要修复它,我这样做:
ps -ef | grep screen | grep pty
ps -ef | grep bash | grep $PTY
kill -KILL $PID
这将导致屏幕正确完成其断开连接,并让您正常地重新连接。
请参阅此处的示例脚本,以某种方式使其自动化。
我的屏幕会话有类似的问题。我给它们命名,并将它们设置为多用户会话。我发现它正在列出我的会话,但告诉我没有人可以重新连接。然后我尝试了:
screen -x <session_name>
它像冠军一样运作!
我不能说我遇到了问题,无论连接什么类型的屏幕都无法返回。我通常的方法:
ssh myname@foo
screen -S sessionName
(do my work... get disconnected...)
ssh myname@foo
screen -d (just to make sure anything wasn't left attached)
screen -r sessionName
灵魂:https ://kb.iu.edu/data/ahrm.html
To see your existing screen sessions, enter:
screen -list
This will display a list of your current screen sessions. For instance, if you had one attached screen, you would see:
1636.pts-21.hostname (Attached)
To detach an attached screen, enter:
screen -D
If you have more than one attached screen, you can specify a particular screen to detach. For example, to detach the screen in the above example, you would enter:
screen -D 1636.pts-21.hostname
我有时会遇到相同的问题(屏幕-r -d无法恢复,无响应)。要解决此问题,请找到与屏幕会话关联的终端(tty / pty):
screen -list
There is a screen on:
28176.pts-51.localhost (Attached)
1 Socket in /tmp/uscreens/S-xxxx.
找到列出的终端(在本示例中为pts-51):
ps axuw | grep 'pts/51' # will vary depending upon how pty's are named
you 12293 0.0 0.2 2148 1128 pts/51 Ss 10:34 0:00 -bash
终止该终端(通常是您的shell)上的进程:
kill 12293
再次运行ps以确保它消失了。如果不 :
kill -9 12293
在我的服务器(gnu / linux)上,有时我不得不杀死-9次,直到它死掉。
在该tty上的所有进程都消失之后,屏幕应正确恢复:
screen -r -d