White space fix only. Translators can ignore.
This commit is contained in:
Dru Lavigne
parent
0abcd2e1b8
commit
f9fcd39326
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=43022
1 changed files with 183 additions and 176 deletions
|
|
@ -542,7 +542,7 @@ console none unknown off secure</programlisting>
|
|||
</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 I+ 2:09AM 0:00.01 passwd</screen>
|
|||
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>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>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>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>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>&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>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>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>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><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>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>
|
||||
<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>
|
||||
<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>
|
||||
<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>
|
||||
<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>
|
||||
<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>
|
||||
<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>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>
|
||||
<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>
|
||||
<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">
|
||||
|
|
|
|||
Loading…
Reference in a new issue