2010-12-02 4 views
22

J'ai un site Web en php qui fonctionne avec un serveur d'indexation solr, basé sur CodeIgniter.500 Erreur de serveur: fin prématurée des en-têtes de script:

Nous avons eu beaucoup de nouveaux contenus, donc nous avons vidé la base de données, et avons dû réindexer le contenu (environ 168 000 éléments). J'ai créé un script pour indexer le contenu par tranches de 500 - quand le script se termine, nous lançons l'indexation suivante.

Il fonctionne parfaitement sur mon environnement de test local, mais sur la production je reçois cette erreur 500:

[Thu Dec 02 ...] [error] [client IP] Premature end of script headers: index.php 

Il n'y a absolument rien dans mon php.log, juste le error_log apache qui retourne. Je l'ai vu arriver sur d'autres pages du site une ou deux fois, mais c'était pendant cette indexation.

Des idées?

+1

Il n'y a pas assez d'informations à dire. Si cela fonctionne sur votre environnement de test, je suspecterais des autorisations de fichiers: le serveur Apache fonctionne-t-il en tant qu'utilisateur différent peut-être? –

+0

Donc, laissez le script écrire dans les informations du journal après chaque ligne afin que vous sachiez où il se brise exactement. –

+0

Colin Fine: Je ne pense pas que ça vient de l'utilisateur, je cours php avec suphp, chaque serveur est compartimenté WhatIsOpenID: non ce n'est pas 500 erreurs différentes, il est Apache qui renvoie une erreur "500 erreur serveur interne" –

Répondre

0

Quel est votre niveau d'erreur dans PHP? Le message d'erreur que vous obtenez dans le journal est souvent le résultat d'une simple erreur PHP, mais le serveur est configuré pour ne pas envoyer de messages d'erreur au client pour des raisons de sécurité. De ce fait le message n'est pas très utile, ça pourrait être tout.

+0

Le niveau d'erreur est mis à display_errors sur et pour lancer toutes les erreurs, complément de cela, j'ai un système de journalisation qui fait une bagtrace de débogage complet sur tout erreur et le stocke dans la base de données. donc il n'y a rien de ce côté. –

24

Cette erreur est généralement (parfois) causée par la configuration FastCGI du FcgidIOTimeout directive (ancien nom: IPCCommTimeout).

C'est le nombre de secondes pour le délai d'attente IO, la valeur par défaut est de 40 secondes. Délai d'attente signifie que

"The FastCGI application must begin generating the response within this period of time. Increase this directive as necessary to handle applications which take a relatively long period of time to respond."

Vous pouvez essayer de le résoudre de mettre ceci dans votre vhost.conf:

<IfModule mod_fcgid.c> 
    # 5 minutes for IO timeout, default is 40 seconds 
    FcgidIOTimeout 300 
</IfModule> 

Vous pouvez augmenter comme vous avez besoin et puis restaurer la valeur initiale une fois que le processus est terminé réindexation .

+0

Je ne suis pas complètement familier avec la configuration apache et toutes ces choses. est suphp considéré comme fastCGI? Est-ce que les mêmes règles s'appliquent? Si oui, je vais essayer votre solution, car je pense que c'est aussi un problème de timeout –

+0

Je n'ai jamais utilisé suphp. Quoi qu'il en soit, vous pouvez essayer avec un simple script php qui dort plus de 100 secondes par exemple. Si vous obtenez la même erreur, vous pouvez essayer ma solution. –

4

Il y a une bonne liste des possibilités sur KB de Liquid Web;

  1. Upgrading or downgrading to a different version of PHP can leave residual options in the httpd.conf. Check the current version of PHP using php -v on the command line and search for any lines mentioning another version in the httpd.conf. If you find them, comment them out, distill the httpd.conf and restart apache.

  2. The RLimitCPU and RLimitMEM directives in the httpd.conf may also be responsible for the error if a script was killed due to a resource limit.

  3. A configuration problem in suEXEC, mod_perl, or another third party module can often interfere with the execution of scripts and cause the error. If these are the cause, additional information relating to specifics will be found in the apache error_log.

  4. If suphp’s log reaches 2GB in size or larger you may see the premature end of scripts headers error. See what the log contains and either gzip it or null it. Restart apache and then deal with any issues that the suphp log brought to light. The suphp log is located at: /usr/local/apache/logs/suphp_log

  5. The script’s permissions may also cause this error. CGI scripts can only access resources allowed for the User and Group specified in the httpd.conf. In this case, the error may simply be pointing out that an unauthorized user is attempting to access a script.

http://www.liquidweb.com/kb/apache-error-premature-end-of-script-headers/

Si je dans la même situation, je vérifie les autorisations d'abord, puis continuer avec 3 et 4.

-3

u oublié d'ajouter en-tête de type de contenu dans la réponse que est un must http entête lors de l'hébergement sur Apache2

header('Content-Type: text/html'); 
+0

false: exécutez ce script '' et vous obtiendrez une page blanche sans un tel message d'erreur. –

1

son peut aussi en raison de l'utilisation de PHP APC Extension dans le mauvais sens. donc d'abord retirer apc.so de php.ini redémarrer apache et le tester à nouveau :)

2

Je recevais également ce message d'erreur dans etc/httpd/logs/error_log après une erreur 500 Server interne en essayant de charger un site Web.

Pour moi, la solution était des autorisations - a dû chmod 755 le fichier. J'avais créé le fichier en tant qu'utilisateur de niveau d'accès supérieur à celui qui "chargeait" le site sur le serveur.

0

J'ai eu ce problème et après avoir lutté pendant plus de 5 heures, j'ai désactivé xcache et tout est revenu à la normale, l'erreur a disparu!

-5

J'ai eu le même problème, il suffit de redémarrer le serveur Apache et cela fonctionne

Questions connexes