sched, vhand and bdflush (with process IDs 0, 2 and 3 respectively). These processes are sections of kernel code which must be called periodically; vhand provides virtual memory paging services, sched provides swapping services, and bdflush flushes the buffer cache periodically. None of these processes can be killed; they are part of the kernel, and are essential to the correct running of the UNIX system.
Finally the kernel creates a third process; init, or process 1. init starts up as a dummy process, then achieves independence: it runs as the first true process on the system. init runs continuously; it is the parent of all other processes on the system.
Run levels define the behavior of init, and by extension those processes which run on the system when it is at any given level. The system starts at run level 0 (shutdown) and then enters run level 1, single user mode. At level 1, only the root filesystem is mounted and only processes connected to the console can run; this means that it is safe to check the unmounted filesystems for integrity without risking any other processes altering them. At other run levels, init starts up the daemon processes that provide various services, and enters multiuser mode.
init executes other programs via the fork system call. Each time init calls fork, it passes control to the kernel, which creates a new entry in the process table, allocates a temporary storage area called a U-area, and copies the calling processes' local data (including the stack) into the U-area. The kernel then returns control to the child process, which may make an exec call, overwriting itself with a new program. init periodically reads a file called /etc/inittab, which tells it which programs to execute at any given run level.
Multiuser mode
When the system reaches a suitable run level (2 or higher), init starts a series of processes called gettys. (In /etc/inittab each line specifying a getty process includes the option respawn. This means that whenever a getty process dies, init spawns a replacement with the same parameters immediately. The getty options include a ttyserial line, which it serves.
The job of the getty process is to display a login prompt, then wait for input. If you try to log in on the terminal, getty works out your serial line speed as you type your name, then execs a login process. The login process reads your password; if it is incorrect the process dies, and init spawns another getty on your terminal. If you enter a valid password, login then runs a shell, which inherits your terminal, your identity and your access permissions.
When your login shell finishes, there are no processes left attached to your terminal, so init respawns another getty to wait for a login. Thus, while the system is in multiuser mode, each terminal continually executes a four stage cycle: init-getty-login-shell.
It is not uncommon for a system to remain in multiuser mode for days or weeks at a time. However, it is necessary for the system administrator to shut it down for maintenance at regular intervals. (Performance is likely to suffer if a system is kept running for several weeks without a shutdown.)
Finally the kernel creates a third process; init, or process 1. init starts up as a dummy process, then achieves independence: it runs as the first true process on the system. init runs continuously; it is the parent of all other processes on the system.
Run levels define the behavior of init, and by extension those processes which run on the system when it is at any given level. The system starts at run level 0 (shutdown) and then enters run level 1, single user mode. At level 1, only the root filesystem is mounted and only processes connected to the console can run; this means that it is safe to check the unmounted filesystems for integrity without risking any other processes altering them. At other run levels, init starts up the daemon processes that provide various services, and enters multiuser mode.
init executes other programs via the fork system call. Each time init calls fork, it passes control to the kernel, which creates a new entry in the process table, allocates a temporary storage area called a U-area, and copies the calling processes' local data (including the stack) into the U-area. The kernel then returns control to the child process, which may make an exec call, overwriting itself with a new program. init periodically reads a file called /etc/inittab, which tells it which programs to execute at any given run level.
No comments:
Post a Comment