This repository was archived by the owner on Feb 25, 2022. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 2
Expand file tree
/
Copy pathSESS.draft2
More file actions
289 lines (218 loc) · 11 KB
/
SESS.draft2
File metadata and controls
289 lines (218 loc) · 11 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
An introduction to session management
Daniel J. Bernstein
draft 2
10/4/91
1. Session basics
< session, n. ... 4. any period of activity. >
When a user sits down in front of a multi-user computer, gives his login
name and password, and starts typing, he's begun a _session_. Within
that session he might read mail, edit files, compile and run programs,
and even play games. What happens if the screen explodes?
A typical UNIX system lets a user log in through a network, or over a
phone connection between the user's modem and the computer's modem. But
if the phone line suddenly becomes too noisy, or the network doesn't
work, the user's connection may drop. The system will then terminate the
login session. Any programs run by the user will be signalled that the
connection was hung up. If they ask the user for input, they won't get
any. If they produce output, the output will vanish.
Other operating systems are more helpful. VMS, for instance, keeps the
session running inside the computer. When the user establishes another
connection and logs in again, the computer asks if he'd like to
reconnect to the original session. Programs started under the session
won't notice what happened. This is a primitive form of _session
management_. (It is also an abuse of terminology, as the ``session''---
the ``period of activity''---really consists of two periods. On the
other hand, from the point of view of the programs under the session,
there hasn't been any interruption.)
This paper describes a session management system which the author has
developed for BSD UNIX and its variants. In section 2 we describe the
three fundamental operations making up the system. In section 3 we show
how the system appears to novice users. In section 4 we give several
examples of more complex session management techniques which cannot be
performed under VMS.
2. sess, disconnect, reconnect
The session management system consists of three basic operations. To
illustrate the operations we use pictures:
user ==== tty ==== csh (1)
A double line, such as ====, represents a two-way flow of information.
Here the user types characters, which the UNIX kernel processes inside a
tty device and then sends to the user's shell, csh. What csh prints is
then sent back through the tty to the user.
When csh starts a job, the picture changes:
---------------
/ \
user ==== tty ==== csh who
\ |
\ sort
\ |
------------ more
Here the user has started a pipeline, who | sort | more. To simplify the
illustration somewhat we pretend that all I/O from the pipeline is sent
through the shell:
user ==== tty ==== csh ---- who
\ |
\ sort
\ |
-- more
A job consisting of only one process looks like this:
user ==== tty ==== csh ==== vi
If the user's connection dies, the tty effectively disappears:
csh ==== vi
Without a place to send input and output, csh and vi receive the HUP
signal and die a messy death.
The first session management operation is sess. When the user, starting
from picture (1), types ``sess ksh'', he creates a session:
/------\ +------+
user ==== tty ==== csh ==== | conn | ==== | sess | === ksh
\------/ +------+
The session consists of the square box, called the _master_ because it's
in charge of session management, with ksh running below it. The session
is connected to the rounded box, also called the _signaller_ because it
signals csh when the session is finished. Normally both boxes are
completely transparent, and the user can start jobs under the session:
/------\ +------+
user ==== tty ==== csh ==== | conn | ==== | sess | === ksh ==== vi (2)
\------/ +------+
(In fact, from ksh's point of view, the sess box looks just like a tty.
It is actually a _pseudo-tty_, also known as a _pseudo-terminal_.
Further discussion of pseudo-terminals is beyond the scope of this
paper.)
What happens if the user's connection drops? As before, the original tty
disappears, and csh sputters and dies. The signaller disappears too:
+------+
| sess | === ksh ==== vi
+------+
However, the session keeps running. sess doesn't mind being
disconnected. It waits for a reconnect, as described below. Meanwhile,
ksh doesn't have the slightest inkling that the connection is gone.
The user can in fact force a disconnect manually. This is the second
fundamental operation. Starting from picture (2), if the user types
``disconnect'' to ksh, the connection will be severed:
user ==== tty ==== csh
+------+
| sess | === ksh ==== vi (3)
+------+
The signaller exits quietly, and the user can now type commands to csh.
How does the user reconnect to a disconnected session? He uses the third
fundamental operation, the reconnect command. The system assigns each
session a name. If the user starts a new session, it might look like
this:
/------\ +------+
user ==== tty ==== csh ==== | conn | ==== | sess | === qsh
\------/ +--p7--+
Here ``p7'' is this session's name. Say the disconnected session was
named ``qb'':
/------\ +------+
user ==== tty ==== csh ==== | conn | ==== | sess | === qsh
\------/ +--p7--+
+------+
| sess | === ksh ==== vi
+--qb--+
If the user types ``reconnect qb'' to qsh, nothing happens immediately,
but the signaller remembers his reconnect:
/------\ +------+
user ==== tty ==== csh ==== | conn | ==== | sess | === qsh
\-+qb+-/ +--p7--+
+------+
| sess | === ksh ==== vi
+--qb--+
As soon as session p7 exits (or is disconnected), the reconnect takes
effect:
/------\ +------+
user ==== tty ==== csh ==== | conn | ==== | sess | === ksh ==== vi
\------/ +--qb--+
Now it's just as if session qb had been connected all along. The user
can type commands to vi. If the connection disappears again, he can
reconnect again, any number of times.
Why doesn't reconnect take effect immediately? There are several
reasons. Perhaps the most important is that before reconnecting the user
may want to terminate the currently connected session---or he may want
to disconnect it, so that he can reconnect to it later. This reconnect
interface doesn't force one choice or the other. The user may also want
to perform some lengthy operations before reconnecting, and it's easier
to schedule the reconnect once and do it at his leisure than to have to
worry about the reconnect after all the operations. Finally, it is very
simple to simulate an immediate reconnect using the above operations, as
detailed in section 4.
3. Session management for users
Most users will never have to learn anything about the sess, disconnect,
or reconnect commands. If a connection dies, its owner will be shown a
message like this when he logs in again:
You have a disconnected session on /dev/ttyra, with these processes:
USER PID %CPU %MEM SZ RSS TT STAT START TIME COMMAND
shmoe 17790 0.0 0.9 176 504 ra T 12:47 0:01 vi paper.3
shmoe 17331 0.0 0.7 72 384 ra I 12:31 0:00 -bin/csh (csh)
shmoe 17330 0.0 0.5 104 264 ra S 12:31 0:00 pty -ds argv0 /bin/csh
Would you like to reconnect to that session?
If so, type its two-character extension, ra.
To instead start a new session as usual, just press return:
The user will recognize the ``paper.3'' he was editing, type ra, and be
reconnected to his session. The program which handles this is called
``sessmenu''. While perhaps not as friendly as the reconnect facilities
under some operating systems, sessmenu isolates even novices from the
trauma of losing important work.
All sessions also keep track of a long name assigned by the user. The
``sessname'' command displays or sets the current session name:
csh% sessname
session p7
csh% sessname 'writing net test program'
csh% sessname
session p7: writing net test program
csh%
The user can see all his sessions with ``sesslist'':
csh% sesslist
session p7 pid 16614 slave 16615 connected: writing net test program
session ra pid 8045 slave 8046 disconnected: finishing up paper.3
csh%
Two other useful commands are ``sesswho'', to show all sessions on the
system and their owners, and ``sesswhere'', to show where those sessions
are currently connected to. (The system administrator may disable these
commands for security reasons.)
4. Advanced session management techniques
By combining the sess, disconnect, and reconnect commands in simple
ways, a user can perform surprisingly powerful session operations. In
this section we give some such combinations. The reader may enjoy
drawing pictures to see how the commands work.
A user can reconnect to a disconnected session without finishing the
current session with ``sess reconnect xx''. Another method for doing an
immediate reconnect is ``reconnect xx; disconnect''. The second method
is symmetric: if the original session was yy, the user can flip back and
forth with
csh-yy% reconnect xx; disconnect
...
ksh-xx% reconnect yy; disconnect
...
csh-yy% reconnect xx; disconnect
and so on. To immediately reconnect to another session and finish the
current session, he can use ``reconnect xx; exit'' or ``exec reconnect xx''.
Say a user is in the middle of something---running a crucial
computation, perhaps, or ``talk''ing to another user---and decides to
record what's happening. With sess, reconnect, and disconnect, he can do
this without starting the program again:
[talk session going on, user types ^Z]
Stopped
csh% sess sh
$ sessname; disconnect
session rf
csh% reconnect rf; disconnect
reconnect: will connect to session rf when session p8 is done
pty: info: reconnecting to rf
pty: info: successfully connected to rf
$ sess reconnect p8 | tee talk-record
reconnect: will connect to session p8 when session q0 is done
pty: info: reconnecting to p8
pty: info: successfully connected to p8
csh% fg
[talk session continues as before]
Now everything in session p8 is recorded in talk-record. The recording
is completely transparent and does not require that ``talk'' be
terminated or restarted.
5. Where to find it
The session management system described here is freely available as part
of the pty 4.0 package. pty 4.0 works on BSD-derived UNIX systems.
The author's session management model is based on Bellovin's ``Session
Tty'' Manager [1], which is not as powerful as pty but is better
integrated into the login system.
References
[1] Bellovin, S. M. The ``Session Tty'' Manager. In USENIX Conference
Proceedings, San Francisco, Summer 1988, 339-354.