"Internal Server Error" aléatoire

Bonsoir !

J’utilise Spip 1.9.2a et les squelettes Alternatives.

Depuis la migration, j’ai le message suivant qui apparaît de temps à autres :

 Internal Server Error

 The server encountered an internal error or misconfiguration and was unable to complete your request.

  Please contact the server administrator, "moi@monfournisseur.fr" and inform them of the time the 
  error occurred, and anything you might have done that may have caused the error.

 More information about this error may be available in the server error log.

Parfois, faire recharger la page dans le navigateur (Firefox ou IE7) suffit à la retrouver et ça peut même arriver dans l’espace privé.

J’aurais bien cherché dans le “server error log” mais je ne sais pas où on trouve ça ?

Si quelqu’un a une idée ? Merci

MD 8{>
http://md87.ouvaton.org

Bonsoir,

[quote=Marco87]Bonsoir !

J’utilise Spip 1.9.2a et les squelettes Alternatives.

Depuis la migration, j’ai le message suivant qui apparaît de temps à autres :

 Internal Server Error

 The server encountered an internal error or misconfiguration and was unable to complete your request.

  Please contact the server administrator, "moi@monfournisseur.fr" and inform them of the time the 
  error occurred, and anything you might have done that may have caused the error.

 More information about this error may be available in the server error log.

Parfois, faire recharger la page dans le navigateur (Firefox ou IE7) suffit à la retrouver et ça peut même arriver dans l’espace privé.

J’aurais bien cherché dans le “server error log” mais je ne sais pas où on trouve ça ?

Si quelqu’un a une idée ? Merci

MD 8{>
http://md87.ouvaton.org[/quote]

Les symptômes que tu décris… et que je viens de vérifier apparaissent chez quelques coopérateurs.
La réponse la plus souvent donnée est que le temps d’exécution du script est trop longue (donc trop lourde), plus de 30 secondes. Une deuxième réponse est que ce qui est chargé en mémoire pour l’exécution de ce même script est trop important (le maximum est de mémoire 16 Mo).
Là, à vue de nez, je pencherais pour la première hypothèse. Vois si tu peux optimiser un peu tout ça… (je sais, c’est plus facile à dire qu’à faire ;-()

Christian.

Bonsoir,

Bon spip est lourd mais devrait passer, ton système de squelette je ne sais pas (comme ça il ne parait pas trop gourmand…) mais en jetant à rapide coup d’oeil au code source de ta page d’accueil, j’ai vu que 2 fois est appelé le même script. Je ne sais pas ce qu’il fait mais bon, une fois serait peut-être suffisant :wink:

Si ça peut aider…

Christian.

Merci pour la piste !

Je vais essayer de comprendre. C’est un squelette en plugins et je n’en ai pas encore bien l’habitude !

MD 8{>
http://md87.ouvaton.org

Bonjour,

[quote=Marco87]Merci pour la piste !
Je vais essayer de comprendre. C’est un squelette en plugins et je n’en ai pas encore bien l’habitude !
MD 8{>
http://md87.ouvaton.org[/quote]

Il y a certainement des gains en terme de temps d’exécution à réaliser en scrutant un peu le comportement de ton système. Cependant, tu n’es pas le seul à être confronté à ce type de problème : voir ici --> http://webnews.ouvaton.coop/article.php?id=28680&group=tech.aide#28680

Christian.

Même chose en ce qui me concerne, également avec un squelette Alternative.

+A+

Salut,

Peux-tu me transmettre l’url de la page d’accueil de ce site ?

Christian.

Moi çà le fait à certaines connexions en page d’accueil de façon aléatoire
de même par exemple quand je rajoute un article au moment de l’ajout de l’auteur (?)
les statistiques spip sont accessibles une fois sur trois
et le plan sitemap pour google est inaccessible.

tout çà ce sont des choses qui ne se sont jamais produite sur ouvaton II même si à la moment donnée il y avait des lenteurs importantes

adresse du site : http://www.cgt-snet-provence.ouvaton.org/
spip 1.9.1

bon courrage dans vos recherches :slight_smile:

Joël

[quote=Christian Domec]Salut,

Peux-tu me transmettre l’url de la page d’accueil de ce site ?

Christian.[/quote]

http://indiscipline.fr/

Mais pour le moment, ça ne le fait plus. C’était surtout la semaine passée.

+A+

Bonsoir,

Tant mieux.

Cependant j’ai remarqué que ton site, ainsi que celui de Marco87, appelle deux fois cette adresse : http://le_site_en_question/spip.php?action=cron. Ce qui est tout à fait inutile (il doit faire en tâche de fond la même chose). Mais le site de Joël ne l’appelle qu’une fois et a aussi rencontré des problèmes.

Comme je n’y connais pas grand chose (mais que je suis un peu curieux), j’ai posé cette question sur tech.spip (-> http://webnews.ouvaton.coop/article.php?id=2756&group=tech.spip#2756 ) :


Bonjour,

Je n’utilise plus spip depuis des années.

Depuis la migration sur ouvaton 3 plusieurs coopérateurs se plaignent de l’apparition aléatoire d’“Internal Server Error” (voir sur tech.aide fil “problème toujours d’actualité” -> http://webnews.ouvaton.coop/article.php?id=28671&group=tech.aide#28671)) ou sur le forum -> http://forums.ouvaton.org/viewtopic.php?pid=859#p859

Sur le forum sur les trois sites évoqués, en regardant le source de la page d’accueil par le web de deux d’entre-eux, j’ai remarqué qu’un appel était fait à un fichier par l’adresse : http://nom_du_site/spip.php?action=cron (il était même appelé deux fois de suite (certainement une erreur de squelette) dans l’un d’entre eux.

Que fait ce spip.php lorsqu’on attribue à la variable action la valeur cron ???

Après une recherche assez rapide sur le web je n’ai pas trouvé de réponse à part ceci :

http://archives.rezo.net/spip-dev.mbox/200612.mbox/%3C20061207121734.GB18649@rezo.net%3E

Fil (développeur spip) y dit : “Si le spip.php dont ut parles correspond à http://www.xxxxxxxxxxxxxxxxx.com/spip.php?action=cron
alors c’est normal que ce soit lent voire très lent (c’est le cron), mais il n’est pas censé empêcher ta page de s’afficher”.

et cela : http://doc.spip.org/@cron où il est écrit :

"cron() exécution des tâches de fond :

  • lorsqu’il est appelé par public.php il n’est pas gourmand
  • lorsqu’il est appelé par spip.php?action=cron, il est gourmand"

Deux petites puces qui viennent rejoindre la première qui me grattait l’oreille.

Plus d’information là dessus ???

Christian.


A suivre,

Christian.

Merci Christian, je vais essayer d’en savoir plus également. Peut-être supprimer l’un des deux appels à cron et voir ce que ça donne.

+A+

autre phénomènes constatés

  • appel aux statistiques spip : page blanche affichée ou page sans le css
  • création d’un nouvel article une page blanche apparait aussi

Bonjour,

Je recopie ici ce que je viens de poster sur : http://webnews.ouvaton.coop/article.php?id=2758&group=tech.spip#2758


Christian Domec wrote:

http://nom_du_site/spip.php?action=cron (il était même appelé deux fois de suite (certainement une erreur de squelette) dans l'un d'entre eux.


Que fait ce spip.php lorsqu'on attribue à la variable action la valeur cron ???

Par curiosité, j’ai poussé ma recherche un peu plus loin. J’ai téléchargé le dernier spip qui à nu fait déjà près de 10 Mo !!! (près 20 fois plus qu’à son origine).

J’ai bien trouvé le fichier qui lance le cron : cron.php ce fichier va envoyer des tâches chaque fois qu’il sera appelé en fonction de paramètres temporels (je ne sais pas s’ils peuvent être modifié ailleurs que dans le script).

L’écran d’aide à ce sujet précise (http://doc.spip.org/@spip_cron) :


fonction spip_cron ( $taches = array() )
Autodoc :
Gestion des taches de fond
Deux difficultes :

  • la plupart des hebergeurs ne fournissent pas le Cron d’Unix
  • les scripts usuels standard sont limites a 30 secondes Solution : les scripts usuels les plus brefs, en plus de livrer la page demandee, s’achevent par un appel a la fonction spip_cron. Celle-ci prend dans la liste des taches a effectuer la plus prioritaire. Une seule tache est executee pour eviter la guillotine des 30 secondes. Une fonction executant une tache doit retourner un nombre :
  • nul, si la tache n’a pas a etre effecutee
  • positif, si la tache a ete effectuee
  • negatif, si la tache doit etre poursuivie ou recommencee Elle recoit en argument la date de la derniere execution de la tache. On peut appeler spip_cron avec d’autres taches (pour etendre Spip) specifiee par des fonctions respectant le protocole ci-dessus On peut modifier la frequence de chaque tache et leur ordre d’analyse en modifiant les variables ci-dessous.

Les taches sont dans un array (’nom de la tache’ => periodicite) Cette fonction execute la tache la plus urgente (celle dont la date de derniere execution + la periodicite est minimale) sous reserve que le serveur MySQL soit actif. La date de la derniere intervention est donnee par un fichier homonyme, de suffixe “.lock”, modifie a chaque intervention et des le debut de celle-ci afin qu’un processus concurrent ne la demarre pas aussi. Les taches les plus longues sont tronconnees, ce qui impose d’antidater le fichier de verrouillage (avec la valeur absolue du code de retour). La fonction executant la tache est un homonyme de prefixe “cron_” Le fichier homonyme de prefixe “inc_” est automatiquement charge si besoin, et est supposee la definir si ce n’est fait ici.


On voit ainsi qu’il peut parfois s’agir d’un script très gourmand.

Dans le fichier source j’ai regardé un peu les tâches et leur périodicité en secondes par défaut (je recopie ici une partie de cron.php décrivant la fonction taches_generales() et la fonction cron_optimiser()) :


Construction de la liste des taches.
// la cle est la tache, la valeur le temps minimal, en secondes, entre
// deux memes taches
// NE PAS METTRE UNE VALEUR INFERIEURE A 30 (cf ci-dessus)
//
// http://doc.spip.org/@taches_generales
function taches_generales() {
$taches_generales = array();

// MAJ des rubriques publiques (cas de la publication post-datee)
$taches_generales’rubriques’] = 3600;

// Optimisation de la base
$taches_generales’optimiser’] = 3600*48;

// cache
$taches_generales’invalideur’] = 3600;

// nouveautes
if ($GLOBALS’meta’]‘adresse_neuf’] AND $GLOBALS’meta’]‘jours_neuf’]
AND ($GLOBALS’meta’]‘quoi_de_neuf’] == ‘oui’))
$taches_generales’mail’]= 3600 * 24 * $GLOBALS’meta’]‘jours_neuf’];

