Logins via terminals

Figure 8.1 shows how logins happen via terminals. First, init  makes sure there is a getty  program for the terminal connection (or console). getty  listens at the terminal and waits for the user to notify that he is ready to login in (this usually means that the user must type something). When it notices a user, getty  outputs a welcome message (stored in /etc/issue ), and prompts for the username, and finally runs the login  program. login  gets the username as a parameter, and prompts the user for the password. If these match, login  starts the shell configured for the user; else it just exits and terminates the process (perhaps after giving the user another chance at entering the username and password). init  notices that the process terminated, and starts a new getty  for the terminal.

  
Figure 8.1: Logins via terminals: the interaction of init , getty , login , and the shell.

Note that the only new process is the one created by init  (using the fork  system call); getty  and login  only replace the program running in the process (using the exec  system call).

A separate program, for noticing the user, is needed for serial lines, since it can be (and traditionally was) complicated to notice when a terminal becomes active. getty  also adapts to the speed and other settings of the connection, which is important especially for dial-in connections, where these parameters may change from call to call.

There are several versions of getty  and init  in use, all with their good and bad points. It is a good idea to learn about the versions on your system, and also about the other versions (you could use the Linux Software Map to search them). If you don't have dial-in's, you probably don't have to worry about getty , but init  is still important.