Go to the first, previous, next, last section, table of contents.


Linux

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 section mgetty works, /bin/login hangs.

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!).


Go to the first, previous, next, last section, table of contents.