Configuring init  to start getty : the /etc/inittab file

When it starts up, init  reads the /etc/inittab  configuration file. While the system is running, it will re-read it, if sent the HUP signal; this feature makes it unnecessary to boot the system to make changes to the init  configuration take effect.

The /etc/inittab  file is a bit complicated. We'll start with the simple case of configuring getty  lines. Lines in /etc/inittab  consist of four colon-delimited fields:

id:runlevels:action:process

id

This identifies the line in the file. For getty  lines, it specifies the terminal it runs on (the characters after /dev/tty  in the device file name). For other lines, it doesn't matter (except for length restrictions), but it should be unique.

runlevels

The run levels the line should be considered for. The run levels are given as single digits, without delimiters. (Run levels are described in the next section.)

action

What action should be taken by the line, e.g., respawn to run the command in the next field again, when it exits, or once to run it just once.

process

The command to run.

To start a getty  on the first virtual terminal (/dev/tty1 ), in all the normal multi-user run levels (2-5), one would write the following line:

1:2345:respawn:/sbin/getty 9600 tty1

If you wanted to add terminals or dial-in modem lines to a system, you'd add more lines to /etc/inittab , one for each terminal or dial-in line. For more details, see the manual pages init (8), inittab (5), and getty (8).

If a command fails when it starts, and init  is configured to restart it, it will use a lot of system resources: init  starts it, it fails, init  starts it, it fails, init  starts it, it fails, and so on, ad infinitum. To prevent this, init  will keep track of how often it restarts a command, and if the frequency grows to high, it will delay for five minutes before restarting again.