Bug 480624

Summary: Apache reload actually restarts Apache, closing current connections
Product: Red Hat Enterprise Linux 5 Reporter: Damien Laniel <dlaniel>
Component: httpdAssignee: Joe Orton <jorton>
Status: CLOSED NOTABUG QA Contact: BaseOS QE <qe-baseos-auto>
Severity: medium Docs Contact:
Priority: low    
Version: 5.2Keywords: Reopened
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-01-19 16:33:17 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Damien Laniel 2009-01-19 14:32:22 UTC
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:

Comment 1 Joe Orton 2009-01-19 14:57:19 UTC
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.

Comment 2 Damien Laniel 2009-01-19 15:52:54 UTC
> > 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.

Comment 3 Joe Orton 2009-01-19 16:33:17 UTC
(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.