You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@httpd.apache.org by Christopher Schultz <ch...@christopherschultz.net> on 2014/10/05 16:01:41 UTC
[users@httpd] httpd 2.2 and 2.4; 500 errors with no logs at all
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
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.
Thanks in advance,
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJUMU9FAAoJEBzwKT+lPKRYCwoQAIJo8PuPGL7pWtFXeAUaZPjb
+kLOTi9BB2qmoDS0/ggnVt3CQo5cHE3SSwRn1wAMTsSzMLMedgW8TdO92jRZz3VR
CQogOeq91/0du9EsmoQIVEf2hevlW9AfLwYTtEPmYDQXU4Ucwc12e7L24a20crjF
PTrewtleyb183cbjqkH95xNBRmezadFsR18BTqHmK97wVrM2mmSJuh1C0L1NFVpD
xxyd4wlXXB3RXEu3bttD9vjgVoVtCcMHgv1q2N8Df77Nftls1/WnLm+mrzMAFhxl
zg81pTxflyz72b9leslwF8eo0/I2kwyMxXDDkdTFXgCl3dwz04MV/w+6LlnWt1D/
xo5j/LITLnuKD10KKGcQpolEABKcr8ObvOYnFIBXFxwsB+XoHFYooVm2AIaID+Wa
WFWlFKBMUdEypAgAm3lpsIluvf2EzF5m6eyYr7GqxN294Jo763H7AR7tY9h86tF9
cq4d1rpH+l0LYS1aA+qwLeKB6LXHYEZM6E5XIydxluz5CreJJ4sIrJMIeESXF4lm
Z5WQvTVGT6P9C7BvgbB+/RjMa4B5DHoXc/y2uVv2KAKpjbV0YP9HYEldRGx3RwyU
evYkbyGMeOb51eATuI4T61LbbAlVk1uuBJsOXY6+9JN3UTMSqwce4DOM1jo+r69G
k08PUIBgcCQWFWjOaE3t
=mQaP
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] httpd 2.2 and 2.4; 500 errors with no logs at all
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
-----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@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] httpd 2.2 and 2.4; 500 errors with no logs at all
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJUMVtXAAoJEBzwKT+lPKRY/o8QAJ9HXA+AE2nFZz5BVJWj6IRK
tyIudhUcK/SDDq3T6eELxqkaF8AlHuOGlN5ugbCfJ/+GkUBydD2fD2ofsVvIHpiP
q9La4yy029XmhvXmrX4+ncyRY9hKh7BJEak2inUZIOksnNlK9NF14PfnySoH+3jr
tkPdi+QMo30d5N25GcWsm8iIGaOuv9dXGz8p7v71TpSTN7PGSC+6mgZWrlSFu0aa
4QKehO/c2lidU5Eqhw1LsIVJ5wQ8SktX4TwNfqCvaXP3w0zjsIxsvrfPA6qQqM85
cBhGBmf3PLoIxFwu0So3PHr9uEbHvcD0MI6Hbst7mN7kHGypCiQCT+IrhvuGhYHN
3sOYWxJxGkBTyg5bpvlvaWX5jt8lfQP+T1ahFgvqTyn+b/77vAoksOXvN/AOvuuD
kAsmaKUtKshsTfEYCjUu8FzjKHxoM8EJt00EKaPAgTOcmlS1J1aLgmRSnclY5pLH
rxTjhxhW3gOcvVa3J/9ZDOt7K6fX5TI6fLXDG3XiPKa0Fug08SINlB26NB6iA9LX
dwGKDxEPpEyqAPdS9Aof1GfqmNr3NVv5sFJ2gJ2wj1Gy5009MLuM4pXktkRHBjPo
yOoQx+BRJfCAfV7Z7ErrNgFqUEsnqgrNMVFFL09zLJd6DPh/8VYKhAIqs6rmEP7s
oVAQ0S4vm0Mic8H/AmHc
=VAwN
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] httpd 2.2 and 2.4; 500 errors with no logs at all
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org