UNIX System Administration Handbook - Evi Nemeth [71]
Entries in inittab are of the form
id:run-levels:action:process
Here’s a simple example of an inittab file:
::sysinit:/etc/setclk /dev/console 2>&1
co:234:respawn:/etc/getty console console
11:234:respawn:/etc/getty tty11 9600
12:234:off:/etc/getty tty12 9600
In this format, id is a one or two-character string used to identify the entry. id can be null, as in the first line. For terminal entries, it is customary to use the terminal number as the id.
run-levels enumerates the run levels to which the entry pertains. If no levels are specified (as in the first line), then the entry is valid for all run levels. The action field tells how to handle the process field; some universally understood values are listed in Table 7.7. Some systems support additional options.
Table 7.7 Common values for the /etc/inittab action field
If one of the run-levels matches the current run level and the action field indicates that the entry is relevant, init uses sh to execute (or terminate) the command specified in the process field. The Wait? column in Table 7.7 tells whether init waits for the command to complete before continuing.
In the example inittab file above, the first line sets the clock, the middle lines spawn getty processes, and the last line ensures that there is no getty on tty12.
The command telinit -q makes init reread the inittab file.
The /etc/gettydefs file
Like the gettytab file, gettydefs defines port configurations used by getty. A system will usually have one or the other, never both. The gettydefs file looks like this:
console# B9600 HUPCL # B9600 SANE IXANY #login: #console
19200# B19200 HUPCL # B19200 SANE IXANY #login: #9600
9600# B9600 HUPCL # B9600 SANE IXANY HUPCL #login: #4800
4800# B4800 HUPCL # B4800 SANE IXANY HUPCL #login: #2400
2400# B2400 HUPCL # B2400 SANE IXANY HUPCL #login: #1200
1200# B1200 HUPCL # B1200 SANE IXANY HUPCL #login: #300
300# B300 HUPCL # B300 SANE IXANY TAB3 HUPCL #login: #9600
The format of an entry is
label# initflags # finalflags # prompt #next
getty tries to match its second argument with a label entry. If it is called without a second argument, the first entry in the file is used. The initflags field lists ioctl flags that should be set on a port until login is executed. The finalflags field sets flags that should be used thereafter.
There must be an entry that sets the speed of the connection in both the initflags and the finalflags. The flags available vary by system; check the gettydefs man page for authoritative information (usually, the flag names are the same ones used when setting the options from a C program).
The prompt field defines the login prompt, which may include tabs and newlines in backslash notation. The next field gives the label of an inittab entry that should be substituted for the current one if a break is received. This was useful decades ago when modems didn’t negotiate a speed automatically and you had to match speeds by hand with a series of breaks. Today, it’s an anachronism. For a hardwired terminal, next should refer to the label of the current entry.
Each time you change the gettydefs file, you should run getty -c gettydefs, which checks the syntax of the file to make sure that all entries are valid.
Solaris and sacadm
Rather than traditional UNIX gettys that watch each port for activity and provide a login prompt, Solaris has a convoluted hierarchy called the Service Access Facility that controls TTY monitors, port monitors, and many other things that provide a lot of complexity but little added functionality.
To set up a serial port to provide a login prompt, you must first configure a “monitor” that watches the status of the port (ttymon). You then configure a port monitor that watches the TTY monitor. For example, to set up a 9,600 baud monitor on ttyb to print a login prompt with terminal type VT100, you’d use the following commands.
# sacadm -a -p myttymon -t ttymon -c /usr/lib/saf/ttymon -v 1
# pmadm -a -p myttymon -s b -i root -fu -v 1 -m "`ttyadm