-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 All, Bump. Any ideas what might be causing this? Thanks, - -chris On 10/5/14 10:53 AM, Christopher Schultz wrote: > All, > > On 10/5/14 10:23 AM, Christopher Schultz wrote: >> All, > >> On 10/5/14 10:01 AM, Christopher Schultz wrote: >>> All, > >>> Over the past week, I've had 4 separate httpd servers running >>> 2.2 and 2.4 start failing with the generic "Internal Server >>> Error" page and a 500 response. > >>> The only logs generated are the access log, which of course >>> indicates a 500-response. So, no error logs, no syslogs, no >>> nothing. > >>> We have a couple of redirects configured using something like >>> "RedirectMatch 301 "^/$" https://hostname/"; and these are >>> processed and I get a 302 response which redirects to another >>> page that fails. > >>> All of the pages that are failing are using HTTP Basic >>> authentication with an LDAPS authentication module >>> (mod_authz_ldap) to a remote server. Other httpd instances are >>> currently successfully authenticating against this LDAP server, >>> so the LDAP server itself doesn't appear to be a problem. > >>> In the other cases, an httpd restart has fixed the problem. >>> Triggering a config reload (/etc/init.d/httpd reload on my >>> RHEL-compatible VM) will allow the configuration to reload and >>> does not change the situation with the errors (i.e. the errors >>> still occur). > >>> I was able to reconfigure the VirtualHost to /not/ require >>> LDAP authentication and then I was able to access my pages as >>> expected. So, I'm fairly sure that the problem is with the >>> LDAP authentication module. > >>> I now have another case that is failing and I have the >>> opportunity to inspect it in its failing state. Can you anyone >>> suggest a way to instrument the still-running, still-failing >>> httpd instance to figure out what the problem is? > >>> This particular server has the following configuration as >>> reported by apachtctl -V: > >>> Server version: Apache/2.2.29 (Unix) Server built: Sep 15 >>> 2014 19:41:45 Server's Module Magic Number: 20051115:36 Server >>> loaded: APR 1.5.0, APR-Util 1.4.1 Compiled using: APR 1.5.0, >>> APR-Util 1.4.1 Architecture: 32-bit Server MPM: Prefork >>> threaded: no forked: yes (variable process count) > >>> Looking at a process list, I can see 8 processes. If I go to >>> my browser and mash the RELOAD button, the browser reports a >>> 500 response each time, and when I go back and check the >>> process list, all the pids are the same, so the child processes >>> are not crashing and failing to log errors before the die or >>> anything like that. > >> I might have a lead on this ... the TLS certificate used by the >> LDAP server has expired. But, I have some httpd servers that are >> happily using it for authentication (likely due to the server >> restart of each one I've had to do). > >> Any idea how I might be able to test this hypothesis? I'd prefer >> to nail this down and call the problem solved (by issuing a new >> certificate) rather than mask the real error if there is another >> one. > > I updated the TLS certificate being used for the LDAP server and it > appears to have had no effect on whats going on: I'm still getting > 500 errors with no details in any logs. :( > > Any suggestions? > > -chris > > --------------------------------------------------------------------- > > To > unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx > For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUNtEuAAoJEBzwKT+lPKRYGiMP/1yLrWa+0JNQviwXwisRJwrC hcdN2YfLdjOodV5wl7T2wduxKwcK31fEA5DVmArufORibGfYfM7gWV/7xApr0jQx XYVG2wUjBJdWwanwEYADeArxRdswtXuppVONHpzBYgO+FNhObU1tG1n1NltuLwjP CCZpkj5ULVqaz+ZYB+lbNHuHmRhfFt7+2NTKviEb/huO3DpYLhLyXoSc6EQrBTh4 5IzwyAUBF2tVrZF7Z4QQATn4MqO4MxFJXawLxI+/EZlXKtETs+EW8Qe1k3xPPXJO yNJb3qOjlQOuAoy59fw1t4njHcflqVZKcvtdUHXAB4VGdUUB3rL93gTr+1RMenjy y1m0RN6spSY2AZ9ABeB2d3tapiywEHyIitaqoiTgE5hGVvEv+UohkFTH/Ym/VHMB bEQGT+ifEMhwtdM91DvdAzrYuPr/+d3jxcFpqLL5i6aSMUwbbgHNA8m8r3rivb9F bAMUFAoJnZtoQD5e1EPEqcD4haTxC43b/Z/Q9w5Yp9jFeL28vtRXBPVxvehCkh6q BWfqYrTVb/sx2VZiGaGrRIOqbSz4C8K2zxL82TktRQraG4H05jloFgAY2fR9mMqe v7L38Hq+5Bim5qDLTkH25tWLup7tG53vMWg0UVH29c6CWIEscAnZuPqs5MUAoZKS ldIDlMDqYq1x44Byf3mc =myfR -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|