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
|
------------------------------------------------------------------------
Release: 2.0.7j
READ ALL THE RELEASE NOTES! THESE ARE "UNOFFICIAL" RELEASES
If you're using 28.8 modems or faster for dialins, you probably
want to upgrade. This release is happening only because of
an unbearable number of pleas from Usenet. Please read the
Serial-HOWTO before you post questions in the comp.os.linux.*
and linux.dev.* groups.
uugetty and getty should now accept 57600, 115200 and 230400
as valid speeds. Hopefully this will keep us going for six
months until we need to up them again.
This release DOES NOT support speeds lower than 2400!
If you're trying to use adaptive answer with Hylafax's
faxgetty, you should use agetty which will accept a
connection from stdin.
No support for this release.
Sho Nakagama
bbs.fdu.edu
February 21, 1997
------------------------------------------------------------------------
Release: 2.0.7i
If you're using 'uugetty' for dial-in's, you should upgrade
to this release.
uugetty sometimes hangs while trying to open() a modem port.
The last line from /usr/adm/debug will look like ...
"... D_INIT: opening line /dev/ttyS1"
This release fixed the above problem so that failure to open the
"tty" after 3 attempts will terminate the program so that init
can restart another uugetty, rather than hanging forever!
Jeff Chua
jchua@fedex.com
April 28 96
------------------------------------------------------------------------
Release: 2.0.7h
This release fixes a bug that I saw a long time ago, but it went
away . . . until now (while upgrading to 1.3.xx kernel). The problem
shows up as a segmentation fault if the term type is not specified for
a getty or uugetty process. I have not been specifying the terminal
type for serial lines in my /etc/inittab file. For example, I have
# Serial lines
s0:5:respawn:/sbin/uugetty ttyS0 38400
as opposed to
# Serial lines
s0:5:respawn:/sbin/uugetty ttyS0 38400 vt100
In my case, uugetty would default to a term type of 'unknown' and
would never initialize its clear screen variable (clrscr), causing a
segmentation fault every time the login process began. A minor fix,
so it should work either way now.
Mike Blatchley
Mike_Blatchley@maxtor.com
------------------------------------------------------------------------
Release: 2.0.7g
This releases is a minor modification of the 2.0.7f `release'. The main
problem with 2.0.7f is that some files are missing which are necessary for
the compilation. 2.0.7g contains the missing files (uufuncs.* and utmp2.c
which can be obtained from the getty_ps-2.0.7e and the agetty-1.9.1a
packages).
I also fixed two bugs. Getty now should work even if there is no utmp entry
for the line on startup.
The other bug I fixed is not really a bug, only a necessary change to make
callout programs work together with getty (and its WAITFOR option) on future
kernels. The problem is that POSIX allows to implicitly vhangup() a
terminal when the session leader of the terminal exits. With the WAITFOR or
WAITCHAR option getty waits for a character on its standard input. When a
character arrives it checks for logs on the line and if it finds one, it
exits. But this exit may vhangup() the callout program which locked the
device. To prevent this, in this version getty drops its controlling
terminal before exiting.
In this version getty does a chmod(devname, 0600) before it opens and
vhangups the terminal.
Note that at present it seems that there is not maintainer for getty_ps.
The original maintainer no longer works on it. I do not maintain it
either. If you would like to become a maintainer, please contact
Kris Gleason <gleasokr@boulder.colorado.edu>
but do not mention getty in the subject since Kris has a mail robot which
drops these messages.
In this package I included precompiled elf binaries. a.out binaries
dynamically linked with libc.so.4.5.26 are also available, just unpack the
aout-bins.tgz archive.
Zoltan Hidvegi
hzoli@cs.elte.hu
------------------------------------------------------------------------
Release: 2.0.7f
The current getty's under Linux change the 2-character vector ut_id to
be the first 2 characters of the line. This causes problems for
3-character names of ports such as ttyS20 because ttyS20, ttyS21, etc
all get the same abbreviation.
In addition, the utmp2.c file as distributed keys off ut_id to determine
which utmp entry to replace in "setutent", so changing the ut_id field
confuses setutent.
These problems lead to only one such terminal being seen from "who",
"finger", "talk", etc, as well as infinite growth of /etc/utmp.
Init sets up ut_id from the 2-character key at the front of each line
of the /etc/inittab file, and the mods to getty_ps in this directory
cause it to leave that key untouched.
The mods to getty_ps in this directory appear to fix the problems mentioned
above.
The following output of /usr/src/init/dump < /etc/utmp shows correct
utmp entries generated by a fixed agetty (for tty2-tty6) and incorrect
entries generated by a broken uugetty (ttyC* and tty1):
Utmp dump of stdin
[5] [22634] [c1] Jul 27 13:32:59
[6] [22588] [c2] tty2 Jul 27 13:27:25
[6] [22589] [c3] tty3 Jul 27 13:27:29
[7] [22317] [c5] alan tty5 Jul 27 13:16:58
[6] [22718] [c4] tty4 Jul 27 13:43:25
[6] [22593] [c6] tty6 Jul 27 13:27:41
[5] [22724] [t8] Jul 27 13:43:36
[6] [22724] [ ] ttyC14 Jul 27 13:43:37
[0] [00000] [ ] Dec 31 17:00:00
[0] [00000] [ ] Dec 31 17:00:00
[0] [00000] [ ] Dec 31 17:00:00
[0] [00000] [ ] Dec 31 17:00:00
[0] [00000] [ ] Dec 31 17:00:00
[6] [22634] [1 ] tty1 Jul 27 13:33:00
This is showing alan logged in on tty5, with tty2, tty3, tty4, and tty6
waiting in agetty. The [5]'s are in init, [6]'s are getty/login,
[7]'s are user processes, and [0]'s are free entries. It should be
unusual to see a process in init if the terminal is enabled.
The duplicate entries for pid's 22634 and 22724 for ttyC14 are caused
by the broken gettys.
Note that utmp seems to be growing, in that there are 5 empty entries
but tty1's entry got stuck at the end of the file. The released
utmp2.c, in setutent, fails to find the entry for tty1 (because its
searching for "1 " and the original entry was "c1") and so it adds
another entry at the end of the file.
Because pty's won't have unique ut_id's either, the regular utmp code
won't work for them. I've added a "rewriteutent" call which just
overwrites the last entry returned by getutent. This eliminates
the sequential search that setutent was performing to match ut_id,
so performance should be improved as well as reliability.
Alan Wendt
alan@ezlink.com
|
