停止apache服务的命令_linux 重启apache

tail -f /usr/local//日志/

您可以修改这些示例以适合您的设置。

现在停止

信号：学期

-k 停止

向父进程发送 TERM 或停止信号可能会导致其立即终止所有子进程。这将需要一些时间来杀死所有子进程。然后父进程本身退出。所有正在进行的请求将被强制中止，并且不再接受进一步的请求。

优雅重启

信号：USR1

-k

USR1 或信号导致父进程建议子进程在完成当前请求后退出（如果它们不提供服务，它们将立即退出）。父进程重新读取配置文件并重新打开日志文件。每当一个子进程死亡时，父进程立即使用新的配置文件创建一个新的子进程，并立即开始服务新的请求。

重启代码的目的是保证MPM进程控制指令的正常运行，即保证重启过程中有适当数量的进程和线程来响应客户端请求。它是这样的：如果一秒钟后没有创建新的子进程，则创建足够的子进程来完成当前任务。因此，除了维护许多可以维持服务器上当前负载的子进程之外，还保证代码按照您的意愿运行。

用户会注意到发送USR1信号后服务器统计数据并没有被清除。编写代码的目的是最大限度地减少服务器无法处理新请求的时间（这些请求将由操作系统排队，以便它们不会丢失），并符合您的参数优化。为了做到这一点，它将在重新生成子进程的过程中保存所有子进程的状态。

那些在优雅重启之前已启动但尚未结束服务请求的子进程也会被标记为“G”。

目前，日志滚动脚本无法使用USR1来确定写入预重启日志的所有子进程都已结束。我们建议您在发送 USR1 信号后等待适当的时间，然后再处理旧日志。例如，如果对于窄带用户，大多数点击处理将在 10 分钟内完成，那么您应该等待 15 分钟后再处理旧日志。

如果重启时发现配置文件错误，父进程不会重启，而是报错并退出。在正常重启的情况下，当它正在处理的子进程存在时（即那些在处理其请求后需要“正常退出”的子进程），它将保持其存在。如果您要重新启动服务器，这将导致一些问题：它将无法绑定到其侦听端口。在执行重启之前，可以使用-t命令行参数检查配置文件语法的正确性（参见httpd）。但这仍然不能保证服务器能够正确重启。为了从语法和语义上检查配置文件，您可以以非 root 用户身份启动 httpd。如果没有错误，它将尝试打开套接字和日志文件，然后失败，因为它没有root权限（或者因为当前运行的httpd已经绑定了这些端口）。如果是由于其他原因，则可能是配置文件错误，您应该在执行正常重新启动之前更正该错误。

立即重新启动

信号：HUP

-k

向父进程发送 HUP 或信号将导致其杀死所有子进程，就像收到 TERM 信号一样。不同的是父进程本身并不退出。它重新读取配置文件并重新打开日志文件。然后会产生一系列新的子进程来继续提供服务。

用户会注意到，发送HUP信号后，服务器统计信息将被清除。

如果重启时配置文件不正确，父进程不会重启，而是报错并退出。请参阅上文了解避免这种情况的方法。

优雅的停止

信号：绞车

-k -停止

WINCH 或 -stop 信号使父进程建议子进程在完成当前请求后退出（如果它们不提供服务，它们将立即退出）。然后，父进程删除并停止侦听所有端口。父进程仍然继续运行并监视正在处理请求的子进程。一旦所有子进程完成任务并退出或者超过out指令指定的时间，父进程就会退出。如果超时，所有子进程都会收到 TERM 信号并被迫退出。

在“优雅”状态下，TERM信号将立即终止父进程和所有子进程。由于它已被删除，您将无法使用 httpd 或 httpd 发送该信号。

-stop 允许您同时运行多个配置相同的 httpd 实例。在执行平滑升级时，这是一个非常有用的功能。然而，它也可能在某些配置中导致死锁和竞争条件。

必须注意确保诸如 和 等包含服务器PID 的磁盘文件能够安全共存。但是，如果配置指令、第三方模块或持久 CGI 使用任何磁盘锁或状态文件，则必须注意确保 httpd 的多个运行实例之间不存在文件争用。

您还必须防止潜在的竞争条件，例如使用样式管道日志记录。多个正在运行的实例尝试同时滚动同一日志文件可能会导致彼此损坏彼此的日志文件。

信号和竞争条件

在 1.2b9 之前，有很多关于重启和死亡信号的竞争条件。竞争条件的简单描述是：一个时间敏感的问题，如果某件事在错误的时间或以错误的顺序发生，它会以你意想不到的方式做出反应；如果同样的事情在正确的时间发生，就不会发生异常。我们试图通过依赖具有“正确”功能集的架构来避免它们。但值得注意的是，这种架构中仍然存在一些竞争条件。

使用物理磁盘时存在潜在的损坏风险。当“bind: in use”（HUP 之后）或“失散多年的孩子回家了！”时会发生这种情况。 （USR1 之后）。前者是致命错误，而后者会导致服务器丢失一条记录。因此，我们建议更多地使用平滑重启，偶尔使用硬重启。这些问题很难解决，但幸运的是大多数结构不需要文件。而如果你需要这样的结构，可以参考文档。

当每个子进程参与 HTTP 持久连接（）中的第二个并发请求时，所有结构都会或多或少地存在竞争条件。它会在读取请求后立即退出，而不读取任何请求头。这个修复对于 1.2 来说来得太晚了。但因为长连接的客户端已经考虑到了网络延迟和服务器超时会导致类似的情况，所以理论上这并不是什么大问题。事实上，似乎没有任何影响：在一个测试案例中，服务器在一秒钟内重新启动了 20 次，而客户端成功浏览了网站，没有任何损坏的图像或空文档。