Text-Terminals on Linux

getty command in linux

14.1 Getty (used in /etc/inittab)

Introduction to Getty

In order to have a login process run on a serial port (and the terminal connected to it) when the computer starts up (or switches run levels) a getty command must be put into the /etc/inittab file. Running getty from the command line may cause problems (see If getty run from command line: Programs get stopped to see why ). Getty GETs a TTY (a terminal) going.

Each terminal needs its own getty command. There is also at least one getty command for the console in every /etc/inittab file. Find this and put the getty commands for the real terminals next to it. This file may contain sample getty lines for text terminals that are commented out so that all you need to do is to uncomment them (remove the leading #) and change a few arguments.

The arguments which are permitted depend on which getty you use:
Two gettys best for directly connected terminals are:

Two gettys best for dial-in modems (avoid for directly connected terminals) are:

  • mgetty: the best one for modems; works for terminals too but inferior
  • uugetty: for modems only; part of the getty_ps package

Simple gettys to use if you don't use a real text-terminal. Most Linux users use one of these at their monitor:

  • mingetty
  • fbgetty
  • fgetty
  • rungetty

Your Linux distribution may come with either ps_getty or agetty for text-terminals. Some distributions supply neither. Unfortunately, they often just call it "getty" so you may need to determine which one you have since the arguments you put after it in /etc/inittab differ.

Debian uses agetty (in the util-linux package). RedHat and Fedora used ps_getty which is at: ps_getty

As a last resort to try to determine which getty you have, you might check out its executable code (usually in /sbin). ps_getty has /etc/gettydefs embedded in this code. To search for it, go to /sbin and type:
strings getty | grep getty
If getty is actually agetty the above will result in nothing. However if you have agetty typing:
getty -h
should show the options [-hiLmw].

If you don't have the getty you want check other distributions and the alien program to convert between RPM and Debian packages. The source code may be downloaded from Getty Software.

If you are not using modem control lines (for example if you only use the minimum number of 3 conductors: transmit, receive, and common signal ground) you should let getty know this by using a "local" flag. The format of this depends on which getty you use.

Getty exits after login (and can respawn)

After you log in you will notice (by using "top", "ps -ax", or "ptree") that the getty process is no longer running. What happened to it? Why does getty restart again if your shell is killed? Here's why.

After you type in your user name, getty takes it and calls the login program telling it your user name.

The getty process is replaced by the login process. The login process asks for your password, checks it and starts whatever process is specified in your password file. This process is often the bash shell. If so, bash starts and replaces the login process. Note that one process replaces another and that the bash shell process originally started as the getty process. The implications of this will be explained below.

Now in the /etc/inittab file, getty is supposed to respawn (restart) if killed. It says so on the line that calls getty. But if the bash shell (or the login process) is killed, getty respawns (restarts).

Why? Well, both the login process and bash are replacements for getty and inherit

* Text Terminal How-To Index

the signal connections establish by their predecessors. In fact if you observe the details you will notice that the replacement process will have the same process ID as the original process. Thus bash is sort of getty in disguise with the same process ID number. If bash is killed it is just like getty was killed (even though getty isn't running anymore). This results in getty respawning.

When one logs out, all the processes on that serial port are killed including the bash shell.

This may also happen (if enabled) if a hangup signal is sent to the serial port by a drop of DCD voltage by the modem. Either the logout or drop in DCD will result in getty respawning. One may force getty to respawn by manually killing bash (or login) either by hitting the k key, etc. while in "top" or with the "kill" command. You will likely need to kill it with signal 9 (which can't be ignored).

If getty run from command line: Programs get stopped

You should normally run getty from inside /etc/inittab and not from the command line or else some programs running on the terminal may be unexpectedly suspended (stopped). Here's why (skip to the next section if the why is not important to you). If you start getty for say ttyS1 from the command line of another terminal, say tty1, then it will have tty1 as its "controlling terminal" even though the actual terminal it runs on is ttyS1. Thus it has the wrong controlling terminal.

But if it's started inside the inittab file then it will have ttyS1 as the controlling terminal (correct).

Even though the controlling terminal is wrong, the login at ttyS1 works fine (since you gave ttyS1 as an argument to getty). The standard input and output are set to ttyS1 even though the controlling terminal remains tty11.

Other programs run at ttyS1 may inherit this standard input/output (which is connected to ttyS1) and everything is OK. But some programs may make the mistake of trying to read from their controlling terminal (tty1) which is wrong. Now tty1 may think that these programs are being run in the background by tty1 so an attempt to read from tty1 (it should have been ttyS1) results in stopping the process that attempted to read. (A background process is not allowed to read from its controlling terminal.). You may see a message something like: "[1]+ Stopped" on the screen. At this point you are stuck since you can't interact with a process which is trying to communicate with you via the wrong terminal. Of course to escape from this you can go to another terminal and kill the process, etc.

agetty (may be named getty)

An example line in /etc/inittab:

 S1:23:respawn:/sbin/getty -L 19200 ttyS1 vt102
S1 is from ttyS1. 23 means that getty is run upon entering run levels 2 or 3. respawn means that if getty (or a process that replaced it such as bash) is killed, getty will automatically start up (respawn) again. /sbin/getty is the getty command. The -L means Local (ignore modem control signals). -h (not shown in the example) enables hardware flow control (same as stty crtscts). 19200 is the baud rate. ttyS1 means /dev/ttyS1 (COM2 in MS-DOS). vt102 is the type of terminal and this getty will set the environment variable TERM to this value. There are no configuration files. Type "init q" on the command line after editing getty and you should see a login prompt.

Agetty's auto-detection of parity problems

The agetty program will attempt to auto-detect the parity set inside the terminal (including no parity). It doesn't support 8-bit data bytes plus 1-bit parity. See 8-bit data bytes (plus parity).

If you use stty to set parity, agetty will automatically unset it since it initially wants the parity bit to come thru as if it was a data bit. This is because it needs to get the last bit (possibly a parity bit) as you type your login-name so that it can auto-detect parity. Thus if you use parity, enable it only inside the text-terminal and let agetty auto-detect it and set it at the computer. If your terminal supports received parity, the login prompt will look garbled until you type something so that getty can detect the

parity. The garbled prompt will deter visitors, etc. from trying to login. That could be just what you want.

There is sometimes a problem with auto detection of parity. This happens because after you first type your login name, agetty starts the login program to finish logging you in. Unfortunately, the login program can't detect parity so if the getty program failed to determine the parity then login will not be able to determine it either.

If the first login attempt fails, login will let you try again, etc. (all with the parity set wrong). Eventually, after a number of failed attempts to login (or after a timeout) agetty will start up again and start the login sequences all over again. Once getty is running again, it may be able to detect the parity on the second try so everything may then work OK.

With wrong parity, the login program can't correctly read what you type and you can't log in. If your terminal supports received parity, you will continue to see a garbled screen. If getty fails to detect parity an /etc/issue file is usually dumped to the screen just before the before the prompt, so more garbled words may appear on the screen.

Why can't agetty detect parity by the first letter typed? Here's an example: Suppose it detects an 8-bit byte with its parity bit 0 (high-order bit) and with an odd number of 1-bits. What parity is it?

Well, the odd number of 1 bits implies that it's odd parity. But it could also just be an 8-bit character with no parity. There's no way so far to determine which. But so far we have eliminated the possibility of even parity. The detection of parity thus proceeds by a process of elimination.

If the next byte typed is similar to the first one and also only eliminates the possibility of even parity, it's still impossible to determine parity.

This situation can continue indefinitely and in rare cases login will fail until you change your login-name. If agetty finds a parity bit of 1 it will assume that this is a parity bit and not a high-order bit of an 8-bit character. It thus assumes that you don't use meta-characters (high bit set) in your user name (i.e that your name is in ASCII).

One may get into a "login loop" in various ways. Suppose you only type a single letter or two for your login name and then hit return. If these letters are not sufficient for parity detection, then login runs before parity has been detected. Sometimes this problem happens if you don't have the terminal on and/or connected when agetty first starts up.

If you get stuck in this "login loop" a way out of it is to hit the return key several times until you get the getty login prompt. Another way is to just wait a minute or so for a timeout. Then the getty login prompt will be put on the screen by the getty program and you may try again to log in.

8-bit data bytes (plus parity)

Unfortunately, agetty can't detect this parity. As of late 1999 it has no option for disabling the auto-detection of parity and thus will detect incorrect parity. The result is that the login process will be garbled and parity will be set wrong.

Thus it doesn't seem feasible to try to use 8-bit data bytes with parity.

getty (part of getty_ps)

(Most of this is from the old Serial-HOWTO by Greg Hankins)
For this getty one needs to both put entries in a configuration file and add an entry in /etc/inittab. Here are some example entries to use for your terminal that you put into the configuration file /etc/gettydefs.

 # 38400 bps Dumb Terminal entry
 DT38400# B38400 CS8 CLOCAL # B38400 SANE -ISTRIP CLOCAL #@S @L login: #DT38400
 # 19200 bps Dumb Terminal entry
 DT19200# B19200 CS8 CLOCAL # B19200 SANE -ISTRIP CLOCAL #@S @L login: #DT19200
 # 9600 bps Dumb Terminal entry
 DT9600# B9600 CS8 CLOCAL # B9600 SANE -ISTRIP CLOCAL #@S @L login: #DT9600

Note that the DT38400, DT19200, etc.

are just labels and must be the same that you use in /etc/inittab.

If you want, you can make getty print interesting things in the login banner. In my examples, I have the system name and the serial line printed. You can add other things: [blockquote

 @B The current (evaluated at the time the @B is seen) bps rate.
 @D The current date, in MM/DD/YY.
 @L The serial line to which getty is attached.
 @S The system name.
 @T The current time, in HH:MM:SS (24-hour).
 @U The number of currently signed-on users. This is a
 count of the number of entries in the /etc/utmp file
 that have a non-null ut_name field.
 @V The value of VERSION, as given in the defaults file.
 To display a single '@' character, use either '\@' or '@@'.

When you are done editing /etc/gettydefs, you can verify that the syntax is correct by doing:

 linux# getty -c /etc/gettydefs

Make sure there is no other getty or uugetty config file for the serial port that your terminal is attached to such as (/etc/default/{uu}getty.ttySN or /etc/conf.{uu}getty.ttySN), as this will probably interfere with running getty on a terminal. Remove such conflicting files if they exits.

Edit your /etc/inittab file to run getty on the serial port (substituting in the correct information for your environment - port, speed, and default terminal type):

 S1:23:respawn:/sbin/getty ttyS1 DT9600 vt100
Restart init:
 linux# init q

At this point, you should see a login prompt on your terminal. You may have to hit return to get the terminal's attention.


The "m" stands for modem. This program is primarily for modems and as of mid 2000 it will require recompiling to use it for text-terminals (unless you use hardware flow control --and that usually requires a hand-made cable).

For the documentation for directly connected terminals see the "Direct" section of the manual: mgetty.texi.

Look at the last lines of /etc/mgetty/mgetty.config for an example of configuring it for a terminal. Unless you say "toggle-dtr no" it will think that you have a modem and drop (negate) the DTR pin at the PC in a vain attempt to reset the non-existent modem.

In contrast to other gettys, mgetty will not attach itself to a terminal until someone hits any key of that terminal so you'll see a ? for the terminal in top or ps until this happens. The logs in /var/log/mgetty/ may show a few warning messages which are only applicable to modems which you may ignore.

Here's an example of the simple line you put in /etc/inittab:

 s1:23:respawn:/sbin/mgetty -r ttyS1