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.

Thanks

Edmond


On Fri, Sep 27, 2013 at 3:45 PM, Edmond Rodriguez <erodrig97.l...@gmail.com>
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.
>
> Edmond
>
>
>
>
> On Fri, Aug 30, 2013 at 4:41 PM, Edmond Rodriguez <
> erodrig97.l...@gmail.com> 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.
>>
>> Thanks,
>>
>> Edmond
>>
>>
>> On Thu, Aug 29, 2013 at 5:54 PM, wes <david...@ling.ohio-state.edu>
>> 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]
>>>
>>>   http://savannah.gnu.org/bugs/?11610
>>>
>>> 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.
>>>
>>> hth,
>>> wes
>>>
>>> _______________________________________________
>>> screen-users mailing list
>>> screen-users@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/screen-users
>>>
>>
>>
>
_______________________________________________
screen-users mailing list
screen-users@gnu.org
https://lists.gnu.org/mailman/listinfo/screen-users

Reply via email to