📄 581-583.html
字号:
<HTML>
<HEAD>
<TITLE>Using Linux:Managing the Kernel</TITLE>
<META NAME="ROBOTS" CONTENT="NOINDEX, NOFOLLOW">
<SCRIPT>
<!--
function displayWindow(url, width, height) {
var Win = window.open(url,"displayWindow",'width=' + width +
',height=' + height + ',resizable=1,scrollbars=yes');
}
//-->
</SCRIPT>
</HEAD>
-->
<!--ISBN=0789716232//-->
<!--TITLE=Using Linux//-->
<!--AUTHOR=William Ball//-->
<!--PUBLISHER=Macmillan Computer Publishing//-->
<!--IMPRINT=Que//-->
<!--CHAPTER=32//-->
<!--PAGES=581-583//-->
<!--UNASSIGNED1//-->
<!--UNASSIGNED2//-->
<CENTER>
<TABLE BORDER>
<TR>
<TD><A HREF="578-580.html">Previous</A></TD>
<TD><A HREF="../ewtoc.html">Table of Contents</A></TD>
<TD><A HREF="583-586.html">Next</A></TD>
</TR>
</TABLE>
</CENTER>
<P><BR></P>
<H3><A NAME="Heading12"></A><FONT COLOR="#000077">Managing Processes</FONT></H3>
<P>As introduced in Chapter 28, “Managing Daemons,” the Linux process model places significant importance on the ideas of process ownership and parent processes. Managing all the programs that run on a Linux system is a task that requires constant attention from the system administrator. The “mother of all processes” is called <TT>init</TT>, which is part of the kernel, and this process <I>spawns</I> all other processes, usually via the <TT>inittab</TT> file entries and the <TT>init</TT> scripts that define the system run levels.</P>
<P>Because Linux is a multiuser operating system, its processes also have other information attached to them. The user ID and the group ID, as well as a priority setting, are part of the process. You see, the process has all the rights of the user that started the process on the system. This is an important concept: the process is what prevents a user’s programs from overwriting another user’s home directory or reading his email. The process also makes it dangerous to run programs, especially unattended <I>daemon</I> programs, on the system as root because the program can read from and write to any file and all networks.</P>
<P>Rights, as specified by user and group IDs, are <I>inherited</I> by all processes spawned by any other process. For example, when a user logs on, the shell that is started to process the user commands, usually <TT>bash</TT>, has the same user ID as the user who has logged on, and so any process that the shell starts (such as <TT>ls</TT>, <TT>pine</TT>, and so on) has the same settings as well. When a process’s parent process finishes before the child process does, the child process is <I>orphaned</I>. In this case, <TT>init</TT> takes over as the parent process. If the user is no longer on the system and the process has not been flagged to continue running after the user logs off, using the command <TT>nohup</TT> (meaning “no hang-up,” or “don’t send the hang-up signal to the process when the user leaves”), <TT>init</TT> terminates the process.</P>
<P>Because every process must have a parent, and many programs use multiple processes to accomplish their tasks, child programs must have a way of passing some information back to their parents. Fundamental to this is the <I>return code</I>, a number that a program returns to the system after its completion. The problem is that the parent must be ready to accept the return code of the child process. In cases when this does not happen, the child process, although having completed processing, continues to exist in the system because its parent has not accepted the return value of the child process. Such a process is termed to be in a <I>zombified</I> state. Zombie processes don’t use many system resources, but an excess of them can cause problems and require intervention from the system administrator. The simplest way to clear up zombie processes is to kill their parent processes (that’s quite the social policy, if you ask me…). The children then become the property of <TT>init</TT>, which happily accepts the return code.</P>
<H4 ALIGN="LEFT"><A NAME="Heading13"></A><FONT COLOR="#000077">Using the <I>/proc</I> Directory Information
</FONT></H4>
<P>The <TT>/proc</TT> directory tree is a special directory structure that is a window on the running Linux kernel. This structure contains files and directories with all sorts of information that the kernel collects, and is useful for troubleshooting the system or learning about how it works. Utilities such as <TT>ps</TT>, <TT>top</TT>, and <TT>uptime</TT> gather information from this directory tree.</P>
<P>Some files in <TT>/proc</TT> are security sensitive—in particular, the file <TT>/proc/kcore</TT> is essentially a file pointing to all of the system’s memory, and as such can contain passwords or other information that others should not see. As a result, this file and any other files that contain sensitive information have the appropriate permissions set on them to prevent this sort of abuse. Table 32.1 covers a few files of interest in the <TT>/proc</TT> directory.</P>
<TABLE WIDTH="100%"><CAPTION ALIGN=LEFT><B>TABLE 32.1</B> A few files of interest in the <I>/proc</I> directory
<TR>
<TH COLSPAN="2"><HR>
<TR>
<TH WIDTH="40%" ALIGN="LEFT">File
<TH WIDTH="60%" ALIGN="LEFT">Description
<TR>
<TD VALIGN="TOP"><TT>cpuinfo</TT>
<TD>Contains information about the processor(s) in the system, including the capabilities and bugs that Linux has detected. For example, many Intel processors contain the F0 0F bug that can cause the system to completely freeze when certain machine instructions are executed. Later kernels (2.0.33 and later, for example) can detect this and take appropriate measures to minimize the impact of these problems with the system processor. Other processor problems include the Pentium floating point math bug, but the kernel also accounts for differences in how floating point coprocessors and halt instructions are handled.
<TR>
<TD VALIGN="TOP"><TT>version</TT>
<TD>Contains the kernel version number, the system name, and the time and date that the kernel was compiled.
<TR>
<TD VALIGN="TOP"><TT>pci</TT>
<TD>Contains information about the devices on the system’s PCI bus, as well as the detected capabilities of the hardware that’s on the bus.
<TR>
<TD VALIGN="TOP"><TT>interrupts</TT>
<TD>Contains a count of all interrupts the system has processed, and the device that they are attached to.
<TR>
<TD COLSPAN="2"><HR>
</TABLE>
<P>The majority of these files are used by Linux developers to debug their systems, and this material, while interesting, is not vital to any administration task. The <TT>pci</TT> and <TT>interrupts</TT> files can provide insight into system problems, however.</P>
<H4 ALIGN="LEFT"><A NAME="Heading14"></A><FONT COLOR="#000077">Viewing the System Load Average</FONT></H4>
<P>The load on a system in the UNIX world is measured by using a number called the <I>load average</I>. This number is based on the number of processes waiting to run at a given time.</P>
<P>The best command for viewing the system load average is <TT>uptime</TT>. The output of this command also reveals how long the system has been up, along with the load average over the last 1, 5, and 15 minutes, and number of users logged on. If you’d rather gather all this information yourself, it’s in <TT>/proc/loadavg</TT>—the first three numbers are the load average.</P><P><BR></P>
<CENTER>
<TABLE BORDER>
<TR>
<TD><A HREF="578-580.html">Previous</A></TD>
<TD><A HREF="../ewtoc.html">Table of Contents</A></TD>
<TD><A HREF="583-586.html">Next</A></TD>
</TR>
</TABLE>
</CENTER>
</td>
</tr>
</table>
<!-- begin footer information -->
</body></html>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -