Bug 492753
Summary: | Logrotate kills httpd after a "yum update" | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Nadav Har'El <nyh> |
Component: | httpd | Assignee: | Joe Orton <jorton> |
Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | high | Docs Contact: | |
Priority: | low | ||
Version: | 10 | CC: | benny+bugzilla, dnovotny, jbaker, jorton, pahan, simon.andrews, tsmetana |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2009-08-18 12:04:21 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
Nadav Har'El
2009-03-29 10:39:59 UTC
signalling Apache to reset log files by SIGHUP is the right thing documented in Apache (http://httpd.apache.org/docs/1.3/misc/howto.html#logreset) so logrotate did nothing wrong. reassigning to httpd Just to add that our webserver had exactly the same problem following a recent logrotate: [Sun Mar 29 04:14:10 2009] [notice] SIGHUP received. Attempting to restart httpd: Syntax error on line 188 of /etc/httpd/conf/httpd.conf: Cannot load /etc/httpd/modules/mod_proxy.so into server: /etc/httpd/modules/mod_proxy.so: undefined symbol: ap_timeout_parameter_parse Manually restarting it brought apache back up without a complaint, but I can't see why it didn't work when logrotate tried to restart it. We experienced the same issue as well. [Sun May 24 05:09:15 2009] [notice] SIGHUP received. Attempting to restart httpd: Syntax error on line 199 of /etc/httpd/conf/httpd.conf: Cannot load /etc/httpd/modules/mod_proxy.so into server: /etc/httpd/modules/mod_proxy.so: undefined symbol: ap_timeout_parameter_parse Further, this is running x86_64 version, which may or may not be related. I have 3 other servers running FC10's apache, one running x86_64, two running i386, but they have not experienced this problem, only this one (which is the one that receives probably 90% of the traffic load) Versions of httpd in question: Linux version 2.6.27.21-170.2.56.fc10.x86_64 - httpd-2.2.11-2.fc10.x86_64 - this is the server that failed Linux version 2.6.27.23-78.2.50.fc9.i686 - httpd-2.2.11-2.fc10.i386 - running fine (this was updated to FC10 via yum, the fc10 kernel was older than the current fc9 kernel which is why it retained the fc9 kernel) Linux version 2.6.27.23-78.2.50.fc9.i586 - httpd-2.2.11-2.fc10.i386 - running fine (same comment about the kernel as above) Linux version 2.6.27.19-170.2.35.fc10.x86_64 - httpd-2.2.11-2.fc10.x86_64 - this is our x86_64 machine that is running fine. Looks like an update has cured it for me, not sure which one but the logrotate script was re-written on an update (I had commented out the HUP line) and these are the modules that were updated at that time: libX11-1.1.5-4.fc10.x86_64 netpbm-10.35.64-1.fc10.x86_64 policycoreutils-2.0.57-21.fc10.x86_64 perl-DBD-SQLite-1.23-1.fc10.x86_64 ipsec-tools-0.7.2-1.fc10.x86_64 3:ypbind-1.20.4-11.fc10.x86_64 selinux-policy-3.5.13-59.fc10.noarch selinux-policy-targeted-3.5.13-59.fc10.noarch xkeyboard-config-1.4-8.fc10.noarch squirrelmail-1.4.18-2.fc10.noarch libX11-1.1.5-4.fc10.i386 netpbm-10.35.64-1.fc10.i386 netpbm-progs-10.35.64-1.fc10.x86_64 libX11-devel-1.1.5-4.fc10.x86_64 libX11-devel-1.1.5-4.fc10.i386 *** This bug has been marked as a duplicate of bug 491567 *** |