Date: Tue, 22 Oct 2013 19:39:04 +0000 (UTC) From: Dru Lavigne <dru@FreeBSD.org> To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43022 - head/en_US.ISO8859-1/books/handbook/basics Message-ID: <201310221939.r9MJd4jC011612@svn.freebsd.org>
next in thread | raw e-mail | index | archive | help
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">
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201310221939.r9MJd4jC011612>