// stats : toutes les 5 minutes on peut vider un panier de visites
if ($GLOBALS’meta’]“activer_statistiques”] == “oui”) {
$taches_generales’visites’] = 300; $taches_generales’popularites’] = 7200; # calcul lourd
}

// syndication
if ($GLOBALS’meta’]“activer_syndic”] == “oui”) $taches_generales’syndic’] = 90;

// indexation
if ($GLOBALS’meta’]“activer_moteur”] == “oui”) $taches_generales’indexation’] = 90;

// maintenance (ajax, verifications diverses)
$taches_generales’maintenance’] = 3600 * 2;

return pipeline(‘taches_generales_cron’,$taches_generales);
}

// Cas particulier : optimiser est dans base/optimiser, et pas dans inc/
// il faut donc definir la fonction _cron ici.
// http://doc.spip.org/@cron_optimiser
function cron_optimiser($t) {
include_spip(‘base/optimiser’);
optimiser_base();
return 1;
}

Sans aller plus avant dans les scripts de spip, je me rends compte qu’à première vue ils sont excessivement gourmands. Il n’est pas tout à fait étonnant que des “internal error” apparaissent (les commentaires du script sont d’ailleurs éloquants).

Christian.

En fait ce qui se passe c’est que lorsque le temps de téléchargement de fichiers lourds comme des stat de visites par exemple ou des plans sitemap google, le serveur coupe la connexion exemple de message obtenu avec konkeror ci-dessous.

