500 - Внутренняя ошибка сервера, НЕ появляющаяся в error.log (или access.log)
Если Вы хотите совершенно другой набор полномочий для http://moss/depts/safety, чем Вы делаете для http://moss (и в этом отношении, http://moss/depts/finance), настраиваете их как наборы сайта с/depts, поскольку подстановочное включение настроило путь. Это позволит Вам сохранять навигацию в целости, но иметь совершенно другие полномочия (и администраторы набора сайта) для каждого сайта отдела.
РЕШЕННЫЙ: Увы, существует подсистема балансировки нагрузки, управляющая сервером, и подсистема балансировки нагрузки была настроена для остановки соединений после 10 секунд неактивности или около этого. Проблема решена теперь. Причина, которую эти 500 не разоблачили в error.log апача, состоит в том, что это была "внешняя" система (подсистема балансировки нагрузки) остановка соединения, не самого сервера. Спасибо всем за Ваши идеи и справку! Надо надеяться, кто-то еще найдет это просвещение однажды.
С наилучшими пожеланиями, римлянин.
Это могло быть проблемой с Вашей директивой Apache LogLevel, или она могла быть связана с обработкой ошибки периода выполнения PHP.
Это только покажет в апачском журнале ошибок, если ошибка будет повышена в рамках апачского кода - но необходимо все еще видеть его в журнале доступа (с кодом состояния 500), если состояние установлено в рамках кода PHP. Хотя могут быть экземпляры, где процессы PHP отказывают полностью (хотя они очень редки).
NB это может также произойти при соединении через прокси и винты прокси.
Эти 500 прибывают из другого хоста через что-то, встраивают документ? Возможно, у Вас есть свой CSS или некоторое такое прибытие из другого поля? Также попытайтесь добавить Директиву ErrorLog. Используйте Firebug или Chrome webdev инструменты для обнаружения, куда эти 500 прибывают из, могла даже быть реклама или что-то на странице.
Также попробуйте что-то как ЗАВИХРЕНИЕ или LWP для выполнения запроса, посмотрите, каковы заголовки ответа, например:
lwp-request -m HEAD -eSsd http://www.google.com/
HEAD http://www.google.com/ --> 200 OK
Cache-Control: private, max-age=0
Connection: close
Date: Tue, 19 Apr 2011 15:56:26 GMT
Server: gws
Content-Type: text/html; charset=ISO-8859-1
Expires: -1
Client-Date: Tue, 19 Apr 2011 15:56:26 GMT
Client-Peer: 74.125.91.99:80
Client-Response-Num: 1
Client-Transfer-Encoding: chunked
Set-Cookie:
REF=ID=b4ac3801dfbd939c:FF=0:TM=1303228586:LM=1303228586:S=nU_H2eC3zcLbTKfb;
expires=Thu,18-Apr-2013 15:56:26 GMT; path=/; domain=.google.com Set-Cookie:
NID=46=dsepCUy0iW9MDD7AkaP1-P4INDfRLTXz7l_TchQFzCGqtP4GU1EFbpn7K-sKq-ujNhpnR
Br8Cqgdyd3LyC3mxsRDOCCFoOn2OutZad7VWFs5erWVh0UNgEgkQJGqRe-; expires=Wed, 19-Oct-2011
15:56:26 GMT; path=/; domain=.google.com; HttpOnly
X-XSS-Protection: 1; mode=block
править: GF определил опечатку.
У меня была такая же проблема, и она была вызвана настройкой отчетов об ошибках в PHP. Хотя у меня была E_ERROR | E_WARNING | E_PARSE в моем .htaccess PHP не записывал фатальную ошибку PHP в журнал ошибок. Всего 500 в журнале доступа. Была сгенерирована даже половина страницы (пока я не вызвал функцию с этой ошибкой).
Другая возможность: ищите @ в своих исходных файлах.
Предупреждение
В настоящее время префикс оператора контроля ошибок «@» отключает даже отчеты об ошибках. для критических ошибок, которые завершат сценарий исполнение. Помимо прочего, это означает, что если вы используете "@" для подавлять ошибки определенной функции, и либо она недоступна или был напечатан с ошибкой, сценарий сразу же умрет без указание на то, почему.
Кредиты принадлежат Люку М. , который спас меня и многих пользователей CodeIgniter.
Для проектов Symfony не забудьте проверить app/logs
Вы можете найти более подробную информацию по этому вопросу :
https://stackoverflow.com/questions/18577003/how-to-debug-500-error-in-symfony-2
Btw, другие фреймворки или CMS могут иметь похожее поведение.
.