[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Screen 4.0.2 frozen, can't remote detach either
From: |
Juergen Weigert |
Subject: |
Re: Screen 4.0.2 frozen, can't remote detach either |
Date: |
Fri, 17 Jul 2009 11:54:09 +0200 |
User-agent: |
Mutt/1.5.19 (2009-01-05) |
On Jul 14, 09 22:17:19 -0700, Joe Zbiciak wrote:
>
> Hello again,
>
> I realize I'm top-posting my reply to my own email. Sorry for the bad form.
> Yahoo doesn't make it easy.
>
> Anyway, I still have all these processes running and frozen. Would anyone
> like me to dig around or otherwise perform some forensics on this? Or should
> I just kill all the processes?
>
pid 21652 is the frontend. It is just stuck because the backend is not
listening on its socket, as it should. You can kill 21652 without harm.
Backend 13738 appears to be stuck in write to the user display:
> write(4, "tr_new = 0 num_cmd = 28 metric "..., 348 <unfinished ...>
> lrwx------ 1 jzbiciak vivid 64 Jul 13 07:25 4 -> /dev/pts/0
We have no good cure for this situation.
you can
try a)
close the other end of /dev/pts/0 (your xterm, ssh daemon, or whatever it was)
$ kill -CHLD 13738
and check if it is still stuck in the write. If so,
try b)
$ rm /tmp/uscreens/S-jzbiciak/13738.pts-2.durable03
$ kill -CHLD 13738
and see if it recreates the socket. If it does, the signal handler was able
to pull it out of the write. If not, there is not much more to do
except $ kill -9 13738
All those write() calls in screen should have an alarm() on them,
so that screen has a chance to regain control, whenever the kernel keeps us
stuck.
It apparently happens quite frequently to some people, while it only
happened once or twice to myself. The exact cause is still a mystery to me.
sorry,
JW-
--
o \ Juergen Weigert unix-software __/ _=======.=======_
<V> | address@hidden creator __/ _---|____________\/
\ | 0179/2069677 __/ (____/ /\
(/) | ____________________________/ _/ \_ vim:set sw=2 wm=8