Description of problem: Apache reload actually restarts Apache, closing current connections. The init script executes the line "killproc $httpd -HUP". The HUP signal means actually restarting. apachectl manual says reloading must be done with "apachectl graceful", which sends a SIGUSR1 signal. As an example of the correct behaviour, here are the lines used in Debian init script, reload function : " if ! $APACHE2CTL configtest > /dev/null 2>&1; then $APACHE2CTL configtest || true log_end_msg 1 exit 1 fi log_daemon_msg "Reloading web server config" "apache2" if pidof_apache > /dev/null ; then if $APACHE2CTL graceful $2 ; then log_end_msg 0 else log_end_msg 1 fi fi " The important lines are apachectl configtest + apachectl graceful. Version-Release number of selected component (if applicable): 2.2.3 How reproducible: Steps to Reproduce: 1. /etc/init/apache2 reload Actual results: Restarts Apache Expected results: Reload Apache configuration Additional info:
Thanks for the feedback. You can already use "service httpd graceful" if you wish to perform a graceful restart in preference to a reload/HUP, as you may already be aware. "" Actual results: Restarts Apache Expected results: Reload Apache configuration "" These statements are rather ambiguous. Both a SIGHUP and a SIGUSR1 will "restart Apache", and both will "reload [the] Apache configuration". The difference is only in how the behaviour effects currently-connected clients. It is somewhat arbitrary to which specific behaviour the init script "reload" maps to; the chosen behaviour is to forcibly reload the server into the new configuration as soon as possible. Note that if, for example, a security-related config change has been made, it would be surprising behaviour for many users if that config change did not take affect for all clients immediately. Changing the behaviour of the init script at this stage would certainly be surprising to many existing users (the behaviour has remained the same for as long as the package has existed, as far as I'm aware). We would need a very strong argument to force a change here and I'm not seeing such an argument here.
> > You can already use "service httpd graceful" if you wish to perform a graceful > > restart in preference to a reload/HUP, as you may already be aware. Yes, I saw that in the init script, but a "graceful" alone doesn't check config first and might try to reload apache with a bad config and so it would no more run. The configtest + graceful as in Debian doesn't stop Apache if the config is buggy. > > "" > > Actual results: > > Restarts Apache > > > > Expected results: > > Reload Apache configuration > > "" > > > > These statements are rather ambiguous. Both a SIGHUP and a SIGUSR1 will > > "restart Apache", and both will "reload [the] Apache configuration". The > > difference is only in how the behaviour effects currently-connected clients. Yes, right. > > It is somewhat arbitrary to which specific behaviour the init script "reload" > > maps to; This is now defined in LSB 3.0 : http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html "reload : cause the configuration of the service to be reloaded without actually stopping and restarting the service" I interpret that as sending a "apachectl graceful" command to apache instead of "apachectl restart" (= SIGHUP). > > the chosen behaviour is to forcibly reload the server into the new > > configuration as soon as possible. Note that if, for example, a > > security-related config change has been made, it would be surprising behaviour > > for many users if that config change did not take affect for all clients > > immediately. Security-related config changes should use a force-reload / restart for this reason, not reload. > > Changing the behaviour of the init script at this stage would certainly be > > surprising to many existing users (the behaviour has remained the same for as > > long as the package has existed, as far as I'm aware). As you wish. I'm not a regular Redhat user anyway, so I don't really matter what you will finally change or not. Just trying to help. > > We would need a very > > strong argument to force a change here and I'm not seeing such an argument > > here. I think the LSB argument is good enough.
(In reply to comment #2) > Yes, I saw that in the init script, but a "graceful" alone doesn't check > config first and might try to reload apache with a bad config and so it > would no more run. That's not correct. graceful calls out to apachectl which runs httpd -t before proceeding. > > > It is somewhat arbitrary to which specific behaviour the init script "reload" > > > maps to; > > This is now defined in LSB 3.0 : > http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html > > "reload : cause the configuration of the service to be reloaded without > actually stopping and restarting the service" > > I interpret that as sending a "apachectl graceful" command to apache > instead of "apachectl restart" (= SIGHUP). It seems very clear to me that both a SIGHUP or a graceful restart cause the config to be reloaded without stopping and restarting the service, and either would meet the requirement of the LSB spec. Were the LSB spec to specify a preference for graceful, it must make reference to active connections; it does not, so I can't see what your interpretation is based on. > > > the chosen behaviour is to forcibly reload the server into the new > > > configuration as soon as possible. Note that if, for example, a > > > security-related config change has been made, it would be surprising behaviour > > > for many users if that config change did not take affect for all clients > > > immediately. > > Security-related config changes should use a force-reload / restart for > this reason, not reload. Having different behaviour for force-reload and reload makes little sense for this init script. force-reload exists only to allow daemons which cannot do an in-place reload to fallback on stop/start, such that automated callers can use "force-reload" to perform a restart in the best supported fashion.