I screen, you screen, robocop kills screens

Jan 4 22:31 UTC 2005

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?

response 2 of 14:

Jan 5 04:09 UTC 2005

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.

response 4 of 14:

Jan 6 04:32 UTC 2005

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

response 6 of 14:

Jan 7 03:49 UTC 2005

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.

response 8 of 14:

Jan 13 12:14 UTC 2005

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.

response 10 of 14:

Nov 19 16:46 UTC 2011

It's probably due to robocop.