How to restart Apache under Linux

Linux System for Ubuntu

First, start Apache 2 Server/start Apache service

#/etc/init.d/apache2 Start

Or

$ sudo/etc/init.d/apache2 Start

Second, restart Apache 2 Server/restart Apache service

#/etc/init.d/apache2 Restart

Or

$ sudo/etc/init.d/apache2 Restart

Third, stop Apache 2 Server/stop Apache Service

#/etc/init.d/apache2 Stop

Or

$ sudo/etc/init.d/apache2 Stop

Apache Restart and stop under Linux

This document describes how to stop and restart Apache on a Unix-like system. Users of Windows nt/2000/xp/2003 see running Apache as a service, and Windows 9x/me users see running Apache in the console.

Brief introduction

To stop or restart Apache, you must send a signal to the running httpd process. There are two ways to send signals. The first approach is to send a signal to a running process directly using the KILL command for UNIX. You may notice that there are a lot of httpd processes running in your system. But you should not send a signal directly to any one of them, as long as you send a signal to a parent process that has already documented its own PID in Pidfile. In other words, you do not have to send a signal to any process other than the parent process. You can send three kinds of signals to the parent process: TERM, HUP, USR1, and we'll give you a detailed explanation in a moment.

You can send a signal to the parent process using the following command:

Kill-term ' Cat/usr/local/apache2/logs/httpd.pid '

The second method uses the-K command-line option of the httpd binary executable described below: Stop, restart, graceful, graceful-stop. However, we recommend that you use the Apachectl control script to pass these options to the httpd binary executable file.

When you send a signal to httpd, you can read it in this way:

Tail-f/usr/local/apache2/logs/error_log

You can modify these samples to suit your serverroot and pidfile settings.

Stop Now

Signal: TERM

Apachectl-k stop

Sending a term or stop signal to the parent process can cause it to kill all child processes immediately. This will take some time to kill all the child processes. The parent process then exits itself as well. All in-progress requests are aborted and no further requests are accepted.

Graceful restart

Signal: USR1

Apachectl-k Graceful

The USR1 or graceful signal enables the parent process to recommend that the subprocess exit after completing their present request (if they do not perform the service, they will exit immediately). The parent process reads back into the configuration file and opens the log file again. Every time a child process dies, the parent process immediately creates a new subprocess with the new configuration file and immediately begins to servo the new request.

The design of the restart Code ensures that the MPM process controls the normal operation of the instructions, that is, to ensure that there are adequate numbers of processes and threads to respond to client requests during the reboot process. It's startservers: If you haven't created a startservers child process in a second, create a number of child processes that are enough to complete the task now. As a result, the code also ensures that Startservers operates as you wish, in addition to the subprocess that maintains the number of existing loads on the server.

Users who use Mod_status will notice that the server's statistics are not zeroed after the USR1 signal is sent. The code is written to minimize the amount of time that your server will not be able to servo new requests (which are placed in the queue by the operating system so they are not lost) and can be tuned to your parameters. To do this, it will save the state of all child processes on the scoreboard during the process of rebuilding the child process.

Mod_status also uses a "G" to flag the child processes that have started before graceful restart without ending the servo request.

Currently, log scrolling scripts cannot use USR1 to determine that all child processes written to the pre-restart log have ended. We recommend that you wait for an appropriate time after sending the USR1 signal and then deal with the old log. For example, if for a narrowband user, most of the click Processing will be done in 10 minutes, then you should wait for 15 minutes before processing the old log.

If the configuration file is found to be incorrect when Apache restarts, the parent process will not reboot, but the error and exit. In graceful restarts, it will maintain its presence in the presence of the child processes in process (those that are required to "gracefully exit" after their request is processed). If you want to reboot the server, this will cause some problems: it will not be able to bind to its listening port. Before performing a reboot, you can check the correctness of the configuration file syntax with the-t command-line argument (see HTTPD). However, this still does not guarantee that the server will be able to reboot correctly. To check the configuration file from both syntax and semantics, you can start httpd with a non-root user. If there is no error, it will attempt to open the socket and log files, and then fail because there is no root permission (or because the httpd that are now running already have these ports bound). If for other reasons it may be a configuration file error, you should correct the error before graceful restart. Reboot now

Signal: HUP

Apachectl-k restart

Sending a hup or restart signal to the parent process kills all of the child processes as if they received the term signal, except that the parent process itself does not exit. It reads back into the configuration file and opens the log file again. Then a series of new child processes are generated to continue the service.

Users who use Mod_status will notice that the server statistics are zeroed out after the HUP signal is sent.

If the configuration file is incorrect when you reboot, the parent process will not reboot, but the error and exit. See the method avoided in the above. Graceful Stop

Signal: Winch

Apachectl-k Graceful-stop

The winch or graceful-stop signal enables the parent process to recommend that the subprocess exit after completing their present request (if they do not perform the service, they will exit immediately). The parent process then deletes the pidfile and stops listening on all ports. The parent process continues to run and monitors the child process that is processing the request, and the parent process exits once all the child processes complete the task and exit or exceed the time specified by the gracefulshutdowntimeout instruction. In the case of a timeout, all child processes receive the term signal and are forced to quit.

In graceful state, the term signal immediately aborts the parent process and all child processes. Since Pidfile has been removed, you will not be able to send the signal using APACHECTL or httpd.

Graceful-stop allows you to run multiple httpd instances of the same configuration at the same time. This is a very useful feature when you have a smooth upgrade of Apache. However, it can also lead to deadlocks and competitive conditions in some configurations.

Care must be taken to ensure that disk files such as Lockfile and Scriptsock contain the PID of the server and can coexist securely. However, if a configuration directive, Third-party module, or persistent CGI uses any disk locks or state files, you must be careful to ensure that there are no competing files between multiple httpd running instances.

You must also prevent potential competitive conditions, such as using rotatelogs-style piping logs. Running multiple Rotatelogs instances attempting to scroll the same log file at the same time can cause each other's log files to be corrupted.

Appendix: Signals and competitive conditions

Before the Apache 1.2b9, there were a lot of competitive conditions for restart and death signals. A simple description of the competitive conditions is: a time-sensitive question, if something happens at an inappropriate time or in an improper order, it will make a response that you do not expect; if the same thing happens at the right time, there will be no exception. We try to avoid them with the architecture that has the "right" feature set. It is worth noting, however, that there are still competitive conditions in this architecture.

Scoreboardfile using a physical disk can have a potential risk of damaging scoreboard. This will happen after "Bind:address already in" (HUP) or "long Lost Child came home!" (after USR1). The former is a fatal error, while the latter causes the server to lose a record of scoreboard. So we recommend using more graceful reboots and occasionally using hard reboots. These problems are difficult to solve, but fortunately most structures do not require scoreboard files. And if you need such a structure, you can refer to the Scoreboardfile document.

When each subprocess involves a second concurrent request in an HTTP persistent connection (KeepAlive), all structures will have a more or less competitive state problem. It will exit immediately after reading the request without reading any request headers. The fix was too late for 1.2来. In theory, however, this is not a big problem because the clients that are continually connected have taken into account the network latency and the server timeout will cause a similar situation. In fact, it does not seem to have any effect: in a test case the server was restarted 20 times in a second, while the client successfully browsed the Web site without any corrupted pictures or empty documents.