Process Relationship

We now discuss about the init process. This process always has a process ID of 1.  When a Unix system is started for normal multiuser operation, the kernel invokes the program /etc/init to start things up.  The init process runs with user ID of zero, so that it has superuser privileges. The operation of init depends on the unix system.

The init process forks a copy of itself, and then each child process execs the /etc/getty program.  This gives the picture shown in fig. 2.7.

getty sets the terminal's speed, outputs a greeting message, and waits for user to enter his/her login name.  After login name is entered, getty execs the program /bin/login, passing it his/her login name as argument.  The login program then looks up the login name in the /etc/passwd file and prompts his/her for a password, if required. If he/she enter a login name to the second getty shown in fig. 2.7, the picture becomes as shown in fig. 2.8.  The other getty processes in fig. 2.8 are waiting for someone to enter a login name.

The programs that have been run so far, init, getty, and login, have all been running with a user ID and an effective user ID of zero (the superuser). Also note that the process ID does not change when an exec occurs, so all the processes starting from the forked copy of init have the same process ID. Now that the login program knows who is logging in, it does the following:

• sets the current working directory to the login-directory field from the password file entry. This is done by calling the chdir system call.
• sets the group ID and the user ID, in that order, to the values specified in the password file entry.  This is done by calling the setgid and setuid system calls.
• execs the shell program specified by the password file entry, or /bin/sh if one is not specified.

The shell that is invoked by login is known as the login shell.  The parent process ID of all processes shown in fig. 2.9, other than the original init process (whose process ID is 1), is 1. This is because when init forks its child processes, the parent process ID of the child process is 1, and the parent process ID does not change when an exec occurs.

see this scenario.............

Looking only at the shell process, its normal action is to wait for the interactive user to enter a command line, which it then executes. For e.g. if you enter

date

the action taken are

1. the shell forks a copy of itself and waits for the child process to terminate.

2. The child process uses the PATH environment variable, to look for an executable file withthe name date.  If the environment variable were

PATH=/usr1/stevens/bin:/usr/local/bin:/usr/ucb:/bin:/usr/bin

the shell looks int he directory /usr1/stevens/bin, then the directory /usr/local/bin, and so on. Assuming the executable program is located in /bin/date the child process execs that program.

3. When the date program finishes, it calls exit with its return status, which terminates the child process and allows the wait to return to the parent process.