[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Screen terminal freezes

From: Edmond Rodriguez
Subject: Re: Screen terminal freezes
Date: Tue, 17 Jun 2014 20:43:45 +0100

So I wanted to write in again (see way below for original mail).

I have been having a problem with screen terminals freezing up on me and no way to get them moving again.  Ctl q, ctl a q etc.... does not work.    At this time a new screen version is not an option.

The most reliable solution I have found which almost always works is to do the following:

kill -1 `pgrep -f SCREEN`

This almost always allows the frozen terminal (within the screen session) to continue, though the side effect is that I get kicked off of the screen session and I have to reattach to it.

Now I wonder if I can find a similar solution that will allow my screen session to stay attached, and also if someone, given the above solution, might comment on exactly what is causing the freezes and the above allowing it to continue.

On rare occasion, using the above solution may destroy my screen session.  But as I mentioned earlier, it almost always solves the problem.



On Fri, Sep 27, 2013 at 3:45 PM, Edmond Rodriguez <address@hidden> wrote:
So here is an update to my terminal hanging curious problems.

When I look at screen processes on a system I will see usually one that comes out in upper case letters (ie: SCREEN) and other in lowercase.    Often a lower case process (I guess not the main SCREEN session) will remain after disconnecting from a VPN.

(I am not sure I totally get the uppercase "SCREEN" session, how that gets created or run and ps listing shows SCREEN instead of "screen").

Though inconvenient, I can often solve a terminal hanging problem by killing (signal 1 or 2) all the screen processes except the SCREEN process.   Then logging back in, I can get back to the screen session with everything as I left it.   This solution does not always work, but it works most of the time.

This experiment started with the SIGHUP idea someone sent, which sometimes worked.

When I do "screen -ls" I do not see all the screen processes running.  It shows me that I am attached to the main SCREEN process, but I can't easily tell which screen process I am using (there are always at least two processes). 

So I will maybe try to find an easy way to find the processes that are doing nothing and kill them, and thus maybe I can keep the current session without having to relog into it.

Thanks for the all the replies, as this was the motivation to solve the above.  Any more comments, please do send them.


On Fri, Aug 30, 2013 at 4:41 PM, Edmond Rodriguez <address@hidden> wrote:

Thanks for the link.  The Ctl sequences do not seem to be an issue, I have tried several and they seem fine (but not for the freeze problem).   

I do notice that sending SIGHUP to screen does fix it (at least the terminal, but maybe not the process that was writing to the terminal), though I have also lost the screen session doing that.   I need to try more times, and as I mentioned it's an intermittent problem, though it is frequent enough to know it will happen a few times. 



On Thu, Aug 29, 2013 at 5:54 PM, wes <address@hidden> wrote:
On Wed, 28 Aug 2013, Edmond Rodriguez wrote:

I am running gnu screen version 4.00.02.

Everyone once in a while (but consistently) a terminal will freeze
up while printing output and there is no way that I know of to
unfreeze it.

CTL A q does not help and I tried about every command available in
the help.

I can create other terminals within the screen, but cannot usually
reconnect to the screen session it if I detach it.  The frozen
terminal remains just that (frozen) until I terminate the entire
screen session.

I also tried the "wipe" function of the screen command, though I
have not seen a need for it.

Any clue what might be happening?

"GNU Screen - Bugs: bug #11610, XON (Ctrl-S) halts screen 4.0.2"
                                ^^^[xoff, iiuc]

btw, you do not mention trying...

 ctrl-a ctrl-q

...and perhaps that is because ^q is not mapped to xon in your
installation.  but if it is, you might want to give that a try.  (ftr,
i am using version 4.01.00devel (GNU) 2-May-06 in debian 7.1.)

i make the suggestion because on my installation "ctrl-a ctrl-q"
behaves differently than "ctrl-a q".  namely, the former happens to
work and the latter does not appear to work (both in a vt and in
xterm).  this is despite the fact that my screen installation's help
command informs me that both ^Q and q are mapped to xon.

i have been assuming the discrepancy is most likely due to some
non-screen part of my environment.  because i like screen's help
command, and i like to think it would not tell me dirty, dirty lies.


screen-users mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]