In current stable kernels (i.e. the latest 2.0.xx release or even one of the 1.2.xx series) and current shared libraries (libc version 5.x) there should be no bug to interfere with this software.
If you have a really old Linux system, notice that Linux kernel versions prior to 0.99pl15 have a bug in the serial handshake code, that is, if the ‘CRTSCTS’ flag is set, software flow control (XON/XOFF) won’t work. The alarm() call is broken in 4.1 and 4.4.2 libraries, which sometimes results in aborting the fax receiving.
On very recent systems using the GNU Libc, you must use mgetty 1.1.10 or higher, as the timeout handling on all previous versions doesn’t work under glibc. Unfortunately, this means that the version of mgetty shipped with RedHat 5.0 (1.1.9) won’t work. Upgrade!
Hardware handshake (RTS+CTS) on Linux works flawlessly (but only if mgetty
is compiled with POSIX_TERMIOS, but that is default on Linux
anyway). Nevertheless, the scrts.c program in contrib/ is
still provided, it has some other uses, too.
Linux has no poll(S), so, don’t #define USE_POLL, and the default,
USE_SELECT, will be used.
Important note: Use the /dev/ttyS* devices for getty and
for dial-out (that is, for kermit, uucico, cu, seyon, ...) - never
use /dev/cua*. Dialing out on /dev/cua* will result in the
error message “device busy”. (There are reasons why mgetty cannot
use the “ttyS* vs. cua* kernel locking mechanism”, see
below). If all programs agree on using /dev/cua* only,
it will work, too - but they have to agree on one variant.
For some background about ttyS vs. cua, you might want to read a mail from the author of the Linux serial drivers, Ted Ts’o, posted to the Linux-PPP mailing list. I have included it in doc/ttyS-cua.txt.
Some guys seemingly can’t resist posting misinformation to the net all the
time, don’t believe ’em. The /dev/cua* devices are not
different from the /dev/ttyS* devices concerning data flow or modem
control lines. The only difference is how the device reacts if you do an
open(): Opening /dev/ttyS* normally blocks until the “carrier
detect” line goes active (unless open() is called with the
O_NDELAY flag; mgetty and all dial-out programs do that), and
opening /dev/cua* will return an error message (errno=EBUSY)
if another process has the device already open, thus preventing
dial-out on /dev/cua* if mgetty is active on
/dev/ttyS*.
We use /dev/ttyS* all the time for dial-in and for dial-out, and believe me, it works, and it’s the only combination that will work properly. The kernel locking mechanism only works if you use modem auto-answer (the getty process sleeps until the modem gets a carrier), and mgetty uses manual answer (it waits for the RING message from the modem), which will save your callers a lot of grief because their calls will only be answered if your computer is ready to receive a call. Part of the motivation for writing mgetty was being tired of losing lots of money for useless calls to a hung machine.
I’d recommend against using /dev/modem as a link to the real
device, but if you do that, make it a hard link to the
appropriate /dev/ttyS*. A soft link will cause problems with the
device ownership because of a peculiarity in the linux chown()
implementation (that I refuse to work around).
If you get into trouble with write permissions on ttySx, you may add
a new group ‘dialout’ to /etc/group, then
chown .dialout /dev/ttySx your device, and add your users to
the dialout group. Don’t forget to add the system user ‘uucp’ to
that group (UUCP needs to have modem access), and make sure,
port-group in mgetty’s configuration file is set up correctly.
The concept of such a dialout group is already used in most Linux
distributions today.
There are various different init and last programs out there,
some work with mgetty, some don’t. If you get some strange output from
who or last and are using a different init program
than the sysv init, try to define -DNO_SYSVINIT. That should
help.
I’ve been told that it’s necessary to do that if you use the
simple-init.
Anyway, I can only strongly recommend to switch over to
SysVinit if you use simple init, since the latter seems to
be severely broken regarding utmp and controlling tty handling.
If you have problems because of an uninitialized TERM environment
variable (which really isn’t getty’s job, but getty_ps insists on
doing it, and people rely on it), use the term … config file
option to set it according to your needs.
If you’re experiencing problems with hanging /bin/login processes,
See login-hang.
Recently, I have received a number of bug reports concerning operation in systems using one or more Cyclades serial boards. There is some incompatibility between the standard Cyclades driver and the GNU CC 2.7.2, which can result in system lockups. Upgrade to the very latest Linux driver, which can be found on ftp.cyclades.com. I have received reports that the driver version 2.1 works fine (85 modems on one system, connected to 3 Cyclom Ye boards!).