[vox-tech] screen question

[Peter Jay Salzman]

Thanks Mike.  I did try the remote detach (-d).  It *said* that the session
was forcibly detached, but a subsequent "screen -ls" showed the session as
still being attached.

Here's an example:


   # Try to reattach
   #
   born$ screen -r
   There is a screen on:
           25783.pts-2.born        (Attached)
   There is no screen to be resumed.

   # OK, try to detach.  Looks like it worked.
   #
   born$ screen -d
   [25783.pts-2.born detached.]

   # Apparently, it didn't!
   #
   born$ screen -ls
   There is a screen on:
           25783.pts-2.born        (Attached)
   1 Socket in /home/psalzman/.screen.

   # Confirmed.  It didn't detach.
   #
   born$ screen -r
   There is a screen on:
           25783.pts-2.born        (Attached)
   There is no screen to be resumed.
   born$ 


It looks like "screen -R" looks for a screen to be resumed, doesn't find one,
so it starts a new screen session.

Looks like I can name the session to be remotely detached/reattached, but
that doesn't work either:


   born$ screen -d 25783.pts-2.born 
   [25783.pts-2.born detached.]

   born$ screen -r 25783.pts-2.born 
   There is a screen on:
           25783.pts-2.born        (Attached)
   There is no screen to be resumed matching 25783.pts-2.born.



I'm really out of ideas here, other than to say screen itself is messed up
somehow.  The system appears to be (from /etc/redhat-release):


   Scientific Linux SL Release 3.0.2 (SL)


Never heard of this before.  Wierd.  According to rpm (can't believe I
remember how to do this!), the version of screen is not exactly recent:

   screen-3.9.15-10.src.rpm

I'll try to find a more recent rpm for screen and ask the admins to upgrade.
Other than that, I have absolutely NO idea how to lick this problem.   :(

Pete



On Mon 01 Nov 04, 12:30 AM, ME <dugan at passwall.com> said:
> If a session is still attached according to the system, you can try to
> issue a remote detatch:
> (new shell, login from a non-screen session on the box)
> $ screen -d
> 
> Another option is to try a force re-attach with "-R" (includes existing
> attached sessions as wells as ones which are detatched.)
> $ screen -R
> 
> If screen -l shows the sessions, or there are multiple sessions, you can
> attach to a session by its ID.
> 
> If you noticed that screen still does not work, then you should note that
> screen user should be able to write to /tmp for socket space (assuming
> insecure /tmp space writing.) In your case, you state that your session
> info for screens are stored in your own home directory. You may want to
> check to see if the SUID bit on screen has been altered, or if an upgrade
> of screen 9while it as running) caused the new version to search /tmp
> instead of ~/.screen, (etc.)
> 
> Hopefully, one of these above will help.
> 
> -ME
> 
> 
> Peter Jay Salzman said:
> > There's a bunch of computers that have NFS mounted /home.  I log into
> > these
> > computers to run simulations.  In the past, I've used screen to leave a
> > job
> > running and come back to it a few days later to check up on the output.
> >
> > The screen sessions are saved in $HOME/.screen.  Typical socket:
> >
> >    kusch$ ls -la .screen/
> >    total 8.0K
> >    drwx------    2 psalzman g96          4.0K Oct 31 20:36 ./
> >    drwx------   32 psalzman g96          4.0K Oct 31 20:36 ../
> >    prwx------    1 psalzman g96             0 Oct 31 20:37
> > 6991.pts-13.kusch|
> >
> > Recently, I've been having trouble reattaching to the sessions.  Here's a
> > pretty typical example.  I wrote a small perl script to keep writing
> > incrementing numbers to a file so I can see if the session is actually
> > running:
> >
> >    kusch$ screen                           (1)
> >    [detached]                              (2)
> >    kusch$ screen -r                        (3)
> >    [detached]                              (4)
> >    kusch$ screen -r                        (5)
> >    There is a screen on:                   (6)
> >            7197.pts-13.kusch  (Attached)
> >    There is no screen to be resumed.
> >    kusch$
> >
> > (1) Screen is started and the script (not shown here) is started.
> > (2) Second, I detached the screen session with ctl-a/d
> > (3) Third, I successfully reattached to it.
> > (4) Fourth, I detached from it again.
> > (5) Then I ATTEMPTED to reattach, only to be told that there's no screen
> >    to be resumed.
> >
> >
> > The perl script is still running, so the session is still "alive",, but
> > for
> > some reason, I can't reattach to the session (despite the fact that I JUST
> > attached to it a few seconds ago).
> >
> > Why all of a sudden I can reattach to the session?
> >
> > Why does screen insist that the session is current attached?  According to
> > line (4), it should be detached.
> >
> > Is there a way to reattach to this session?
> >
> >
> > Thanks!
> > Pete
> > _______________________________________________
> > vox-tech mailing list
> > vox-tech at lists.lugod.org
> > http://lists.lugod.org/mailman/listinfo/vox-tech
> >
> >
> 
> _______________________________________________
> vox-tech mailing list
> vox-tech at lists.lugod.org
> http://lists.lugod.org/mailman/listinfo/vox-tech

-- 
----------------------------------------------------------------   linux
To err is human, to forgive is divine.               p at dirac.org     _
To oink is porcine, to meow is feline.    http://www.dirac.org/p    ._.
To neigh is equine to howl is lupine,     I'm a true patriot and    /v\
To moo is bovine to bleat is ovine.       support Kerry/Edwards.   // \\
----------------------------------------------------------------   ^^ ^^
     The best way to accelerate Windows XP is at 9.81 m/s^2        rules!