Shulou(Shulou.com)06/01 Report--

This article is to share with you about how to restart apache in Linux. The editor thinks it is very practical, so I share it with you. I hope you can get something after reading this article.

Linux system is Ubuntu

1. Start Apache 2 Server / start apache service

# / etc/init.d/apache2 start

Or

$sudo / etc/init.d/apache2 start

2. Restart Apache 2 Server / restart apache service

# / etc/init.d/apache2 restart

Or

$sudo / etc/init.d/apache2 restart

3. Stop Apache 2 Server / stop the apache service

# / etc/init.d/apache2 stop

Or

$sudo / etc/init.d/apache2 stop

Restart and stop apache under linux

This document describes how to stop and restart Apache on Unix-like systems. For users of Windows NT/2000/XP/2003, see running Apache as a service, and for 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 a signal. The first method is to use UNIX's kill command directly to signal a running process. You may notice that there are many httpd processes running on your system. But you should not send a signal directly to any of them, just send a signal to a parent process that has recorded its own PID in PidFile. That is, you don't have to signal any process other than the parent process. You can send three signals to the parent process: TERM, HUP, and USR1, which we will explain in detail later.

You can use the following command to signal the parent process:

Kill-TERM `cat / usr/local/apache2/logs/ httpd.pid`

The second method is to use the-k command-line options of the httpd binary executable that will be 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.

When you send a signal to httpd, you can read its progress like this:

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

You can modify these examples to suit your ServerRoot and PidFile settings.

Stop immediately

Signal: TERM

Apachectl-k stop

Sending a TERM or stop signal to the parent process causes it to kill all child processes immediately. This will take some time to kill all child processes. Then the parent process exits itself. All ongoing requests will be forcibly suspended and no other requests will be accepted.

Elegant restart

Signal: USR1

Apachectl-k graceful

The USR1 or graceful signal causes the parent process to advise the child process to exit after completing their current request (if they are not in service, they will exit immediately). The parent process re-reads the configuration file and reopens the log file. Whenever a child process dies, the parent process immediately generates a new child process with the new configuration file and immediately starts to serve the new request.

The restart code is designed to ensure the proper operation of the MPM process control instructions, that is, to ensure that an appropriate number of processes and threads respond to client requests during the restart process. It is StartServers like this: if no new StartServers subprocesses are created after a second, then create enough subprocesses to complete the current task. Therefore, in addition to holding child processes that can maintain the current load on the server, the code also ensures that the StartServers works as you wish.

Users using mod_status will notice that the server's statistics are not cleared after the USR1 signal is sent. The code is written to minimize the time when your server cannot serve new requests (which will be queued by the operating system so that they are not lost) while complying with your parameter optimization. To do this, it will save the state of all child processes on the scoreboard during the process of regenerating the child processes.

Mod_status also marks subprocesses that start before the graceful restart without ending the servo request with a "G".

Currently, the log scrolling script 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 process the old log. For example, if for a narrowband user, most click processing will be completed within 10 minutes, then you should wait 15 minutes before processing the old log.

If the configuration file is found to be incorrect when Apache is restarted, the parent process will not restart, but will report an error and exit. In the case of a graceful restart, it will maintain its existence in the presence of the child processes in progress (that is, those that are required to "gracefully exit" after processing their requests). If you restart the server, this will cause some problems: it will not be able to bind to its listening port. Before performing a restart, you can check the syntax of the configuration file with the-t command line argument (see httpd). But there is still no guarantee that the server will restart correctly. To check the configuration file both syntactically and semantically, you can start httpd with a non-root user. If there are no errors, it will try to open sockets and log files, and then fail because it does not have root permissions (or because the running httpd is already bound to these ports). If it's something else, it could be an error caused by a configuration file, and you should correct it before doing an elegant restart. Restart immediately

Signal: HUP

Apachectl-k restart

Sending a HUP or restart signal to the parent process causes it to kill all child processes as if it had received a TERM signal, except that the parent process itself does not exit. It re-reads the configuration file and reopens the log file. Then a series of new subprocesses are generated to continue the service.

Users using mod_status will notice that the server statistics are cleared after the HUP signal is sent.

If you restart the configuration file incorrectly, the parent process will not restart, but will report an error and exit. See the methods avoided above. Elegant stop

Signal: WINCH

Apachectl-k graceful-stop

The WINCH or graceful-stop signal causes the parent process to advise the child process to exit after completing their current request (if they are not in 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 processes that are processing the request. Once all the child processes complete the task and exit or exceed the time specified by the GracefulShutdownTimeout directive, the parent process will exit. In the case of a timeout, all child processes will receive a TERM signal and be forced to exit.

In the "elegant" state, the TERM signal immediately aborts the parent process and all child processes. Since PidFile has been deleted, 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 upgrading Apache smoothly. However, it can also lead to deadlocks and race conditions in some configurations.

Care must be taken to ensure that disk files such as Lockfile and ScriptSock contain the server's PID and can coexist safely. However, if a configuration instruction, third-party module, or persistent CGI uses any disk locks or status files, care must be taken to ensure that files are not competing among multiple httpd running instances.

You must also prevent potential competitive conditions, such as using rotatelogs-style pipeline logs. Attempts by multiple running rotatelogs instances to scroll the same log file at the same time may result in corrupting each other's log files.

Appendix: signals and competitive conditions

Before Apache 1.2b9, there were a lot of competition conditions for restart and death signals. A simple description of competitive conditions is: a time-sensitive problem, if something happens at the wrong time or in the wrong order, it will react in a way that you do not expect; if the same thing happens at the right time, there will be no exception. With architectures that have "correct" feature settings, we try to avoid them. However, it is worth noting that there are still some competitive conditions in such an architecture.

There is a potential risk of corrupting ScoreBoard with ScoreBoardFile on physical disks. This will happen when "bind: Address already in use" (after 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. Therefore, we recommend using more elegant restarts and occasional hard restarts. These problems are difficult to solve, but fortunately most structures do not require ScoreBoard files. If you need such a structure, you can refer to the ScoreBoardFile documentation.

When each child process involves a second concurrent request in a persistent connection (KeepAlive) of an HTTP, all structures are more or less in a competitive state. It will exit immediately after reading the request without reading any request headers. This fix came too late for 1.2. But because clients with persistent connections have taken into account similar situations caused by network latency and server timeouts, in theory, this is not a big problem.

The above is how to restart apache in Linux. The editor believes that there are some knowledge points that we may see or use in our daily work. I hope you can learn more from this article. For more details, please follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.