7

I am checking /usr/local/apache/logs/error_log

This has happened several times. Sometimes server restart is fast sometimes it's slow. What factor could possibly contribute to this mess.

[Mon Dec 31 21:40:49 2012] [notice] Graceful restart requested, doing restart
[Mon Dec 31 21:40:53 2012] [error] [client 66.249.74.237] File does not exist: /home2/wallpape/public_html/tag
[Mon Dec 31 21:40:53 2012] [error] [client 66.249.74.237] File does not exist: /home2/wallpape/public_html/404.shtml
[Mon Dec 31 21:50:02 2012] [notice] SSL FIPS mode disabled
[Mon Dec 31 21:50:03 2012] [notice] Apache/2.2.23 (Unix) mod_ssl/2.2.23 OpenSSL/1.0.0-fips mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635 configured -- resuming normal operations

On the other hand ungraceful restart seems to be faster:

[Mon Dec 31 21:52:58 2012] [notice] SIGHUP received.  Attempting to restart
[Mon Dec 31 21:52:58 2012] [notice] SSL FIPS mode disabled
[Mon Dec 31 21:52:58 2012] [notice] Apache/2.2.23 (Unix) mod_ssl/2.2.23 OpenSSL/1.0.0-fips mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635 configured -- resuming normal operations

From the manual: http://httpd.apache.org/docs/2.2/stopping.html

The parent re-reads its configuration files and re-opens its log files. As each child dies off the parent replaces it with a child from the new generation of the configuration, which begins serving new requests immediately.

It seems that graceful restart is designed so that service can run with no interruption at all. It doesn't work that way though. All domains in my server is death while restarting :(

0

3 Answers 3

6

A graceful restart waits for all current connections to close before restarting, whereas a standard restart just aborts current connections.

3
  • I see. And that's actually increase downtime. Jan 1, 2013 at 5:34
  • 3
    @SeptiadiAgus: Yes, but it also doesn't kill ongoing requests. Pick your poison.
    – Sven
    Jan 1, 2013 at 5:49
  • 1
    The manual seems to suggest that graceful restart is not restarting httpd server at all. the httpd server load new config and pop up new children based on that. Am I missing something? Jan 1, 2013 at 6:13
9

Note that if you have an invalid hostname in your etc/hosts file -- for example, if you did not modify the default installation settings -- then you may wait up to 90 seconds for various tasks to be performed, including starting/restarting httpd.

vi /etc/hosts

Change

127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

To

127.0.0.1   localhost
::1         localhost
111.222.333.444  www.mysite.com mysite.com

References:

/etc/hosts entry for single IP server serving multiple domains

https://unix.stackexchange.com/questions/57439/slow-start-of-midnight-commander#answer-397879

2
  • Incredible, but true. Restarting apache went from 4 min to 10 seconds. Thanks a lot.
    – 4wk_
    Oct 2, 2018 at 7:37
  • Thanks. The one that set that default value there is savage :)
    – adrianTNT
    Jan 25, 2020 at 4:44
0

When using graceful restart, the parent apache process stops accepting new connections and waits forever for all the child processes to exit. So essentially the web server is dead (other than existing connections) until all the existing children exit.

In the normal use case of short-lived http/https connections, this is not a problem when doing a graceful shutdown or restart...it should normally take a second. The problem is when you have something that delays the children exiting, such as persistent websocket connections. In that case the server will never actually manage to gracefully stop/restart...it will just sit there forever in a semi-dead state.

You can adjust the delay using the GracefulShutdownTimeout directive:

https://httpd.apache.org/docs/2.4/mod/mpm_common.html#gracefulshutdowntimeout

By default it is set to 0 (infinite). 5 seconds is a more reasonable value.

Note that when using systemctl to restart the server, it will only wait a maximum of 90 seconds by default before forcing it to kill the child processes (rather than forever), which is why you are seeing this 90 second delay. This is set in /etc/systemd/system.conf:

#DefaultTimeoutStopSec=90s

This can also be changed for individual units using the TimeoutStopSec option.

1
  • 1
    Of course you can't change DefaultTimeoutStopSec in an individual service, it's the default. You change TimeoutStopSec instead. Jul 17, 2021 at 18:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.