svn commit: r43022 - head/en_US.ISO8859-1/books/handbook/basics
Dru Lavigne
dru at FreeBSD.org
Tue Oct 22 19:39:04 UTC 2013
Author: dru
Date: Tue Oct 22 19:39:03 2013
New Revision: 43022
URL: http://svnweb.freebsd.org/changeset/doc/43022
Log:
White space fix only. Translators can ignore.
Modified:
head/en_US.ISO8859-1/books/handbook/basics/chapter.xml
Modified: head/en_US.ISO8859-1/books/handbook/basics/chapter.xml
==============================================================================
--- head/en_US.ISO8859-1/books/handbook/basics/chapter.xml Tue Oct 22 18:58:12 2013 (r43021)
+++ head/en_US.ISO8859-1/books/handbook/basics/chapter.xml Tue Oct 22 19:39:03 2013 (r43022)
@@ -542,7 +542,7 @@ console none
</listitem>
</varlistentry>
</variablelist>
- </sect3>
+ </sect3>
<sect3 id="users-superuser">
<title>The Superuser Account</title>
@@ -1305,7 +1305,7 @@ teamtwo:*:1100:jru,db</screen>
<screen>&prompt.user; <userinput>id jru</userinput>
uid=1001(jru) gid=1001(jru) groups=1001(jru), 1100(teamtwo)</screen>
- </example>
+ </example>
<para>In this example, <username>jru</username> is a member of
the groups <groupname>jru</groupname> and
@@ -2879,75 +2879,78 @@ root 5211 0.0 0.2 3620 1724 2
always the first process to start at boot time and which always
has a <acronym>PID</acronym> of <literal>1</literal>.</para>
- <para>Some programs are not designed
- to be run with continuous user input and disconnect from the
- terminal at the first opportunity. For example, a web server
- responds to web requests, rather than user input. Mail servers
- are another example of this type of application. These types of
- programs are known as <firstterm>daemons</firstterm>.
- The term daemon comes from Greek mythology and represents an
- entity that is neither good nor evil, and which invisibly
- performs useful tasks. This is why the BSD mascot is the
- cheerful-looking daemon with sneakers and a pitchfork.</para>
+ <para>Some programs are not designed to be run with continuous
+ user input and disconnect from the terminal at the first
+ opportunity. For example, a web server responds to web
+ requests, rather than user input. Mail servers are another
+ example of this type of application. These types of programs
+ are known as <firstterm>daemons</firstterm>. The term daemon
+ comes from Greek mythology and represents an entity that is
+ neither good nor evil, and which invisibly performs useful
+ tasks. This is why the BSD mascot is the cheerful-looking
+ daemon with sneakers and a pitchfork.</para>
<para>There is a convention to name programs that normally run as
daemons with a trailing <quote>d</quote>. For example,
<application>BIND</application> is the Berkeley Internet Name
- Domain, but the actual program that executes is <command>named</command>.
- The <application>Apache</application> web server program is
+ Domain, but the actual program that executes is
+ <command>named</command>. The
+ <application>Apache</application> web server program is
<command>httpd</command> and the line printer spooling daemon
- is <command>lpd</command>. This is only a naming convention. For example,
- the main mail daemon for the <application>Sendmail</application>
- application is <command>sendmail</command>, and not
- <literal>maild</literal>.</para>
+ is <command>lpd</command>. This is only a naming convention.
+ For example, the main mail daemon for the
+ <application>Sendmail</application> application is
+ <command>sendmail</command>, and not
+ <literal>maild</literal>.</para>
+
<sect2>
<title>Viewing Processes</title>
- <para>To see the processes running on the system, use &man.ps.1; or
- &man.top.1;. To display a static list of the currently running
- processes, their <acronym>PID</acronym>s, how much memory they
- are using, and the command they were started with, use
- &man.ps.1;. To display all the running processes and update
- the display every few seconds in order to interactively see
- what the computer is doing, use &man.top.1;.</para>
+ <para>To see the processes running on the system, use &man.ps.1;
+ or &man.top.1;. To display a static list of the currently
+ running processes, their <acronym>PID</acronym>s, how much
+ memory they are using, and the command they were started with,
+ use &man.ps.1;. To display all the running processes and
+ update the display every few seconds in order to interactively
+ see what the computer is doing, use &man.top.1;.</para>
- <para>By default, &man.ps.1; only shows the commands that are
- running and owned by the user. For example:</para>
+ <para>By default, &man.ps.1; only shows the commands that are
+ running and owned by the user. For example:</para>
- <screen>&prompt.user; <userinput>ps</userinput>
+ <screen>&prompt.user; <userinput>ps</userinput>
PID TT STAT TIME COMMAND
8203 0 Ss 0:00.59 /bin/csh
8895 0 R+ 0:00.00 ps</screen>
- <para>The output from &man.ps.1; is organized into a number of
- columns. The <literal>PID</literal> column displays the process
- ID. <acronym>PID</acronym>s are assigned starting at 1, go up
- to 99999, then wrap around back to the beginning. However, a
- <acronym>PID</acronym> is not reassigned if it is already in
- use. The <literal>TT</literal> column shows the tty the program
- is running on and <literal>STAT</literal> shows the program's
- state. <literal>TIME</literal> is the amount of time the
- program has been running on the CPU. This is usually not the
- elapsed time since the program was started, as most programs
- spend a lot of time waiting for things to happen before they
- need to spend time on the CPU. Finally,
- <literal>COMMAND</literal> is the command that was used to start
- the program.</para>
-
- <para>A number of different options are available to change
- the information that is displayed. One of the most useful sets
- is <literal>auxww</literal>, where <option>a</option> displays
- information about all the running processes of all users,
- <option>u</option> displays the username and memory usage of the process' owner,
- <option>x</option> displays
- information about daemon processes, and <option>ww</option>
- causes &man.ps.1; to display the full command line for each
- process, rather than truncating it once it gets too long to fit
- on the screen.</para>
+ <para>The output from &man.ps.1; is organized into a number of
+ columns. The <literal>PID</literal> column displays the
+ process ID. <acronym>PID</acronym>s are assigned starting at
+ 1, go up to 99999, then wrap around back to the beginning.
+ However, a <acronym>PID</acronym> is not reassigned if it is
+ already in use. The <literal>TT</literal> column shows the
+ tty the program is running on and <literal>STAT</literal>
+ shows the program's state. <literal>TIME</literal> is the
+ amount of time the program has been running on the CPU. This
+ is usually not the elapsed time since the program was started,
+ as most programs spend a lot of time waiting for things to
+ happen before they need to spend time on the CPU. Finally,
+ <literal>COMMAND</literal> is the command that was used to
+ start the program.</para>
+
+ <para>A number of different options are available to change the
+ information that is displayed. One of the most useful sets is
+ <literal>auxww</literal>, where <option>a</option> displays
+ information about all the running processes of all users,
+ <option>u</option> displays the username and memory usage of
+ the process' owner, <option>x</option> displays
+ information about daemon processes, and <option>ww</option>
+ causes &man.ps.1; to display the full command line for each
+ process, rather than truncating it once it gets too long to
+ fit on the screen.</para>
- <para>The output from &man.top.1; is similar:</para>
+ <para>The output from &man.top.1; is similar:</para>
- <screen>&prompt.user; <userinput>top</userinput>
+ <screen>&prompt.user; <userinput>top</userinput>
last pid: 72257; load averages: 0.13, 0.09, 0.03 up 0+13:38:33 22:39:10
47 processes: 1 running, 46 sleeping
CPU states: 12.6% user, 0.0% nice, 7.8% system, 0.0% interrupt, 79.7% idle
@@ -2974,68 +2977,70 @@ Swap: 2048M Total, 2048M Free
2338 dru 1 20 0 440M 84532K select 1 0:06 0.00% kwin
1427 dru 5 22 0 605M 86412K select 1 0:05 0.00% kdeinit4</screen>
- <para>The output is split into two sections. The header (the
- first five or six lines) shows the <acronym>PID</acronym> of the last
- process to run, the system load averages (which are a measure
- of how busy the system is), the system uptime (time since the
- last reboot) and the current time. The other figures in the
- header relate to how many processes are running,
- how much memory and swap space has been used, and how
- much time the system is spending in different CPU states. If
- the system has been formatted with the <acronym>ZFS</acronym>
- file system, the <literal>ARC</literal> line provides an
- indication of how much data was read from the memory cache
- instead of from disk.</para>
-
- <para>Below the header is a series of columns containing similar
- information to the output from &man.ps.1;, such as the
- <acronym>PID</acronym>, username, amount of CPU time, and the
- command that started the process. By default, &man.top.1; also
- displays the amount of memory space taken by the process.
- This is split into two columns: one for total size and one for
- resident size. Total size is how much memory the application
- has needed and the resident size is how much it is actually
- using now.</para>
-
- <para>&man.top.1; automatically updates the display every two
- seconds. A different interval can be specified with
- <option>-s</option>.</para>
- </sect2>
+ <para>The output is split into two sections. The header (the
+ first five or six lines) shows the <acronym>PID</acronym> of
+ the last process to run, the system load averages (which are a
+ measure of how busy the system is), the system uptime (time
+ since the last reboot) and the current time. The other
+ figures in the header relate to how many processes are
+ running, how much memory and swap space has been used, and how
+ much time the system is spending in different CPU states. If
+ the system has been formatted with the <acronym>ZFS</acronym>
+ file system, the <literal>ARC</literal> line provides an
+ indication of how much data was read from the memory cache
+ instead of from disk.</para>
+
+ <para>Below the header is a series of columns containing similar
+ information to the output from &man.ps.1;, such as the
+ <acronym>PID</acronym>, username, amount of CPU time, and the
+ command that started the process. By default, &man.top.1;
+ also displays the amount of memory space taken by the process.
+ This is split into two columns: one for total size and one for
+ resident size. Total size is how much memory the application
+ has needed and the resident size is how much it is actually
+ using now.</para>
+
+ <para>&man.top.1; automatically updates the display every two
+ seconds. A different interval can be specified with
+ <option>-s</option>.</para>
+ </sect2>
- <sect2 id="basics-daemons">
- <title>Killing Processes</title>
+ <sect2 id="basics-daemons">
+ <title>Killing Processes</title>
- <para>One way to communicate with any running
- process or daemon is to send a <firstterm>signal</firstterm> using
- &man.kill.1;. There are a number of different signals; some
- have a specific meaning while others are described in the
- application's documentation. A user can only send a signal to a
- process they own and sending a signal to someone else's process
- will result in a permission denied error. The exception is the
- <username>root</username> user, who can send signals to anyone's
- processes.</para>
-
- <para>The operating system can also send a signal to a process. If an application
- is badly written and tries to access memory that it is not
- supposed to, &os; will send the process the
- <quote>Segmentation Violation</quote> signal
- (<literal>SIGSEGV</literal>). If an application has been written to use the
- &man.alarm.3; system call to be alerted after a period of time
- has elapsed, it will be sent the <quote>Alarm</quote> signal
- (<literal>SIGALRM</literal>).</para>
-
- <para>Two signals can be used to stop a process:
- <literal>SIGTERM</literal> and <literal>SIGKILL</literal>.
- <literal>SIGTERM</literal> is the polite way to kill a process
- as the process can read the signal, close any log files it may
- have open, and attempt to finish what it is doing before
- shutting down. In some cases, a process may ignore
- <literal>SIGTERM</literal> if it is in the middle of some task
- that can not be interrupted.</para>
-
- <para><literal>SIGKILL</literal> can not be ignored by a process.
- Sending a <literal>SIGKILL</literal> to a
- process will usually stop that process there and then.<footnote>
+ <para>One way to communicate with any running process or daemon
+ is to send a <firstterm>signal</firstterm> using &man.kill.1;.
+ There are a number of different signals; some have a specific
+ meaning while others are described in the application's
+ documentation. A user can only send a signal to a process
+ they own and sending a signal to someone else's process will
+ result in a permission denied error. The exception is the
+ <username>root</username> user, who can send signals to
+ anyone's processes.</para>
+
+ <para>The operating system can also send a signal to a process.
+ If an application is badly written and tries to access memory
+ that it is not supposed to, &os; will send the process the
+ <quote>Segmentation Violation</quote> signal
+ (<literal>SIGSEGV</literal>). If an application has been
+ written to use the &man.alarm.3; system call to be alerted
+ after a period of time has elapsed, it will be sent the
+ <quote>Alarm</quote> signal
+ (<literal>SIGALRM</literal>).</para>
+
+ <para>Two signals can be used to stop a process:
+ <literal>SIGTERM</literal> and <literal>SIGKILL</literal>.
+ <literal>SIGTERM</literal> is the polite way to kill a process
+ as the process can read the signal, close any log files it may
+ have open, and attempt to finish what it is doing before
+ shutting down. In some cases, a process may ignore
+ <literal>SIGTERM</literal> if it is in the middle of some task
+ that can not be interrupted.</para>
+
+ <para><literal>SIGKILL</literal> can not be ignored by a
+ process. Sending a <literal>SIGKILL</literal> to a
+ process will usually stop that process there and then.
+ <footnote>
<para>There are a few tasks that can not be interrupted. For
example, if the process is trying to read from a file that
is on another computer on the network, and the other
@@ -3045,89 +3050,91 @@ Swap: 2048M Total, 2048M Free
out occurs the process will be killed.</para>
</footnote>.</para>
- <para>Other commonly used signals are <literal>SIGHUP</literal>,
- <literal>SIGUSR1</literal>, and <literal>SIGUSR2</literal>.
- Since these are general purpose signals, different applications
- will respond differently.</para>
-
- <para>For example, after changing a web server's configuration
- file, the web server needs to be told to re-read its
- configuration. Restarting <command>httpd</command> would result
- in a brief outage period on the web server. Instead, send the
- daemon the <literal>SIGHUP</literal> signal. Be aware that
- different daemons will have different behavior, so refer to the
- documentation for the daemon to determine if
- <literal>SIGHUP</literal> will achieve the desired
- results.</para>
-
- <procedure>
- <title>Sending a Signal to a Process</title>
-
- <para>This example shows how to send a signal to &man.inetd.8;.
- The &man.inetd.8; configuration file is
- <filename>/etc/inetd.conf</filename>, and &man.inetd.8; will
- re-read this configuration file when it is sent a
- <literal>SIGHUP</literal>.</para>
-
- <step>
- <para>Find the <acronym>PID</acronym> of the process to send
- the signal to using &man.pgrep.1;. In this example, the
- <acronym>PID</acronym> for &man.inetd.8; is 198:</para>
+ <para>Other commonly used signals are <literal>SIGHUP</literal>,
+ <literal>SIGUSR1</literal>, and <literal>SIGUSR2</literal>.
+ Since these are general purpose signals, different
+ applications will respond differently.</para>
+
+ <para>For example, after changing a web server's configuration
+ file, the web server needs to be told to re-read its
+ configuration. Restarting <command>httpd</command> would
+ result in a brief outage period on the web server. Instead,
+ send the daemon the <literal>SIGHUP</literal> signal. Be
+ aware that different daemons will have different behavior, so
+ refer to the documentation for the daemon to determine if
+ <literal>SIGHUP</literal> will achieve the desired
+ results.</para>
+
+ <procedure>
+ <title>Sending a Signal to a Process</title>
+
+ <para>This example shows how to send a signal to
+ &man.inetd.8;. The &man.inetd.8; configuration file is
+ <filename>/etc/inetd.conf</filename>, and &man.inetd.8; will
+ re-read this configuration file when it is sent a
+ <literal>SIGHUP</literal>.</para>
+
+ <step>
+ <para>Find the <acronym>PID</acronym> of the process to send
+ the signal to using &man.pgrep.1;. In this example, the
+ <acronym>PID</acronym> for &man.inetd.8; is 198:</para>
- <screen>&prompt.user; <userinput>pgrep -l inetd</userinput>
+ <screen>&prompt.user; <userinput>pgrep -l inetd</userinput>
198 inetd -wW</screen>
- </step>
+ </step>
- <step>
- <para>Use &man.kill.1; to send the signal. Because
- &man.inetd.8; is owned by <username>root</username>, use
- &man.su.1; to become <username>root</username> first.</para>
+ <step>
+ <para>Use &man.kill.1; to send the signal. Because
+ &man.inetd.8; is owned by <username>root</username>, use
+ &man.su.1; to become <username>root</username>
+ first.</para>
- <screen>&prompt.user; <userinput>su</userinput>
+ <screen>&prompt.user; <userinput>su</userinput>
<prompt>Password:</prompt>
&prompt.root; <userinput>/bin/kill -s HUP 198</userinput></screen>
- <para>Like most &unix; commands, &man.kill.1; will not print
- any output if it is successful. If a signal is sent to a
- process not owned by that user, the message
- <errorname>kill: <replaceable>PID</replaceable>: Operation
- not permitted</errorname> will be displayed. Mistyping
- the <acronym>PID</acronym> will either send the signal to
- the wrong process, which could have negative results, or
- will send the signal to a <acronym>PID</acronym> that is
- not currently in use, resulting in the error
- <errorname>kill: <replaceable>PID</replaceable>: No such
- process</errorname>.</para>
-
- <note>
- <title>Why Use <command>/bin/kill</command>?</title>
-
- <para>Many shells provide <command>kill</command> as a built
- in command, meaning that the shell will send the signal
- directly, rather than running
- <filename>/bin/kill</filename>. Be aware that different
- shells have a different syntax for specifying the name of
- the signal to send. Rather than try to learn all of them,
- it can be simpler to specify <command>/bin/kill</command>.</para>
- </note>
- </step>
- </procedure>
-
- <para>When sending other signals, substitute
- <literal>TERM</literal> or <literal>KILL</literal> with the name
- of the signal.</para>
-
- <important>
- <para>Killing a random process on the system is a bad idea.
- In particular, &man.init.8;, <acronym>PID</acronym> 1, is
- special. Running <command>/bin/kill -s KILL 1</command> is
- a quick, and unrecommended, way to shutdown the system.
- <emphasis>Always</emphasis> double check the arguments to
- &man.kill.1; <emphasis>before</emphasis> pressing
- <keycap>Return</keycap>.</para>
- </important>
- </sect2>
+ <para>Like most &unix; commands, &man.kill.1; will not print
+ any output if it is successful. If a signal is sent to a
+ process not owned by that user, the message
+ <errorname>kill: <replaceable>PID</replaceable>: Operation
+ not permitted</errorname> will be displayed. Mistyping
+ the <acronym>PID</acronym> will either send the signal to
+ the wrong process, which could have negative results, or
+ will send the signal to a <acronym>PID</acronym> that is
+ not currently in use, resulting in the error
+ <errorname>kill: <replaceable>PID</replaceable>: No such
+ process</errorname>.</para>
+
+ <note>
+ <title>Why Use <command>/bin/kill</command>?</title>
+
+ <para>Many shells provide <command>kill</command> as a
+ built in command, meaning that the shell will send the
+ signal directly, rather than running
+ <filename>/bin/kill</filename>. Be aware that different
+ shells have a different syntax for specifying the name
+ of the signal to send. Rather than try to learn all of
+ them, it can be simpler to specify
+ <command>/bin/kill</command>.</para>
+ </note>
+ </step>
+ </procedure>
+
+ <para>When sending other signals, substitute
+ <literal>TERM</literal> or <literal>KILL</literal> with the
+ name of the signal.</para>
+
+ <important>
+ <para>Killing a random process on the system is a bad idea.
+ In particular, &man.init.8;, <acronym>PID</acronym> 1, is
+ special. Running <command>/bin/kill -s KILL 1</command> is
+ a quick, and unrecommended, way to shutdown the system.
+ <emphasis>Always</emphasis> double check the arguments to
+ &man.kill.1; <emphasis>before</emphasis> pressing
+ <keycap>Return</keycap>.</para>
+ </important>
+ </sect2>
</sect1>
<sect1 id="shells">
More information about the svn-doc-all
mailing list