Fin prématurée des en-têtes de script: php5 Symfony génère une erreur de serveur interne 500

Je me heurte à un problème qui me laisse dans une impasse alors à mon tour, je me tourne vers vous! Récemment, une application Symfony est en train de se décomposer en affichant une erreur interne d'apache -500. Après la suppression du cache Symfony, le site revient. Après une enquête plus approfondie, j'ai trouvé l'erreur de "Fin prématurée des en-têtes de script: php5". Le site n'a généré aucune erreur de ce type depuis plus d'un an et nous n'avons apporté aucune modification à ce site et cela se produit régulièrement (une fois par semaine). Ce qui suit provient des fichiers journaux.Fin prématurée des en-têtes de script: php5 Symfony génère une erreur de serveur interne 500

[Sat Aug 28 06:20:30 2010] [error] [client 206.131.184.1] Premature end of script headers: php5

Cet e-mail a également été envoyé récemment par MT, peut-être en rapport avec ce problème.

Nous avons constaté que votre service ----.com générait un nombre anormalement élevé de verrous de système de fichiers sur le cluster hébergeant votre compte. Les sites Web ou les scripts qui utilisent le verrouillage de fichier NFS de manière incorrecte peuvent souvent générer cette erreur, ce qui affecte de façon démesurée les performances du cluster pour d'autres clients. Ceci est une violation de notre AUP qui peut être trouvé à 'http://mediatemple.net/company/legal/aup_general.php'.

Nous avons suivi le fichier problème de verrouillage dans le fichier suivant qui est verrouillé à plusieurs reprises:

/domains/----.com/symfony/cache/frontend/prod/config/routing/symfony.routing. configuration.cache /domains/----.com/symfony/cache/frontend/prod/config/routing/symfony.routing.data.cache

Nous vous recommandons de désactiver immédiatement le verrouillage de fichiers pour vos scripts si l'option est disponible (souvent situé dans la section de configuration du script); ou utilisez un script différent qui n'utilise pas le verrouillage de fichier. Tout abus de verrouillage futur de ce script peut entraîner la suspension du trafic vers ce domaine pour empêcher le verrouillage d'affecter d'autres clients.

Si vous avez des questions concernant ce problème de verrouillage de fichier ou si vous ne savez pas par où commencer en désactivant le verrouillage de fichier, veuillez répondre à ce ticket pour obtenir une assistance supplémentaire.

Source

2010-08-29 jeffreynolte

Récemment, j'ai rencontré un problème similaire. Le remplacement de la mise en cache des fichiers avec APC a complètement résolu mes problèmes. J'avais besoin de remplacer sfFileCache pour view_cache, le cache et le routage.

Si APC n'est pas disponible sur votre serveur, vous pouvez facilement utiliser n'importe quel autre accélérateur populaire.

Comment utiliser APC avec symfony: http://www.zalas.eu/symfony-meets-apc-alternative-php-cache

Source

2010-08-29 11:06:36

merci pour l'aperçu @kuba que je viens de mettre en œuvre et espère le meilleur. – jeffreynolte

N'oubliez pas d'écrire si cela a aidé ou non;) –

Après un certain temps, le site semble fonctionner très bien et cela a fait l'affaire. Merci un million !! Désolé pour le retard, je voulais m'assurer que le site était résolu. – jeffreynolte

Je pense qu'il est prudent de désactiver le verrouillage du cache de Symfony pour les lectures en lib/cache/sfFileCache.class.php dans la méthode read(). Symfony prend un verrou de partage lors de la lecture. Le verrou n'est pas nécessaire car Symfony utilise un fichier temporel et le renommer lors de l'écriture. En outre, dans lib/log/sfFileLogger.class.php la méthode de verrouillage dans doLog() n'est pas nécessaire, car l'écriture est atomique (appel unique fwrite()), et le fichier est ouvert en mode ajout.

Je n'ai pas testé comment ces changements affecteraient Symfony.

"Fin prématurée des en-têtes de script" n'est pas un message d'erreur PHP. Le serveur Web émet ce message lorsque le backend (PHP dans ce cas) n'envoie pas d'en-têtes. C'est très probablement parce qu'il meurt avant de pouvoir faire quoi que ce soit. Vous devriez localiser le journal des erreurs PHP et voir le vrai message d'erreur. Toutefois, notez que Symfony utilise beaucoup de @ pour la suppression des erreurs dans les appels de fonction afin que vous ne puissiez rien trouver.

Source

2010-08-29 08:27:26 jmz

Merci, j'espère que ceci à l'unisson avec l'information de @ kuba nous devrions aller bien. – jeffreynolte

jmz +1 pour votre aide sur ceci. J'ai corrigé cela et il n'y a plus de verrouillage de fichier, mais je ne pense pas que ce soit la cause du problème principal. Il a certainement aidé avec une partie secondaire du problème, mais le sfFileCache était le coupable. Merci encore! – jeffreynolte

Il se produit uniquement si vous naviguez avec Google Chrome et si une exception est levée. Là où quelques changements dans Monolog, ils ont permis "chromephp".

Dans votre config_dev.yml:

monolog: 
handlers: 
    main: 
     type: stream 
     path: %kernel.logs_dir%/%kernel.environment%.log 
     level: debug 
    firephp: 
     type: firephp 
     level: info 
    chromephp: 
     type: chromephp 
     level: info

Retirez le bloc entier de chromephp et everythings bien.

Source

2013-06-20 09:04:32 mYkon

Vous avez ouvert un problème: https://github.com/Seldaek/monolog/issues/206 – mYkon

Cette réponse n'est pas associée à cette question. Ceci est une question symfony, pas monologue - envisager de le réviser. – Raise

Réponse non associée à cette question? Connaissez-vous Symfony? Monolog est un bundle par défaut qui vient avec symfony, donc bien sûr, il est lié! – mYkon

Fin prématurée des en-têtes de script: php5 Symfony génère une erreur de serveur interne 500

Répondre

Questions connexes