Bug 464815 - "service httpd reload" says "ok" even though the reload actually failed
"service httpd reload" says "ok" even though the reload actually failed
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: httpd (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Joe Orton
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-09-30 12:54 EDT by Dennis Jacobfeuerborn
Modified: 2008-09-30 14:56 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-09-30 14:56:31 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Dennis Jacobfeuerborn 2008-09-30 12:54:42 EDT
After making a typo in the log directory name of vhost and reloading the httpd config the system responded with "Reloading httpd: [Ok]". The truth was that the daemon couldn't find the log directory and terminated.

The best course of action for the daemon would be to refuse the new configuration and keep running with the old but at least the init.d script should properly report the failure of the daemon and not respond with "Ok".
Comment 1 Joe Orton 2008-09-30 14:56:31 EDT
1) The init script does run "httpd -t" to test the configuration before doing a reload

2) running "httpd -t" does not catch all possible configuration errors, nor would it be possible to catch all cases where the *running* httpd binary would fail after a reload (notably, if the package has been updated, the running httpd might not be the same executable as /usr/sbin/httpd on disk)

3) "reload" simply SIGHUPs the daemon, and reports success if the daemon has been signalled; there is no validation of the subsequent state of the daemon beyond that, nor do I think any such would be feasible/appropriate

Hope that helps!

Improving the situation for (2) is vaguely on my long-distance radar of things to improve upstream, FWIW, but the status quo is behaviour as intended.

Note You need to log in before you can comment on or make changes to this bug.