Un problème s’est produit lors du chargement de http://www.cgt-snet-provence.ouvaton.org/ecrire/?exec=statistiques_visites :
La connexion avec l’hôte www.cgt-snet-provence.ouvaton.org a été coupée.

C’est un problème que nous n’avions pas auparavent soit parceque le débit était plus important soit que le temps de latence avant intéruption de la connexion était plus long

Bonsoir,

[quote=joelcapra]En fait ce qui se passe c’est que lorsque le temps de téléchargement de fichiers lourds comme des stat de visites par exemple ou des plans sitemap google, le serveur coupe la connexion exemple de message obtenu avec konkeror ci-dessous.

Un problème s’est produit lors du chargement de http://www.cgt-snet-provence.ouvaton.org/ecrire/?exec=statistiques_visites :
La connexion avec l’hôte www.cgt-snet-provence.ouvaton.org a été coupée.

C’est un problème que nous n’avions pas auparavent soit parceque le débit était plus important soit que le temps de latence avant intéruption de la connexion était plus long[/quote]

La situation s’est-elle améliorée ces derniers jours ?

Christian.

[quote=Christian Domec]Bonsoir,

La situation s’est-elle améliorée ces derniers jours ?

Christian.[/quote]

a priori non car j’ai trouvé le plan sitemap en erreur de téléchargement sur google et qu’il m’a fallu m’y prendre à 2 fois avant d’avoir mes stat

