From owner-svn-doc-head@FreeBSD.ORG Tue Oct 22 19:39:04 2013 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 43E20570; Tue, 22 Oct 2013 19:39:04 +0000 (UTC) (envelope-from dru@FreeBSD.org) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2F9292257; Tue, 22 Oct 2013 19:39:04 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.7/8.14.7) with ESMTP id r9MJd4Yn011613; Tue, 22 Oct 2013 19:39:04 GMT (envelope-from dru@svn.freebsd.org) Received: (from dru@localhost) by svn.freebsd.org (8.14.7/8.14.5/Submit) id r9MJd4jC011612; Tue, 22 Oct 2013 19:39:04 GMT (envelope-from dru@svn.freebsd.org) Message-Id: <201310221939.r9MJd4jC011612@svn.freebsd.org> From: Dru Lavigne Date: Tue, 22 Oct 2013 19:39:04 +0000 (UTC) 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 X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 19:39:04 -0000 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 - + The Superuser Account @@ -1305,7 +1305,7 @@ teamtwo:*:1100:jru,db &prompt.user; id jru uid=1001(jru) gid=1001(jru) groups=1001(jru), 1100(teamtwo) - + In this example, jru is a member of the groups jru 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 PID of 1. - 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 daemons. - 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. + 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 daemons. 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. There is a convention to name programs that normally run as daemons with a trailing d. For example, BIND is the Berkeley Internet Name - Domain, but the actual program that executes is named. - The Apache web server program is + Domain, but the actual program that executes is + named. The + Apache web server program is httpd and the line printer spooling daemon - is lpd. This is only a naming convention. For example, - the main mail daemon for the Sendmail - application is sendmail, and not - maild. + is lpd. This is only a naming convention. + For example, the main mail daemon for the + Sendmail application is + sendmail, and not + maild. + Viewing Processes - 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 PIDs, 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;. + 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 PIDs, 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;. - By default, &man.ps.1; only shows the commands that are - running and owned by the user. For example: + By default, &man.ps.1; only shows the commands that are + running and owned by the user. For example: - &prompt.user; ps + &prompt.user; ps PID TT STAT TIME COMMAND 8203 0 Ss 0:00.59 /bin/csh 8895 0 R+ 0:00.00 ps - The output from &man.ps.1; is organized into a number of - columns. The PID column displays the process - ID. PIDs are assigned starting at 1, go up - to 99999, then wrap around back to the beginning. However, a - PID is not reassigned if it is already in - use. The TT column shows the tty the program - is running on and STAT shows the program's - state. TIME 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, - COMMAND is the command that was used to start - the program. - - A number of different options are available to change - the information that is displayed. One of the most useful sets - is auxww, where displays - information about all the running processes of all users, - displays the username and memory usage of the process' owner, - displays - information about daemon processes, and - 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. + The output from &man.ps.1; is organized into a number of + columns. The PID column displays the + process ID. PIDs are assigned starting at + 1, go up to 99999, then wrap around back to the beginning. + However, a PID is not reassigned if it is + already in use. The TT column shows the + tty the program is running on and STAT + shows the program's state. TIME 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, + COMMAND is the command that was used to + start the program. + + A number of different options are available to change the + information that is displayed. One of the most useful sets is + auxww, where displays + information about all the running processes of all users, + displays the username and memory usage of + the process' owner, displays + information about daemon processes, and + 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. - The output from &man.top.1; is similar: + The output from &man.top.1; is similar: - &prompt.user; top + &prompt.user; top 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 - The output is split into two sections. The header (the - first five or six lines) shows the PID 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 ZFS - file system, the ARC line provides an - indication of how much data was read from the memory cache - instead of from disk. - - Below the header is a series of columns containing similar - information to the output from &man.ps.1;, such as the - PID, 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. - - &man.top.1; automatically updates the display every two - seconds. A different interval can be specified with - . - + The output is split into two sections. The header (the + first five or six lines) shows the PID 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 ZFS + file system, the ARC line provides an + indication of how much data was read from the memory cache + instead of from disk. + + Below the header is a series of columns containing similar + information to the output from &man.ps.1;, such as the + PID, 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. + + &man.top.1; automatically updates the display every two + seconds. A different interval can be specified with + . + - - Killing Processes + + Killing Processes - One way to communicate with any running - process or daemon is to send a signal 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 - root user, who can send signals to anyone's - processes. - - 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 - Segmentation Violation signal - (SIGSEGV). 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 Alarm signal - (SIGALRM). - - Two signals can be used to stop a process: - SIGTERM and SIGKILL. - SIGTERM 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 - SIGTERM if it is in the middle of some task - that can not be interrupted. - - SIGKILL can not be ignored by a process. - Sending a SIGKILL to a - process will usually stop that process there and then. + One way to communicate with any running process or daemon + is to send a signal 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 + root user, who can send signals to + anyone's processes. + + 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 + Segmentation Violation signal + (SIGSEGV). 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 + Alarm signal + (SIGALRM). + + Two signals can be used to stop a process: + SIGTERM and SIGKILL. + SIGTERM 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 + SIGTERM if it is in the middle of some task + that can not be interrupted. + + SIGKILL can not be ignored by a + process. Sending a SIGKILL to a + process will usually stop that process there and then. + 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. . - Other commonly used signals are SIGHUP, - SIGUSR1, and SIGUSR2. - Since these are general purpose signals, different applications - will respond differently. - - For example, after changing a web server's configuration - file, the web server needs to be told to re-read its - configuration. Restarting httpd would result - in a brief outage period on the web server. Instead, send the - daemon the SIGHUP signal. Be aware that - different daemons will have different behavior, so refer to the - documentation for the daemon to determine if - SIGHUP will achieve the desired - results. - - - Sending a Signal to a Process - - This example shows how to send a signal to &man.inetd.8;. - The &man.inetd.8; configuration file is - /etc/inetd.conf, and &man.inetd.8; will - re-read this configuration file when it is sent a - SIGHUP. - - - Find the PID of the process to send - the signal to using &man.pgrep.1;. In this example, the - PID for &man.inetd.8; is 198: + Other commonly used signals are SIGHUP, + SIGUSR1, and SIGUSR2. + Since these are general purpose signals, different + applications will respond differently. + + For example, after changing a web server's configuration + file, the web server needs to be told to re-read its + configuration. Restarting httpd would + result in a brief outage period on the web server. Instead, + send the daemon the SIGHUP signal. Be + aware that different daemons will have different behavior, so + refer to the documentation for the daemon to determine if + SIGHUP will achieve the desired + results. + + + Sending a Signal to a Process + + This example shows how to send a signal to + &man.inetd.8;. The &man.inetd.8; configuration file is + /etc/inetd.conf, and &man.inetd.8; will + re-read this configuration file when it is sent a + SIGHUP. + + + Find the PID of the process to send + the signal to using &man.pgrep.1;. In this example, the + PID for &man.inetd.8; is 198: - &prompt.user; pgrep -l inetd + &prompt.user; pgrep -l inetd 198 inetd -wW - + - - Use &man.kill.1; to send the signal. Because - &man.inetd.8; is owned by root, use - &man.su.1; to become root first. + + Use &man.kill.1; to send the signal. Because + &man.inetd.8; is owned by root, use + &man.su.1; to become root + first. - &prompt.user; su + &prompt.user; su Password: &prompt.root; /bin/kill -s HUP 198 - 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 - kill: PID: Operation - not permitted will be displayed. Mistyping - the PID will either send the signal to - the wrong process, which could have negative results, or - will send the signal to a PID that is - not currently in use, resulting in the error - kill: PID: No such - process. - - - Why Use <command>/bin/kill</command>? - - Many shells provide kill as a built - in command, meaning that the shell will send the signal - directly, rather than running - /bin/kill. 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 /bin/kill. - - - - - When sending other signals, substitute - TERM or KILL with the name - of the signal. - - - Killing a random process on the system is a bad idea. - In particular, &man.init.8;, PID 1, is - special. Running /bin/kill -s KILL 1 is - a quick, and unrecommended, way to shutdown the system. - Always double check the arguments to - &man.kill.1; before pressing - Return. - - + 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 + kill: PID: Operation + not permitted will be displayed. Mistyping + the PID will either send the signal to + the wrong process, which could have negative results, or + will send the signal to a PID that is + not currently in use, resulting in the error + kill: PID: No such + process. + + + Why Use <command>/bin/kill</command>? + + Many shells provide kill as a + built in command, meaning that the shell will send the + signal directly, rather than running + /bin/kill. 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 + /bin/kill. + + + + + When sending other signals, substitute + TERM or KILL with the + name of the signal. + + + Killing a random process on the system is a bad idea. + In particular, &man.init.8;, PID 1, is + special. Running /bin/kill -s KILL 1 is + a quick, and unrecommended, way to shutdown the system. + Always double check the arguments to + &man.kill.1; before pressing + Return. + +