The "screen" program is a good thing.  Except when it isn't.

I don't actually use it often, so I'm no expert, but if you try the "screen"
command, the effect is pretty boring - it clears your screen and gives you
a new shell prompt.  Actually, what you are looking at is a new Grex session
running on a different psuedotty.  By typing control-A and then c you will
create a second session. You can toggle between the two with control-A
control-A.  You could be running party in one, and bbs in the other, and hey,
why not start another to run pine in.  With some practice you can switch
between all these different sessions.  Semi nice.

Another interesting thing you can do is detach sessions.  If you are dialed
in, running screen, you could ssh in to tty, and then do "screen -r -d" and
all the  sessions that were running on your dial-in screen will now be running
on your ssh session.  Or you can detach a session, log off of Grex, take a
plane to Tibet, log into Grex, and pick up the detached session, finding it
running just the way you left it.

Unless I get robocop running again.  Right now we have two users with detached
screen sessions on Grex.  They are not logged in, but they have screen
processes running, shell processes for each screen, and they could have
various other processes, like pine or something.  Typically these would not
be running, though they could be.  This is normally the kind of thing robocop
kills.  Abandoned processes left behind by users who have logged off.

Right now I'm having trouble getting robocop *NOT* to kill processes running
under active screen sessions.  There is no obvious way to tell what pseudottys
are being used by screen sessions.  What I'm thinking of doing is if a user
has any screen process running on his main pseudotty, then I won't kill any
processes belonging to that user, even if they are on different ttys or on
no tty.  Once the user logs out however or exits his main screen process,
all processes would be ripe for murder, including any detached sessions.
This is kind of sad though.

Any thoughts?

14 responses total.

This response has been erased.

Another thing I had though of was letting detached screen processes live
longer than other orphaned processes.  But if it was any serious amount of
time, it would be abused.  Probably like 15 minutes after logout would be as
much as I'd want to give people.

Screen would be quite handy for times when Grex's isp connection becomes
flaky, and people are being knocked off every few minutes. If someone were
in the middle of something, being able to reattach to a screen session after
being knocked off would be very nice.

I also think 15 minutes is completely reasonable for someone who needs to
detach toreboot his/her workstation, or switch to another computer.

Another feature I like about screen is the -h option which allows a nice
scrollback buffer with ctrl-a then ESC
This allows you to see any telegrams/messages you may have received while
refilling your coffee during a party session, etc

Screen sounds useful, but hte implementation doesn't sound as elegant as that
of virtual terminals in Linux and the BSDs.

The usefulness of screen is that you can run it on a remote system and
fully `detach' from it; login from somewhere else, and `re-attach' to
it.  That part is tremendously useful.

I linked this item over from garage1 to garage2 to add some comments.

I've spent some more time working on robocop.  I think it will now correctly
resist the temptation to kill attached screen processes and all the proceses
running under them.

It will, however, kill detached screen processes and all their children.  I'd
like to give detached screens a bit of a longer life, but it turns out to be
difficult to do.  There is no easy way to look at a detached screen and tell
how long it has been detached.  About all I could do is have robocop remember
screen processes from run to run and not kill them until, say, the fourth time
it sees them hanging around detached.  This requires introducing a whole new
type of logic into robocop.  Currently it never remembers anything from pass
to pass except it's file of fingerprints of special processes (sendmail,
screen, etc).  Maybe I'll do this someday, but not right away.

Robocop is, however, still firing blanks.  I need to study the performance
of the latest version some more before I load it's gun and let it really kill
processes.

i'm not certain that it always works in the following fashion, but it
appears to hold for netbsd so perhaps it will for openbsd as well.

summary:  a detached master has no ttys open (just ptys) and a fifo, the
fifo's last mod time tells you when the master was last controlled.

details, probably boring ...

when you reconnect screen passes the name of it's controlling terminal
to the selected master process (which is what maintains the sessions and
their ptys) via a fifo, which it then opens.  i.e., a connected master
can be found to have a tty open, the same tty as a running screen
program has as it's controlling terminal.  it will not be the master's
controlling terminal, in fact the master is always without a controlling
terminal.  e.g.,

] $ pstree -pu | grep malymi
]         |-screen-4.0.2(22326)-+-telnet(7660,malymi)
]         |                     `-ksh(25277,malymi)-+-grep(16026)
]         |             |-sshd(24647)---screen-4.0.2(24652,malymi)

] $ ps -axjc  [hand edited and sorted]
] USER       PID  PPID  PGID   SESS JOBC STAT TT      TIME COMMAND
] root     13915     1 13915 6ed380    0 Ss   ??   0:51.10 sshd
] root     24647 13915 24647  d2540    0 Ss   ??   0:00.11 sshd
] malymi   24652 24647 24652 a27bc0    0 Ss+  p4   0:00.03 screen-4.0.2
] root     22326     1 22326 215a40    0 Ss   ??   0:25.83 screen-4.0.2
] malymi    7660 22326  7660 45a000    0 SNs+ pu  38:15.48 telnet
] malymi   25277 22326 25277 e28d80    0 Ss   pd   0:00.03 ksh
] malymi   26898 25277 26898 e28d80    1 R+   pd   0:00.00 ps

22326 is a master -- as evidenced by having no controlling terminal.

] $ lsof -p 22326 | grep /dev/tty
] screen-4. 22326 root    4u  VCHR    4,4    0t12425  182973 /dev/ttyp4

a tty is open on fd 4 (ttyp4, the controlling terminal of pid 24652)
thus this is an attached master.

a master will also have fds open for ptys of the child sessions.  but
those are ptys, not ttys.

a master can be multi-attached [using -x instead of -r], so can have
multiple ttys open.

a master that is disconnected has no ttys open.

the master is controlled through a fifo, the modification time indicates
when the master was last controlled ...

| $ lsof -p 22326 | grep FIFO
| screen-4. 22326 root    3r  FIFO    8,3        0t0  159370
/tmp/screens/S-malymi/22326.ttyp4.rbt

| $ ls -l /tmp/screens/S-malymi/22326.ttyp4.rbt
| prw-------  1 malymi rbt  0 Jan 13 11:44
/tmp/screens/S-malymi/22326.ttyp4.rbt

which indeed is when i attached to this master.  the mod time did not
change while it was detached even with child sessions producing output.

I have had some trouble with my screen sessions being terminated if they are
idle more than a few minutes,this is even if the screen session is avtive and
undetached. Is this a robocop issue? This never happened before the upgrade
and I was just wondering if is due to the upgrade or if it due to robocop(i
realize this material is dated)

It's probably due to robocop.

Given that general users have no access to cron, the only way to have a 
script regularly do something is by running it as a background process 
(nohup) or via screen... neither of which work, of course with robocop 
on patrol!

Are there any alternatives for this kind of thing?  My use case is a 
simple one... I've written a script to check on a couple of RSS feeds 
that I follow -- some of which post time sensitive information.  I'd 
like to check these regularly, and fire off an email to myself if a 
change is detected.  Normally, I'd cron the script to run every 5 
minutes.

Thoughts?

-Adam

I've allowed you access to cron, Adam.

resp:11 Robocop's polling interval is 5 minutes.  Your script sounds like
it will run quickly; set it to run ever, say, three or 4 minutes.

Thanks guys... appreciate the assistance.

Response not possible - You must register and login before posting.

- Backtalk version 1.3.30 - Copyright 1996-2006, Jan Wolter and Steve Weiss