DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=39744>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=39744 ------- Additional Comments From [EMAIL PROTECTED] 2006-06-19 15:10 ------- (In reply to comment #1) > Segfaults at restart can happen because of global state abuse in OpenSSL. > Is your httpd binary linked against both libssl and libcrypto? You are not > linking php into the httpd process at all, that's correct? I think I may have figured out what's happening, although it's something that *should* be reproducable. Sifting through my logs, I found a series of strange HTTPS requests coming from what Apache believes is the same IP as the SSL-based vhost itself (FYI, I run NOTHING that can cause this to happen, so it's very strange indeed). The timestamps of the requests match up with when I rotate my logs (more on that in a moment). Be sure to note the HTTP response, and the actual HTTP fetch itself (lack-of HTTP/1.0 or HTTP/1.1 for example): >From the error log: [Mon Jun 19 00:00:01 2006] [notice] Graceful restart requested, doing restart >From the access log: support.parodius.com 64.62.145.231 - - [19/Jun/2006:00:00:01 -0700] "GET /" 400 1018 "-" "-" support.parodius.com 64.62.145.231 - - [19/Jun/2006:00:00:01 -0700] "GET /" 400 1018 "-" "-" support.parodius.com 64.62.145.231 - - [19/Jun/2006:00:00:01 -0700] "GET /" 400 1018 "-" "-" support.parodius.com 64.62.145.231 - - [19/Jun/2006:00:00:01 -0700] "GET /" 400 1018 "-" "-" support.parodius.com 64.62.145.231 - - [19/Jun/2006:00:00:01 -0700] "GET /" 400 1018 "-" "-" support.parodius.com 64.62.145.231 - - [19/Jun/2006:00:00:01 -0700] "GET /" 400 1018 "-" "-" support.parodius.com 64.62.145.231 - - [19/Jun/2006:00:00:01 -0700] "GET /" 400 1018 "-" "-" support.parodius.com 64.62.145.231 - - [19/Jun/2006:00:00:01 -0700] "GET /" 400 1018 "-" "-" support.parodius.com 64.62.145.231 - - [19/Jun/2006:00:00:01 -0700] "GET /" 400 1018 "-" "-" support.parodius.com 64.62.145.231 - - [19/Jun/2006:00:00:01 -0700] "GET /" 400 1018 "-" "-" support.parodius.com 64.62.145.231 - - [19/Jun/2006:00:00:01 -0700] "GET /" 400 1018 "-" "-" support.parodius.com 64.62.145.231 - - [19/Jun/2006:00:00:01 -0700] "GET /" 400 1018 "-" "-" support.parodius.com 64.62.145.231 - - [19/Jun/2006:00:00:02 -0700] "GET /" 400 1018 "-" "-" support.parodius.com 64.62.145.231 - - [19/Jun/2006:00:00:02 -0700] "GET /" 400 1018 "-" "-" support.parodius.com 64.62.145.231 - - [19/Jun/2006:00:00:02 -0700] "GET /" 400 1018 "-" "-" support.parodius.com 64.62.145.231 - - [19/Jun/2006:00:00:02 -0700] "GET /" 400 1018 "-" "-" support.parodius.com 64.62.145.231 - - [19/Jun/2006:00:00:02 -0700] "GET /" 400 1018 "-" "-" support.parodius.com 64.62.145.231 - - [19/Jun/2006:00:00:02 -0700] "GET /" 400 1018 "-" "-" support.parodius.com 64.62.145.231 - - [19/Jun/2006:00:00:02 -0700] "GET /" 400 1018 "-" "-" support.parodius.com 64.62.145.231 - - [19/Jun/2006:00:00:02 -0700] "GET /" 400 1018 "-" "-" support.parodius.com 64.62.145.231 - - [19/Jun/2006:00:00:02 -0700] "GET /" 400 1018 "-" "-" support.parodius.com 64.62.145.231 - - [19/Jun/2006:00:00:02 -0700] "GET /" 400 1018 "-" "-" support.parodius.com 64.62.145.231 - - [19/Jun/2006:00:00:02 -0700] "GET /" 400 1018 "-" "-" support.parodius.com 64.62.145.231 - - [19/Jun/2006:00:00:02 -0700] "GET /" 400 1018 "-" "-" I still can't explain the above. It looks suspicious, and to be honest it looks like some sort-of weird bug in Apache (?!). I assure you -- there is NOTHING running at that time which queries https://support.parodius.com/. It's been worrying me that sending two SIGUSR1s to httpd in very short succession might cause the problem (look closely at newsyslog.conf). However, my Apache logs only show one SIGUSR1 being received by Apache (no idea if that's true or not, I'd have to truss or ktrace the process to see). So I've since changed my newsyslog to do the following: /var/log/httpd-*.log 640 13 * @T00 GB /var/run/httpd.pid 30 Which is to send one single SIGUSR1 to Apache then rotate the logs. Now, about which libraries are linked in -- yes, that is correct. PHP is NOT the problem here, it's run purely as a CGI. We do use the SUPHP module, but it acts basically as suexec (calling PHP as a CGI). $ ldd /usr/local/sbin/httpd /usr/local/sbin/httpd: libm.so.2 => /usr/lib/libm.so.2 (0x280c1000) libaprutil-1.so.2 => /usr/local/lib/libaprutil-1.so.2 (0x280dc000) libexpat.so.6 => /usr/local/lib/libexpat.so.6 (0x280f8000) libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x28115000) libapr-1.so.2 => /usr/local/lib/libapr-1.so.2 (0x28202000) libcrypt.so.2 => /usr/lib/libcrypt.so.2 (0x2822e000) libc.so.4 => /usr/lib/libc.so.4 (0x28247000) And just for details, loaded modules we have: LoadModule authn_file_module libexec/apache22/mod_authn_file.so LoadModule authn_dbm_module libexec/apache22/mod_authn_dbm.so LoadModule authn_anon_module libexec/apache22/mod_authn_anon.so LoadModule authn_default_module libexec/apache22/mod_authn_default.so LoadModule authz_host_module libexec/apache22/mod_authz_host.so LoadModule authz_groupfile_module libexec/apache22/mod_authz_groupfile.so LoadModule authz_user_module libexec/apache22/mod_authz_user.so LoadModule authz_dbm_module libexec/apache22/mod_authz_dbm.so LoadModule authz_owner_module libexec/apache22/mod_authz_owner.so LoadModule authz_default_module libexec/apache22/mod_authz_default.so LoadModule auth_basic_module libexec/apache22/mod_auth_basic.so #LoadModule auth_digest_module libexec/apache22/mod_auth_digest.so #LoadModule file_cache_module libexec/apache22/mod_file_cache.so #LoadModule cache_module libexec/apache22/mod_cache.so #LoadModule disk_cache_module libexec/apache22/mod_disk_cache.so LoadModule include_module libexec/apache22/mod_include.so LoadModule filter_module libexec/apache22/mod_filter.so LoadModule charset_lite_module libexec/apache22/mod_charset_lite.so LoadModule deflate_module libexec/apache22/mod_deflate.so LoadModule log_config_module libexec/apache22/mod_log_config.so LoadModule logio_module libexec/apache22/mod_logio.so LoadModule env_module libexec/apache22/mod_env.so LoadModule mime_magic_module libexec/apache22/mod_mime_magic.so #LoadModule cern_meta_module libexec/apache22/mod_cern_meta.so LoadModule expires_module libexec/apache22/mod_expires.so LoadModule headers_module libexec/apache22/mod_headers.so LoadModule usertrack_module libexec/apache22/mod_usertrack.so LoadModule unique_id_module libexec/apache22/mod_unique_id.so LoadModule setenvif_module libexec/apache22/mod_setenvif.so LoadModule version_module libexec/apache22/mod_version.so LoadModule ssl_module libexec/apache22/mod_ssl.so LoadModule mime_module libexec/apache22/mod_mime.so #LoadModule dav_module libexec/apache22/mod_dav.so #LoadModule status_module libexec/apache22/mod_status.so LoadModule autoindex_module libexec/apache22/mod_autoindex.so #LoadModule asis_module libexec/apache22/mod_asis.so #LoadModule info_module libexec/apache22/mod_info.so LoadModule cgi_module libexec/apache22/mod_cgi.so #LoadModule dav_fs_module libexec/apache22/mod_dav_fs.so LoadModule vhost_alias_module libexec/apache22/mod_vhost_alias.so LoadModule negotiation_module libexec/apache22/mod_negotiation.so LoadModule dir_module libexec/apache22/mod_dir.so #LoadModule imagemap_module libexec/apache22/mod_imagemap.so LoadModule actions_module libexec/apache22/mod_actions.so #LoadModule speling_module libexec/apache22/mod_speling.so LoadModule userdir_module libexec/apache22/mod_userdir.so LoadModule alias_module libexec/apache22/mod_alias.so LoadModule rewrite_module libexec/apache22/mod_rewrite.so LoadModule suphp_module libexec/apache22/mod_suphp.so LoadModule bw_module libexec/apache22/mod_bw.so We also use mmap and sendfile: EnableMMAP on EnableSendfile on -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
