Re: GNU Screen on OpenServer 5.0.6
From: Bela Lubkin (belal_at_sco.com)
Date: 04/27/04
- Next message: tony_at_pcunix.com: "Re: The reason Baystar wants its money back from SCOG"
- Previous message: Joe Dunning: "Re: OSR 5.0.6 relicensing"
- In reply to: Steve Bushore: "Re: GNU Screen on OpenServer 5.0.6"
- Next in thread: Dan Skinner: "Re: GNU Screen on OpenServer 5.0.6"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 27 Apr 2004 12:36:25 GMT To: scomsc@xenitec.ca
Steve Bushore wrote:
> Bela Lubkin <belal@sco.com> wrote in message news:<20040424111730.GH11653@sco.com>...
>
> > Anyway. I run screen 3.9.5 all the time, and I (involuntarily) use the
> > auto-detach functionality many times a day, due to a crappy phone line.
> > I forget whether I got the binary from somewhere or built it myself.
> >
> > It needs to be setuid-root for the auto-detach stuff to work right; is
> > it?
>
> Screen automatically performs setiud root on installation, but I did
> verify that this is correctly set. I've even temporarily inflated
> permissions to verify:
> -rwsr-xr-x 1 root sys 296976 Apr 22 13:24 screen@
>
> My testing scenario is as follows:
> I have my desktop pc connected to the LAN, and open a telnet session
> to the target server via the termlite application. This is my control
> connection that I use for monitoring the processes (ie screen -ls to
> see detached ot attached state and ps -af commands to see running
> processes).
> Using my laptop which is also connected to the LAN, I open a telnet
> session to the target server using termlite, launch screen from the
> command line, and run my executeable.
> I can manually detach the session, verifiy status in the desktop
> telnet session is detached, reattach, etc with no issues.
> To simulate a loss of network connection I quite simply unplug the
> network cable from my laptop and wait for the termlite session to
> disconnect, while I monitor the server side status from the desktop.
> The screen session remains in the attached state to the ttyp from the
> laptop session. While in this state it is possible to force a detach
> and attach from the desktop pc, but that isn't the real goal as I need
> to restablish the connection with the orignial pc. It appears to
> remain in this state until I reconnect the network cable to the laptop
> and then initiate a new telnet connection to the server. As soon as
> the laptop initiates the new session - all processes are lost -
> meaning the screen processes and all the child processes of the screen
> application, and a "screen -ls" command yields "no sockets found in
> /tmp/screens/S-user"
>
> If I just close the termlite application without exiting the server
> application and logging off - the processes just die, which I
> understood was not supposed to occur when using screen, so I am sure
> that something here is not right, I'm just not sure where else to
> look.
Try getting it all up and running (telnet, screen, test programs under
screen) -- then kill off the parent telnetd. Your "before" process tree
should look something like:
init
inetd
telnetd
-sh # or whatever login shell
screen
app 1
app 2
app 3
Use `kill -9` on the telnetd to make sure that it doesn't do _any_
cleanup. (People use `kill -9` far too readily, but in this case I
really want to make sure that telnetd just disappears off the face of
the earth.) When you kill the telnetd, you should have:
init
screen
app 1
app 2
app 3
inetd
If they all die, something is wrong in how your `screen` binary is
built.
If they survive, something is wrong in how `telnetd` is dying;
presumably something that the client sends it during its death throes.
And if they survive, then running `screen -r` from another tty should
bring them back. If that fails (yet the apps are still running),
something else is wrong with your `screen` binary. I don't expect you
to get here; you've already demonstrated that manual detach/reattach
works. (Did you detach, log out, login, attach? From a different tty?
But that's all going to work. Your problem is in the moment of
catastrophic detachment.)
BTW, `screen -r -D` means "attach to that screen over there, and if
anyone else happens to be attached to it, forcibly detach them and log
them off". ("-d" means "forcibly detach and don't log them off").
>Bela<
- Next message: tony_at_pcunix.com: "Re: The reason Baystar wants its money back from SCOG"
- Previous message: Joe Dunning: "Re: OSR 5.0.6 relicensing"
- In reply to: Steve Bushore: "Re: GNU Screen on OpenServer 5.0.6"
- Next in thread: Dan Skinner: "Re: GNU Screen on OpenServer 5.0.6"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