Bonsoir,

[quote=joelcapra]

[quote=Christian Domec]Bonsoir,
La situation s’est-elle améliorée ces derniers jours ?
Christian.[/quote]

a priori non car j’ai trouvé le plan sitemap en erreur de téléchargement sur google et qu’il m’a fallu m’y prendre à 2 fois avant d’avoir mes stat[/quote]

Ok ;-(

Bon, je ne suis tout à fait au parfum sur les réglages propres à ouvaton 3. Je sais qu’ils sont sensés répondre à un double soucis :

  • partager au mieux les ressources,
  • prévenir les gros plantages.
    Il y a donc une tolérance moins importante que sur ouvaton 2 concernant les scripts demandant beaucoup de ressources ou présentant un temps de réponse trop important.

Ceci dit, je pense que les réglages seront améliorés* lorsque la migration sera achevée (et ce n’est pas encore pour tout de suite).

En outre, et c’était le sens de ma question, Eiole a procédé à quelques corrections récemment (voir ici : http://forums.ouvaton.org/viewtopic.php?id=179))

Christian.

  • pour que cela se fasse dans les meilleures conditions il est important de noter tous les disfonctionnements pour débattre de leur résolution à ce moment.

[quote=Christian Domec]Bonsoir,

a priori non car j’ai trouvé le plan sitemap en erreur de téléchargement sur google et qu’il m’a fallu m’y prendre à 2 fois avant d’avoir mes stat
Ok ;-(

Bon, je ne suis tout à fait au parfum sur les réglages propres à ouvaton 3. Je sais qu’ils sont sensés répondre à un double soucis :

  • partager au mieux les ressources,
  • prévenir les gros plantages.
    Il y a donc une tolérance moins importante que sur ouvaton 2 concernant les scripts demandant beaucoup de ressources ou présentant un temps de réponse trop important.

Ceci dit, je pense que les réglages seront améliorés* lorsque la migration sera achevée (et ce n’est pas encore pour tout de suite).

En outre, et c’était le sens de ma question, Eiole a procédé à quelques corrections récemment (voir ici : http://forums.ouvaton.org/viewtopic.php?id=179))

Christian.

  • pour que cela se fasse dans les meilleures conditions il est important de noter tous les disfonctionnements pour débattre de leur résolution à ce moment.[/quote]

moi je veut bien mais un site qui marchait bien jusqu’à présent se retrouve avec des difficultées d’affichage des articles recherchés et la fréquentation est en chutte libre.

si les choses n’évoluent pas rapidement il va falloir que je trouve une solution. Je veux bien assumer, prendre quelques savons de mes camarades mais point trop n’en faut. :-((

Bonsoir,

[quote=joelcapra]moi je veut bien mais un site qui marchait bien jusqu’à présent se retrouve avec des difficultées d’affichage des articles recherchés et la fréquentation est en chutte libre.
si les choses n’évoluent pas rapidement il va falloir que je trouve une solution. Je veux bien assumer, prendre quelques savons de mes camarades mais point trop n’en faut. :-(([/quote]

Très franchement, je ne sais pas trop quoi en penser.

Il est vrai que ma réponse précédente est un peu molle : on attend la fin de la migration et on améliore…

Toutefois, ce que j’ai cru comprendre en lisant les messages des administrateurs de la coopérative et les divers échanges sur les listes, les news et les forums autour de cette migration c’est qu’une des raisons de la fragilité de la plate-forme que nous quittons est… sa trop grande souplesse !

Mis à part les erreurs de jeunesse de la nouvelle plate-forme, elle est construite à partir d’éléments plus rigides (un timeout plus rigoureux, des variables potentiellement mieux contrôles…) mais permettant mieux de faire cohabiter des milliers de comptes.

Je pense, un peu à l’aveugle j’en conviens, que mis à part quelques problèmes ergonomiques pour les coopérateurs (revoir des scripts, modifier des comptes, etc.) cette ossature est intéressante pour tous.
Maintenant, effectivement, il peu y avoir débat sur la position du curseur (ressources - tout compris - allouées à chacun et partagées par tous).

Je comprends qu’il soit très, très gênant qu’un site qui fonctionnait bien ne retrouve pas toute sa verdeur suite à la migration (s’il était unique… On pourrait scruter le phénomène. Mais il ne l’est pas). Cette gêne doit donc pouvoir s’exprimer pour adapter au mieux les contraintes d’un serveur mutualisé à la particularité des diverses demandes venant des coopérateurs qui la partage.

Je crois, mais ça n’engage que moi, que le temps de ce débat viendra lorsque la migration sera achevée (en aparté, si elle ne l’est pas c’est en grande partie dû à la frilosité ou même parfois l’absence… de nombreux coopérateurs).

En attendant, il faut bien constater que les moyens matériels et informatiques demandés pour mettre à la disposition de tous sur le web quelques centaines de pages sont souvent “démesurés” par rapport à ce qu’ils pouvaient être lorsque la coopérative fut créée. Et cette “démesure” est souvent complétée par quelques failles dans les scripts qui font la joie des spameurs.

Christian.

Ce qui me pose problème c’est que mon site n’a pas une si grosse fréquentation que çà . en mars la fréquentation moyenne a été de 319 (stat spip) visites par jour (avec des pointes à 600) et là on est tombé à 215 visites de moyenne depuis le début du mois et je me retrouve avec une bande passante saturée là ou çà passait sans problème avec 50 % de visites (stat spip) en plus ?

Je reste perplexe