Apache HTTP服务器 2.0版本
Apache HTTP服务器 2.0版本
本文档涵盖了在Unix类的系统上停止和重启Apache。 Windows NT, 2000 和 XP 用户请参见以服务方式运行Apache， Windows 9x和ME用户则参见在控制台中运行Apache
也许你会注意到你的系统里运行着很多httpd进程。
但你不应直接对它们中的任何一个发送信号，而只要对已经在PidFile记载下了pid的它们的父进程发送信号。
也就是说，你不必对父进程以外的任何进程发送信号。你可以向父进程发送三种信号：
TERM,
HUP, 和
USR1,
我们一会儿会进行详细的说明。
你可以用下面这样的命令来向父进程发送信号：
kill -TERM `cat /usr/local/apache/logs/httpd.pid`
你可以这样来读取它的进行过程：
tail -f /usr/local/apache/logs/error_log
修改这些示例以适应你的ServerRoot和PidFile设置。
同时提供了一个名叫apachectl 的shell脚本以自动向Apache发送信号。此脚本的详细情况请参见启动Apache。
apachectl stop发送一个TERM信号到父进程以使它立刻杀死它所有的子进程。
这将花费一些时间来杀死所有的子进程。此后，父进程自己也退出。
所有进行中的请求被中止，而且不再接受其它请求。
apachectl gracefulUSR1信号使得父进程建议子进程在完成它们现在的请求后退出
(如果他们没有进行服务，将会立刻退出)。父进程重新读入它的配置文件并重新打开它的日志文件。
每当一个子进程死掉，父进程立刻用配置文件新产生一个子进程并立刻开始伺服新的请求。
apachectl温和重启将会发送与您的平台相适应的正确信号。此(重启)代码的设计能够确保MPM进程控制指令的正常运作，即，
在重启过程中保有适当数量的进程和线程以响应客户端的请求。
它是这样StartServers的：
如果在一秒钟以后还没有新创建一个StartServers的子进程，
则创建出足够完成现在任务的子进程。因此，
代码除了保有能够维持服务器的现有负载数量的子进程外，也确保StartServers按你的意愿运作。
使用mod_status的用户会注意到在USR1信号发出后，
服务器的统计信息没有被清零。
代码被写成既能将你服务器无法伺服新请求的时间降至最少
(这些请求将被操作系统放到队列里，使得它们不会丢失)，
又能遵从你参数的优化。为了做到这一点，它将在重新生成子进程的过程中，
在scoreboard上保存所有子进程的状态。
状态模块还会将那些在温和重启前就已经开始而没有结束伺服请求的子进程用一个
G来标志。
目前，日志回卷脚本还无法使用USR1确定所有写入预重启日志的子进程都已结束。
我们建议你在发出了USR1信号后等待一个适当的时间，然后再对旧的日志做处理。
比如说如果对于一个窄带用户来说，大部分的点击处理将在10分钟之内完成，
那么你应该在处理旧的日志前等待15分钟。
-t命令行参数来检查配置文件语法的正确性
(参见httpd)。但这仍不能保证服务器能正确的重启。
为了从语法和语义的方面检查配置文件，你可以以一个非root用户来启动httpd。
如果没有错误，它将尝试去打开它的套接字和日志文件，
继而因没有root权限而失败(或是因为现在运行的httpd已经绑定了这些端口)。
如果是因为其他原因那么这就可能是一个配置文件产生的错误，
而你就应当在进行温和重启之前来改正这个错误。apachectl restart向父进程发送HUP或restart信号
会使它象收到TERM信号一样杀掉所有的子进程，
不同之处在于父进程本身并不退出。它重新读入它的配置文件，重新打开日志文件。
然后产生一系列新的子进程来继续它的服务。
使用mod_status的用户会注意到在HUP信号发出后，服务器统计会清零。
在Apache 1.2b9 之前，有很多关于重启和死亡信号的竞争状态 (关于竞争状态的一个简单描述是：一个时间敏感的问题，如果一些事情在不适当的时间发生， 它将不会作出你期望的反应)。凭借那些拥有“正确的”特性设置的结构，我们尽量避免了它们的出现。 但值得注意的是，仍有一些竞争状态存在于某些特定的结构中。
使用物理磁盘的ScoreBoardFile
就有损坏ScoreBoard的潜在危险。这将发生在“bind: Address already in use”(在HUP之后)
或者“long lost child came home!”(在USR1之后)时。前者是一个致命错误，
而后者则会使服务器丢失ScoreBoard的一个记录。所以我们建议多使用温和重启，
偶尔使用硬重启。这些问题很难解决，但幸运的是大多数结构不需要一个ScoreBoard文件。
而如果你需要这样的结构，你可以参考ScoreBoardFile文档。
当每个子进程在一个HTTP的持续连接(KeepAlive)中涉及到第二个并发的请求时， 所有的结构都会存在一点竞争状态的问题。它将在读取了请求而没有读取任何请求头之后立刻退出。 这个修复说明对于1.2 来说来得太晚了。 但因为持续连接的客户端已经考虑到网络延时和服务器超时会造成类似的情况， 所以理论上说，这不是一个太大的问题。而实际上似乎也没有任何影响 -- 在一个测试案例中服务器在一秒之内被重启了20次，而客户端却成功的浏览了网站， 而且没有任何破损的图片或空文档。