-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 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. Thanks, - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUMVRnAAoJEBzwKT+lPKRY3QMQAIImsJ6IgR1nZGknWAemViSs Yl0E0nA4Yi1c2+Po/AJrMQyZhplpqZY0p7jToCuzYw2DzFfURuHKIdsphm1ZdbK1 6vmCslwb+ao0VpTRGnKsVaQDik7ZoIX5rF8MvXWZLOZmgnOATMu0eu17SVOJoVxZ hGCy2QAEoIBHBtuJoo2XdAWYlYzJkw5zI0Nkg1yNIhjXQioloZkMBHct/yljBg5q 3IwXbJWDMGhPEjpK2Rr6WZF1Ur4K35rUJre4ZAFwRY1Ej70CRDJachMXjW1Hjet8 to2BsY0Y8XJs7PbXACg7T0zqV5LoSpB8GDrD8t7gSjqJgHJ+l9mKR+DeCPSnNtR4 cRDcIxDaxz5DKvaUkXnfj3G33iSO0QiTyOZj4i26bb4N/Sx2v7IZ5t3vCEVTb13J wksQU9mFuzCx7vemw8G+HPTDitIPQc51gljEik6uxodJYuhLKWWGOEWcOMUbqSU6 LToJtyYMBNNQ1SIRzQzn/w7JuXuzAhbQWc1uZvKE8FY2mfyENOj1ppf8MXUCXHTB svw+jEqgAbgjA2yAX9WHqJCmbmUUMq75yuoS2n0R4kU8vf3YBZPigM/nJmjbz21o 6n5FdVq2Gt9KrSMd3T2sGjZ3ZDlOLO1/kE3j4Ibv9atT88HnGtADOA4O8ZsNJGw5 PCB/2dToPLU3psHGwvnn =DDRJ -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
