📄 basics-daemons.html

📁 这是很好的学习嵌入式LINUX的文章
💻 HTML
字号:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta name="generator" content="HTML Tidy, see www.w3.org" /><title>Daemons, Signals, and Killing Processes</title><meta name="GENERATOR" content="Modular DocBook HTML Stylesheet Version 1.7" /><link rel="HOME" title="FreeBSD Handbook" href="index.html" /><link rel="UP" title="UNIX Basics" href="basics.html" /><link rel="PREVIOUS" title="Processes" href="basics-processes.html" /><link rel="NEXT" title="Shells" href="shells.html" /><link rel="STYLESHEET" type="text/css" href="docbook.css" /></head><body class="SECT1" bgcolor="#FFFFFF" text="#000000" link="#0000FF" vlink="#840084"alink="#0000FF"><div class="NAVHEADER"><table summary="Header navigation table" width="100%" border="0" cellpadding="0"cellspacing="0"><tr><th colspan="3" align="center">FreeBSD Handbook</th></tr><tr><td width="10%" align="left" valign="bottom"><a href="basics-processes.html"accesskey="P">Prev</a></td><td width="80%" align="center" valign="bottom">Chapter 3 UNIX Basics</td><td width="10%" align="right" valign="bottom"><a href="shells.html"accesskey="N">Next</a></td></tr></table><hr align="LEFT" width="100%" /></div><div class="SECT1"><h1 class="SECT1"><a id="BASICS-DAEMONS" name="BASICS-DAEMONS">3.8 Daemons, Signals, andKilling Processes</a></h1><p>When you run an editor it is easy to control the editor, tell it to load files, and soon. You can do this because the editor provides facilities to do so, and because theeditor is attached to a <i class="FIRSTTERM">terminal</i>. Some programs are not designedto be run with continuous user input, and so they disconnect from the terminal at thefirst opportunity. For example, a web server spends all day responding to web requests,it normally does not need any input from you. Programs that transport email from site tosite are another example of this class of application.</p><p>We call these programs <i class="FIRSTTERM">daemons</i>. Daemons were characters inGreek mythology; neither good or evil, they were little attendant spirits that, by andlarge, did useful things for mankind. Much like the web servers and mail servers of todaydo useful things. This is why the BSD mascot has, for a long time, been the cheerfullooking daemon with sneakers and a pitchfork.</p><p>There is a convention to name programs that normally run as daemons with a trailing``d''. <b class="APPLICATION">BIND</b> is the Berkeley Internet Name Daemon (and theactual program that executes is called <tt class="COMMAND">named</tt>), the <bclass="APPLICATION">Apache</b> web server program is called <ttclass="COMMAND">httpd</tt>, the line printer spooling daemon is <ttclass="COMMAND">lpd</tt> and so on. This is a convention, not a hard and fast rule; forexample, the main mail daemon for the <b class="APPLICATION">Sendmail</b> application iscalled <tt class="COMMAND">sendmail</tt>, and not <tt class="COMMAND">maild</tt>, as youmight imagine.</p><p>Sometimes you will need to communicate with a daemon process. These communications arecalled <i class="FIRSTTERM">signals</i>, and you can communicate with a daemon (or withany other running process) by sending it a signal. There are a number of differentsignals that you can send--some of them have a specific meaning, others are interpretedby the application, and the application's documentation will tell you how thatapplication interprets signals. You can only send a signal to a process that you own. Ifyou send a signal to someone else's process with <ahref="http://www.FreeBSD.org/cgi/man.cgi?query=kill&sektion=1"><spanclass="CITEREFENTRY"><span class="REFENTRYTITLE">kill</span>(1)</span></a> or <ahref="http://www.FreeBSD.org/cgi/man.cgi?query=kill&sektion=2"><spanclass="CITEREFENTRY"><span class="REFENTRYTITLE">kill</span>(2)</span></a> permissionwill be denied. The exception to this is the <tt class="USERNAME">root</tt> user, who cansend signals to everyone's processes.</p><p>FreeBSD will also send applications signals in some cases. If an application is badlywritten, and tries to access memory that it is not supposed to, FreeBSD sends the processthe <i class="FIRSTTERM">Segmentation Violation</i> signal (<varclass="LITERAL">SIGSEGV</var>). If an application has used the <ahref="http://www.FreeBSD.org/cgi/man.cgi?query=alarm&sektion=3"><spanclass="CITEREFENTRY"><span class="REFENTRYTITLE">alarm</span>(3)</span></a> system callto be alerted after a period of time has elapsed then it will be sent the Alarm signal(<var class="LITERAL">SIGALRM</var>), and so on.</p><p>Two signals can be used to stop a process, <var class="LITERAL">SIGTERM</var> and <varclass="LITERAL">SIGKILL</var>. <var class="LITERAL">SIGTERM</var> is the polite way tokill a process; the process can <span class="emphasis"><iclass="EMPHASIS">catch</i></span> the signal, realize that you want it to shut down,close any log files it may have open, and generally finish whatever it is doing at thetime before shutting down. In some cases a process may even ignore <varclass="LITERAL">SIGTERM</var> if it is in the middle of some task that can not beinterrupted.</p><p><var class="LITERAL">SIGKILL</var> can not be ignored by a process. This is the ``I donot care what you are doing, stop right now'' signal. If you send <varclass="LITERAL">SIGKILL</var> to a process then FreeBSD will stop that process there andthen<a id="AEN4716" name="AEN4716" href="#FTN.AEN4716"><spanclass="footnote">[1]</span></a>.</p><p>The other signals you might want to use are <var class="LITERAL">SIGHUP</var>, <varclass="LITERAL">SIGUSR1</var>, and <var class="LITERAL">SIGUSR2</var>. These are generalpurpose signals, and different applications will do different things when they aresent.</p><p>Suppose that you have changed your web server's configuration file--you would like totell the web server to re-read its configuration. You could stop and restart <ttclass="COMMAND">httpd</tt>, but this would result in a brief outage period on your webserver, which may be undesirable. Most daemons are written to respond to the <varclass="LITERAL">SIGHUP</var> signal by re-reading their configuration file. So instead ofkilling and restarting <tt class="COMMAND">httpd</tt> you would send it the <varclass="LITERAL">SIGHUP</var> signal. Because there is no standard way to respond to thesesignals, different daemons will have different behavior, so be sure and read thedocumentation for the daemon in question.</p><p>Signals are sent using the <ahref="http://www.FreeBSD.org/cgi/man.cgi?query=kill&sektion=1"><spanclass="CITEREFENTRY"><span class="REFENTRYTITLE">kill</span>(1)</span></a> command, asthis example shows.</p><div class="PROCEDURE"><p><b>Sending a Signal to a Process</b></p><p>This example shows how to send a signal to <ahref="http://www.FreeBSD.org/cgi/man.cgi?query=inetd&sektion=8"><spanclass="CITEREFENTRY"><span class="REFENTRYTITLE">inetd</span>(8)</span></a>. The <ttclass="COMMAND">inetd</tt> configuration file is <ttclass="FILENAME">/etc/inetd.conf</tt>, and <tt class="COMMAND">inetd</tt> will re-readthis configuration file when it is sent <var class="LITERAL">SIGHUP</var>.</p><ol type="1"><li><p>Find the process ID of the process you want to send the signal to. Do this using <ahref="http://www.FreeBSD.org/cgi/man.cgi?query=ps&sektion=1"><spanclass="CITEREFENTRY"><span class="REFENTRYTITLE">ps</span>(1)</span></a> and <ahref="http://www.FreeBSD.org/cgi/man.cgi?query=grep&sektion=1"><spanclass="CITEREFENTRY"><span class="REFENTRYTITLE">grep</span>(1)</span></a>. The <ahref="http://www.FreeBSD.org/cgi/man.cgi?query=grep&sektion=1"><spanclass="CITEREFENTRY"><span class="REFENTRYTITLE">grep</span>(1)</span></a> command isused to search through output, looking for the string you specify. This command is run asa normal user, and <ahref="http://www.FreeBSD.org/cgi/man.cgi?query=inetd&sektion=8"><spanclass="CITEREFENTRY"><span class="REFENTRYTITLE">inetd</span>(8)</span></a> is run as <ttclass="USERNAME">root</tt>, so the <var class="OPTION">ax</var> options must be given to<a href="http://www.FreeBSD.org/cgi/man.cgi?query=ps&sektion=1"><spanclass="CITEREFENTRY"><span class="REFENTRYTITLE">ps</span>(1)</span></a>.</p><pre class="SCREEN"><samp class="PROMPT">%</samp> <kbd class="USERINPUT">ps -ax | grep inetd</kbd>  198  ??  IWs    0:00.00 inetd -wW</pre><p>So the <a href="http://www.FreeBSD.org/cgi/man.cgi?query=inetd&sektion=8"><spanclass="CITEREFENTRY"><span class="REFENTRYTITLE">inetd</span>(8)</span></a> PID is 198.In some cases the <var class="LITERAL">grep inetd</var> command might also occur in thisoutput. This is because of the way <ahref="http://www.FreeBSD.org/cgi/man.cgi?query=ps&sektion=1"><spanclass="CITEREFENTRY"><span class="REFENTRYTITLE">ps</span>(1)</span></a> has to find thelist of running processes.</p></li><li><p>Use <a href="http://www.FreeBSD.org/cgi/man.cgi?query=kill&sektion=1"><spanclass="CITEREFENTRY"><span class="REFENTRYTITLE">kill</span>(1)</span></a> to send thesignal. Because <a href="http://www.FreeBSD.org/cgi/man.cgi?query=inetd&sektion=8"><spanclass="CITEREFENTRY"><span class="REFENTRYTITLE">inetd</span>(8)</span></a> is being runby <tt class="USERNAME">root</tt> you must use <ahref="http://www.FreeBSD.org/cgi/man.cgi?query=su&sektion=1"><spanclass="CITEREFENTRY"><span class="REFENTRYTITLE">su</span>(1)</span></a> to become <ttclass="USERNAME">root</tt> first.</p><pre class="SCREEN"><samp class="PROMPT">%</samp> <kbd class="USERINPUT">su</kbd><samp class="PROMPT">Password:</samp><samp class="PROMPT">#</samp> <kbd class="USERINPUT">/bin/kill -s HUP 198</kbd></pre><p>In common with most <span class="TRADEMARK">UNIX</span>&reg; commands, <ahref="http://www.FreeBSD.org/cgi/man.cgi?query=kill&sektion=1"><spanclass="CITEREFENTRY"><span class="REFENTRYTITLE">kill</span>(1)</span></a> will not printany output if it is successful. If you send a signal to a process that you do not ownthen you will see ``<tt class="ERRORNAME">kill: <var class="REPLACEABLE">PID</var>:Operation not permitted</tt>''. If you mistype the PID you will either send the signal tothe wrong process, which could be bad, or, if you are lucky, you will have sent thesignal to a PID that is not currently in use, and you will see ``<ttclass="ERRORNAME">kill: <var class="REPLACEABLE">PID</var>: No such process</tt>''.</p><div class="NOTE"><blockquote class="NOTE"><p><b>Why Use <tt class="COMMAND">/bin/kill</tt>?:</b> Many shells provide the <ttclass="COMMAND">kill</tt> command as a built in command; that is, the shell will send thesignal directly, rather than running <tt class="FILENAME">/bin/kill</tt>. This can bevery useful, but different shells have a different syntax for specifying the name of thesignal to send. Rather than try to learn all of them, it can be simpler just to use the<tt class="COMMAND">/bin/kill <var class="REPLACEABLE">...</var></tt> commanddirectly.</p></blockquote></div></li></ol></div><p>Sending other signals is very similar, just substitute <var class="LITERAL">TERM</var>or <var class="LITERAL">KILL</var> in the command line as necessary.</p><div class="IMPORTANT"><blockquote class="IMPORTANT"><p><b>Important:</b> Killing random process on the system can be a bad idea. Inparticular, <a href="http://www.FreeBSD.org/cgi/man.cgi?query=init&sektion=8"><spanclass="CITEREFENTRY"><span class="REFENTRYTITLE">init</span>(8)</span></a>, process ID 1,is very special. Running <tt class="COMMAND">/bin/kill -s KILL 1</tt> is a quick way toshutdown your system. <span class="emphasis"><i class="EMPHASIS">Always</i></span> doublecheck the arguments you run <ahref="http://www.FreeBSD.org/cgi/man.cgi?query=kill&sektion=1"><spanclass="CITEREFENTRY"><span class="REFENTRYTITLE">kill</span>(1)</span></a> with <spanclass="emphasis"><i class="EMPHASIS">before</i></span> you press <bclass="KEYCAP">Return</b>.</p></blockquote></div></div><h3 class="FOOTNOTES">Notes</h3><table border="0" class="FOOTNOTES" width="100%"><tr><td align="LEFT" valign="TOP" width="5%"><a id="FTN.AEN4716" name="FTN.AEN4716"href="basics-daemons.html#AEN4716"><span class="footnote">[1]</span></a></td><td align="LEFT" valign="TOP" width="95%"><p>Not quite true--there are a few things that can not be interrupted. For example, ifthe process is trying to read from a file that is on another computer on the network, andthe other computer has gone away for some reason (been turned off, or the network has afault), then the process is said to be ``uninterruptible''. Eventually the process willtime out, typically after two minutes. As soon as this time out occurs the process willbe killed.</p></td></tr></table><div class="NAVFOOTER"><hr align="LEFT" width="100%" /><table summary="Footer navigation table" width="100%" border="0" cellpadding="0"cellspacing="0"><tr><td width="33%" align="left" valign="top"><a href="basics-processes.html"accesskey="P">Prev</a></td><td width="34%" align="center" valign="top"><a href="index.html"accesskey="H">Home</a></td><td width="33%" align="right" valign="top"><a href="shells.html"accesskey="N">Next</a></td></tr><tr><td width="33%" align="left" valign="top">Processes</td><td width="34%" align="center" valign="top"><a href="basics.html"accesskey="U">Up</a></td><td width="33%" align="right" valign="top">Shells</td></tr></table></div><p align="center"><small>This, and other documents, can be downloaded from <ahref="ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/">ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/</a>.</small></p><p align="center"><small>For questions about FreeBSD, read the <ahref="http://www.FreeBSD.org/docs.html">documentation</a> before contacting &#60;<ahref="mailto:questions@FreeBSD.org">questions@FreeBSD.org</a>&#62;.<br />For questions about this documentation, e-mail &#60;<ahref="mailto:doc@FreeBSD.org">doc@FreeBSD.org</a>&#62;.</small></p></body></html>
⌨️ 快捷键说明

复制代码 Ctrl + C
搜索代码 Ctrl + F
全屏模式 F11
切换主题 Ctrl + Shift + D
显示快捷键 ?
增大字号 Ctrl + =
减小字号 Ctrl + -