Apache是怎样启动的
如果配置文件中Listen定义的是默认的80端口(或1024以下)，那么启动Apache将 需要root权限以将它绑定在特权端口上。一旦服务器开始启动并完成了一些诸如打开日志文件之类的准备操作，它将创建很多子进程来完成一些诸如侦听和回应 客户端请求的工作。httpd主进程仍然以root用户的权限运行，而它的子进程将以一个较低权限的用户运行。这将由你选择的多路处理模块进行控制。
调用httpd可执行文件的推荐方法是使用apachectl控制脚本。此脚本设置了在某些操作系统中正常运行httpd所必需的环境变量，然后调用
httpd二进制文件。apachectl会传递命令行的所有参数，因此所有用于httpd的选项多半也可以用于apachectl
。你可以直接修改apachectl脚本，改变首部的HTTPD变量使之指向httpd可执行文件的正确位置，也可以设置任意的命令行参数，使之总是有
效。
httpd被调用后第一件要做的事情就是找到并读取配置文件httpd.conf 。此文件的位置是在编译时设定的，但也可以象下面这样在运行时用 -f 选项来指定：
/usr/local/apache2/bin/apachectl -f /usr/local/apache2/conf/httpd.conf
如果启动过程一切正常，服务器将与终端分离并几乎立即出现命令行提示符。这表示服务器已经启动并开始运行。然后你就可以用你的浏览器去连接你的服务器来查看DocumentRoot目录下的测试文档及其页面链接里的其它文档的本地副本。
启动时发生错误
如果Apache在启动过程中发生了致命错误，它将在退出前把描述这个错误的信息显示在终端上或者写入到ErrorLog中。一个最常产生的错误信息是"Unable to bind to Port ..."，这主要由以下原因造成：
想由一个特权端口启动服务但没有以root用户运行
启动服务时已经有另外的Apache实例在运行或其他的web服务器已经绑定了同样的端口
更多问题的解决办法，请参见常见问题。
随系统启动时启动
如果你希望你的服务器在系统重启后仍保持运行状态，你应该把apachectl的调用加入到你的系统启动文件中(通常为rc.local文件或rc.N目
录下的某一文件)。这将会以root权限启动Apache。当然，在此之前，你必须保证你的服务器已经完成了安全和访问权限的设定。
apachectl脚本被设计为可以用作SysV初始化脚本，它接受start、restart、stop参数，并把它们翻译为httpd对应的信号，所以通常都可以将apachectl连接到适当的初始目录，但是需要检查你的系统对此的精确要求。
额外信息
关于httpd和apachectl以及其他相关支持程序的命令行选项的详细信息请参见服务器和支持程序页面。其中还包括所有的随Apache发行包发布的模块和它们提供的指令的文档
停止和重启简介简介
为了停止或者重新启动Apache
，你必须向正在运行的httpd进程发送信号。有两种发送信号的方法。第一种方法是直接使用UNIX的kill命令向运行中的进程发送信号。你也许你会注
意到你的系统里运行着很多httpd进程。但你不应该直接对它们中的任何一个发送信号，而只要对已经在PidFile中记载下了自身PID的父进程发送信
号。也就是说，你不必对父进程以外的任何进程发送信号。你可以向父进程发送三种信号：TERM、HUP、USR1 ，我们过一会儿再进行详细的说明。
你可以用下面这样的命令来向父进程发送信号：
kill -TERM `cat /usr/local/apache2/logs/httpd.pid`
第二种方法是使用下面将要描述的httpd二进制可执行文件的 -k 命令行选项：stop、restart、graceful、graceful-stop 。不过我们推荐你使用apachectl控制脚本来向httpd二进制可执行文件传递这些选项。
当你向httpd发送信号后，你可以这样来读取它的进行过程：
tail -f /usr/local/apache2/logs/error_log
你可以修改这些示例以适应你的ServerRoot和PidFile设置。
立即停止
信号：TERM
apachectl -k stop
发送TERM或stop信号到父进程可以使它立刻杀死所有子进程。这将花费一些时间来杀死所有子进程。然后父进程自己也退出。所有进行中的请求将被强行中止，而且不再接受其它请求。
优雅重启
信号：USR1
apachectl -k graceful
USR1或graceful信号使得父进程建议子进程在完成它们现在的请求后退出(如果他们没有进行服务，将会立刻退出)。父进程重新读入配置文件并重新打开日志文件。每当一个子进程死掉，父进程立刻用新的配置文件产生一个新的子进程并立刻开始伺服新的请求。
重启代码的设计能够确保MPM进程控制指令的正常运作，也就是在重启过程中确保有适当数量的进程和线程以响应客户端的请求。它是这样
StartServers的：如果在一秒钟以后还没有新创建StartServers个子进程，则创建出足够完成现在任务的子进程个数。因此，代码除了保
有能够维持服务器的现有负载数量的子进程外，也确保StartServers按你的意愿运作。
使用mod_status的用户会注意到在USR1信号发出后，服务器的统计信息没有被清零。代码被写成既能将你服务器无法伺服新请求的时间降至最少(这
些请求将被操作系统放到队列里，使得它们不会丢失)，又能遵从你的参数优化。为了做到这一点，它将在重新生成子进程的过程中，在scoreboard上保
存所有子进程的状态。
mod_status还会将那些在优雅重启前就已经开始而没有结束伺服请求的子进程用一个"G"来标志。
目前，日志滚动脚本还无法使用USR1来确定所有写入预重启日志的子进程都已结束。我们建议你在发出了USR1信号后等待一个适当的时间，然后再对旧的日
志做处理。比如说如果对于一个窄带用户来说，大部分的点击处理将在10分钟之内完成，那么你应该在处理旧的日志前等待15分钟。
如果Apache重启时发现配置文件有误，那么父进程将不会重启，而是报错并退出。在优雅重启的情况下，它将在处理中的子进程存在的情况下维持它的存在
(就是那些被要求在处理完它们的请求后"优雅退出"的子进程)。如果你要重启服务器，这将导致一些问题：它将不能绑定到它的监听端口。在执行重启之前，你
可以用 -t
命令行参数来检查配置文件语法的正确性(参见httpd)。但这仍然不能保证服务器一定可以正确的重启。为了从语法和语义两方面检查配置文件，你可以用一
个非root用户来启动httpd。如果没有错误，它将尝试去打开套接字和日志文件，继而因没有root权限而失败(或是因为现在运行的httpd已经绑
定了这些端口)。如果是因为其他原因那么就可能是一个配置文件产生的错误，你就应当在进行优雅重启之前改正这个错误。
立即重启
信号：HUP
apachectl -k restart
向父进程发送HUP或restart信号会使它象收到TERM信号一样杀掉所有的子进程，不同之处在于父进程本身并不退出。它重新读入配置文件、重新打开日志文件。然后产生一系列新的子进程来继续服务。
使用mod_status的用户会注意到在HUP信号发出后，服务器统计信息会被清零。
如果你重启时配置文件有误，那么父进程将不会重启，而是报错并退出。参见上文中避免的方法。
优雅停止
信号：WINCH
apachectl -k graceful-stop
WINCH或graceful-stop信号使得父进程建议子进程在完成它们现在的请求后退出(如果他们没有进行服务，将会立刻退出)。然后父进程删除
PidFile并停止在所有端口上的监听。父进程仍然继续运行并监视正在处理请求的子进程，一旦所有子进程完成任务并退出或者超过由
GracefulShutdownTimeout指令规定的时间，父进程将会退出。在超时的情况下，所有子进程都将接收到TERM信号并被强制退出。
在"优雅"状态下，TERM信号将会立即中止父进程和所有子进程。由于PidFile已经被删除，你将无法使用apachectl或httpd发送该信号。
graceful-stop允许你同时运行多个相同配置的httpd实例。这在对Apache进行平滑升级的时候是一个非常有用的特性。不过它在某些配置的情况下同样可能会导致死锁和竞争条件。
必须注意确保诸如Lockfile和ScriptSock之类的磁盘文件包含服务器的PID ，并且能够安全的共存。然而如果一个配置指令、第三方模块或持久CGI使用任何磁盘锁或状态文件，必须注意确保多个httpd运行实例之间不会争抢文件。
你还必须防止潜在的竞争条件，比如使用rotatelogs风格的管道日志。运行中的多个rotatelogs实例企图同时滚动同一个日志文件可能会导致互相破坏对方的日志文件。
信号和竞争条件
在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次，而客户端却成功的浏览了网站，而且没有任 何破损的图片或空文档 。