When a child process is created, a number
of variables are inherited from the parent process, including the real and effective user IDs, the real and effective group IDs, the umask , the terminal, the current working directory, and the environment variables.
Processes are generally permitted to run on a CPU until their timeslice the amount of time allocated to them by the scheduling algorithmis over, at which point another process is scheduled to be run.
However, processes frequently give up the CPU early because they reach a point when they need a resource to continue; this is called blocking . This is often due to slow input/output operations; no matter how fast your disk drive is, the CPU is still faster, so when one process is waiting for disk data, another process can be executing.
The difference between your typing speed and your CPU speed is even greater; most people type six characters per second or less, so on a 3 GHz PC, the CPU will average at least 500 million operations between keystrokes.
Since processes are usually waiting for data, it's not uncommon for programs to run for only a few seconds a day. I've been using my X display server heavily all day, and it's accumulated less than 30 minutes of CPU time; my POP3 mail server, which is accessed 600 times and transfers several hundred megabytes of data each day, accumulates less than 20 seconds of CPU time a day.
The 2.6 kernels now used in Fedora do fully preemptive scheduling, which means that when data does arrive for a sleeping process, and that sleeping process has a higher priority than the process currently running, the kernel will preempt the running process and immediately schedule the new process for execution (instead of waiting for the currently executing process to reach the end of its timeslice).
The kernel dynamically changes the priority of a process based on the amount of time since it last executed, the amount of time it has executed recently, the amount of I/O it is performing, and the nice value.
To terminate a running process, a numeric signal is sent to that process. To see all of the available signals, use the -l argument to kill , which shows the signal names and numbers:
$ kill -l
1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL
5) SIGTRAP 6) SIGABRT 7) SIGBUS 8) SIGFPE
9) SIGKILL 10) SIGUSR1 11) SIGSEGV 12) SIGUSR2
13) SIGPIPE 14) SIGALRM 15) SIGTERM 17) SIGCHLD
18) SIGCONT 19) SIGSTOP 20) SIGTSTP 21) SIGTTIN
22) SIGTTOU 23) SIGURG 24) SIGXCPU 25) SIGXFSZ
26) SIGVTALRM 27) SIGPROF 28) SIGWINCH 29) SIGIO
30) SIGPWR 31) SIGSYS 34) SIGRTMIN 35) SIGRTMIN+1
36) SIGRTMIN+2 37) SIGRTMIN+3 38) SIGRTMIN+4 39) SIGRTMIN+5
40) SIGRTMIN+6 41) SIGRTMIN+7 42) SIGRTMIN+8 43) SIGRTMIN+9
44) SIGRTMIN+10 45) SIGRTMIN+11 46) SIGRTMIN+12 47) SIGRTMIN+13
48) SIGRTMIN+14 49) SIGRTMIN+15 50) SIGRTMAX-14 51) SIGRTMAX-13
52) SIGRTMAX-12 53) SIGRTMAX-11 54) SIGRTMAX-10 55) SIGRTMAX-9
56) SIGRTMAX-8 57) SIGRTMAX-7 58) SIGRTMAX-6 59) SIGRTMAX-5
60) SIGRTMAX-4 61) SIGRTMAX-3 62) SIGRTMAX-2 63) SIGRTMAX-1
64) SIGRTMAX
Each of these signals has a specific meaning, which can usually be determined from the signal name; for example, SIGHUP is the hangup signal, SIGINT is the interrupt signal (sent when you use Ctrl-C to try to interrupt a program running on a terminal or character-mode VT), SIGFPE is the signal for floating-point exceptions (such as division by zero), and SIGPWR is the signal for a power failure. Most of these signals are generated automatically by the kernel and basic server processes.
In most cases, a process can arrange to catch a particular signal and do something; for example, a text editor might save the current file when SIGHUP is received (the connection to the terminal is lost). If the process has not arranged to catch a signal, a default action is taken. In most cases, the default action is to terminate the process, but the default for some signals (such as SIGPWR ) is simply to ignore the signal and keep on running.
SIGTERM is used to request that a program terminate itself. Most programs catch this signal and clean up before they terminate, deleting any temporary files, saving data if necessary, informing network peers that they are terminating (where appropriate), and so forth. This is the default signal sent by top and kill , and the signal sent by the GNOME System Monitor when you specify End Program.
SIGKILL is uncatchable. It always terminates a program. This is useful when you wish to definitely terminate a program,
but it doesn't give the program an opportunity to shut down gracefully, so files and network communications may be left in half-finished states, which may cause future problems. For this reason, it should be used as a last resort. SIGKILL is the signal sent by the Kill Program option in System Monitor and the Kill button in KSysGuard.