Jump to content

Timeout:La requête a dépassé le temps d"exécution maximum autorisé

Ann
 Share

Recommended Posts

Ann Newbie

Ann

Posted
Posted

Bonjour à tous

 

Un petit souci technique. J'ai voulu faire la dernière mise à jour en 1.5.4 stable et làdamned

pas moyen toujours le même message d'erreur.

 

[server Error] Timeout:La requête a dépassé le temps d"exécution maximum autorisé. Vous devez changer votre configuration serveur pour augmenter la durée de max_execution_time.

 

J'ai donc du restaurer sur la dernière version que j'avais sauvegardée et maintenant je suis en 1.5.3.1

 

Est ce la faute de mon serveur ? ( je suis chez OVH ) Si oui comment faire ?

Et si c'est pas ça où est le bug ?

 

Merci d'avance

Link to comment
Share on other sites
Ann Newbie

Ann

Posted
  • Author
Posted

Bonjour à tous ( et toute mes excuses aux modérateurs pour mon erreur de destination de post )

 

Un petit souci technique. J'ai voulu faire la dernière mise à jour en 1.5.4 stable et là damned

pas moyen toujours le même message d'erreur.

 

[server Error] Timeout:La requête a dépassé le temps d"exécution maximum autorisé. Vous devez changer votre configuration serveur pour augmenter la durée de max_execution_time.

 

J'ai donc dû restaurer sur la dernière version que j'avais sauvegardée et maintenant je suis en 1.5.3.1

 

La dernière mise à jour c'était faite sans souci.

 

Est ce la faute de mon serveur ? ( je suis chez OVH ) Si oui comment faire ?

Et si c'est pas ça où est le bug ?

 

Merci d'avance

Link to comment
Share on other sites
Ann Newbie

Ann

Posted
  • Author
Posted

Merci pour la réponse. Je vais retenter à différentes heures... :) Et si cela ne fonctionne pas et bien il ne restera qu'à recommencer tout depuis le début avec la nouvelle version... ( car depuis le retour à l'ancienne version c'est plein de bugs sur le site...) <_<

Link to comment
Share on other sites
Gregory Roussac Newbie

Gregory Roussac

Posted
Posted

Bonjour Ann,

 

Il est de combien le max_execution_time ? 30 secondes ?

 

Dans le module d'auto upgrade et en passant le mod_dev à on dans /config/defines.inc.php, tu as le mode dit "pas à pas" qui te permettra d’exécuter les différentes étapes et/ou de les forcer à se re exécuter, notamment l’étape UpgradeDb qui en fonction des bases peut prendre du temps.

 

Cordialement

Link to comment
Share on other sites
  • 2 months later...
  • 3 weeks later...
Gregory Roussac Newbie

Gregory Roussac

Posted
Posted

Bonjour,

 

En local cela va être un peu dur de vous aider, il faut regarder les logs d'Apache et mysql. Si vous l’hébergez en ligne, je pourrais plus vous aider pour cette erreur.

 

En local vous pouvez augmenter le max_execution time vous memem dans le php.ini par ce que des etapes de la mise à jour prennent plus de 30 secondes en fonction des shops.

 

Cordialement

Link to comment
Share on other sites
  • 2 weeks later...
kouik-e Newbie

kouik-e

Posted
Posted

Bonjour Ann,

 

Il est de combien le max_execution_time ? 30 secondes ?

 

Dans le module d'auto upgrade et en passant le mod_dev à on dans /config/defines.inc.php, tu as le mode dit "pas à pas" qui te permettra d’exécuter les différentes étapes et/ou de les forcer à se re exécuter, notamment l’étape UpgradeDb qui en fonction des bases peut prendre du temps.

 

Cordialement

 

Bonjour,

le problème c'est que lors de la mise à jour vers 1.5.5.0, la variable est remise à FALSE, donc pas de "pas à pas"

Link to comment
Share on other sites
Gregory Roussac Newbie

Gregory Roussac

Posted
Posted

Bonjour,

 

Il y a une confusion.

 

Vous souhaitez le mode pas à pas, vous passez cette variable avant la mise à jour. La page du module s'affichera différemment à son chargement. Il n'y a pas à le faire pendant la mise à jour, je ne comprends pas du tout ou vous voulez en venir. Ensuite cette variable est remise à off par le module. Si vous souhaitez le remettre à on après mise à jour c'est possible, mais il n'y a aucune raison de le faire pendant, il y a un souci avec ce que vous cherchez à faire.

 

Cordialement

Link to comment
Share on other sites
Gregory Roussac Newbie

Gregory Roussac

Posted
Posted

@kouik-e, vous avez un max_execution_time trop bas ? Il est possible de faire faire au module des boucles moins longues voir ici http://www.prestashop.com/forums/topic/183803-prestashop-149-disponible/?view=findpost&p=912841 sinon vous me faites un accès temporaire à votre FTP et Back office par mail et je regarde cela.

 

Cordialement

Link to comment
Share on other sites
kouik-e Newbie

kouik-e

Posted
Posted

oui justement j'ai passé la variable à ON avant de lancer la mise à jour mais je n'ai pas d'option spéciale, je ne vois pas de changement. Quand je lance la MAJ elle va jusqu'au bout sans me proposer de confirmation. Et à la fin j'ai toujours un Timeout.

Link to comment
Share on other sites
kouik-e Newbie

kouik-e

Posted
Posted

jusqu'ici (voir pièce jointe) tout va bien, c'est ensuite que ça ne fonctionne plus.

 

Au bout de 20 mn ça met une erreur TimeOut et si je clique de nouveau sur upgradeDb, ça veut restauré à la version 1.4.x, je ne peux rien faire d'autre que fermer la fenêtre

post-372287-0-93492800-1379190744_thumb.png

Link to comment
Share on other sites
Gregory Roussac Newbie

Gregory Roussac

Posted
Posted

Bonjour,

 

Je n'arrive pas à me connecter à votre ftp. Il faudrait essayer de choisir le canal "dossier local" après avoir uploader le contenu du dossier /install-dev/ dans /admin/autoupgrade/latest/prestashop/install/ de cette archive https://github.com/PrestaShop/PrestaShop/archive/development.zip car je pense qu'une boucle sur la mise à jour des messages a été corrigée depuis.

 

Cordialement

Link to comment
Share on other sites
kouik-e Newbie

kouik-e

Posted
Posted

Bonsoir, oui mais la maj des modules n'est pas faite et l'étape upgradeDb n'est pas complète, l'admin est à moitié en Anglais, j'ai vraiment le sentiment que la maj n'est pas terminée.

Je n'oserais jamais faire une telle mise à jour sur mon site de prod.

Quand je fais la maj 1.4.9.0 vers 1.4.11, tout se déroule parfaitement, alors que là, ce n'est pas le cas

Link to comment
Share on other sites
Gregory Roussac Newbie

Gregory Roussac

Posted
Posted

Les traductions peuvent se mettre a jour dans la partie localisation. Les modules se mettent a jour dans l'onglet modules.

 

On peut forcer encore une fois la mise à jour, en appelant /install-dev/upgrade/upgrade.php mais il faut changer la version dans /config/settings.inc.php mais le changement est refusé par ftp.

 

Cordialement

Link to comment
Share on other sites
  • 1 year later...
mattheoh Newbie

mattheoh

Posted
Posted (edited)

Bonjour, à tous, je reprends le fil car j ai un problème similaire.

J essaye désespérément de faire une migration de 1.4.11 => 1.6.11.0 via le module autoupgrade.

J ai essayé en mode normal ou pas à pas, et  chaque fois j ai un timeout / max_execution_time.

En pas à pas, si je relance update de la database, au bout de 3 ou 4 relances, erreur json et on me demande de restaurer.

j ai également modifié les fichiers du modules comme indiqué ici https://www.prestashop.com/forums/topic/183803-prestashop-149-disponible/page-3?do=findComment&comment=912841, mais idem.

je suis sur un serveur dédié, et j ai mis un max_execution_time de 300000 ! (histoire d'etre tranquille)

 

A la limite je voudrais bien faire une mise à jour manuelle , mais je n'y parviens pas (il me propose une install et pas une upgrade malgré que je garde bien fichier settings.inc.php avec les infos de la 1.4)

 

Si quelqu'un a une idée car là je sèche ! merci :-)

Edited by mattheoh (see edit history)
Link to comment
Share on other sites
Gregory Roussac Newbie

Gregory Roussac

Posted
Posted

Bonjour,

 

Eventuellement regardez ce qu'il ya dans le json avec Firebug ou la console de Chrome ? ou sinon regardez les logs d'erreur Apache au moment de ce retour d'erreur ?

 

Le timeout vient plutot de mysql que de php si c'est pendant la mise à jour de la base. Vous avez regardé les logs de mysql ? A combien est le max_allowed_packet pour mysql ?

 

Cordialement

Link to comment
Share on other sites
mattheoh Newbie

mattheoh

Posted
Posted

Bonjour Gregory, merci de cette réponse rapide !

Le problème vient en effet surement de MySQL car ma base est assez lourde (600 mégas que je réduis à 300 avant migration en vidant plusieurs tables de stats)

Les logs MySQL ne sont malheureusement pas actif (je peux les activer si besoin)

et pour le max_allowed_packet = 16M - dois je l'augmenter ?

 

Je ne comprends pas pourquoi la mise à jour manuelle n'est pas possible (j en ai fait une de 1.4.5 à 1.4.1, et c'est passé comme une lettre à la Poste !)

 

Merci de votre aide.

Link to comment
Share on other sites
Gregory Roussac Newbie

Gregory Roussac

Posted
Posted

Re,

 

Ma foi vous pouvez essayer de le doubler mais savoir la vraie erreur serait mieux. Et normalement on doit pouvoir trouver dans les logs Apache ou mysql pourquoi il s'arette. Souvent un laconique "mysql has gone away".

 

Une mise a jour manuelle est possible mais non conseillée. Par contre le système a changé de 1.4 à 1.5, il faut apeller directement un fichier /install/upgrade/upgrade.php
. http://doc.prestashop.com/pages/viewpage.action?pageId=11272350 mais encore une fois le module ne fait que faire la mise à jour manuelle pour vous dans une des ces etapes.

 

Cordialement

  • Like 1
Link to comment
Share on other sites
mattheoh Newbie

mattheoh

Posted
Posted

OK, je vais suivre vos conseils et insister avec cette mise à jour automatique.

je viens de relancer le process, et j ai obtenu un max_execution-time au bout de plusieurs dizaines de minutes sur le process de mise à jour de la base.

j'avais au préalable agmenté à 64 M max_allowed_packet et key_buffer.

 

je vois rien de spécial dans les logs (mysql.log ou mysql-slow.log). 

pas de mysql has gone away" non plus dans les logs apache.

 

Vous avez un fichier log précis à m'indiquer dans lequel je dois regarder ? (l OS est une debian)

 

vu que j'avais mis le mode pas à pas, je viens de relancer la mise à jour de la base... let's wait !

Link to comment
Share on other sites
mattheoh Newbie

mattheoh

Posted
Posted (edited)

Re,

 

Mettez le mode_dev à true dans /config/defines.inc.php, activez les erreurs en dessous du mode pas à pas.

 

Ensuite il faudrait regarder ce qui est dans le json renvoyé à l'erreur avec la console de chrome ou firebug. http://www.morefnu.org/post/2010/08/30/D%C3%A9bugger-de-l-Ajax-avec-firebug

 

Cordialement

Bon ça a planté à la 3eme relance de upgradeDB. (voir capture)

je refais le process avec les erreurs php activés sur le module.

je vais le faire depuis Firefox avec Firebug, car j ai pas grand chose dans la console Chrome. 

 

l0xaoMP.png

Edited by mattheoh (see edit history)
Link to comment
Share on other sites
Gregory Roussac Newbie

Gregory Roussac

Posted
Posted (edited)

Si si c'est bien ça. Il a depassé le temps de connexion a votre back office, il dit que le token est epuisé.

 

Essayez de cocher la case qui maintient la connexion au login back office, ou bien d'etendre le temps de connexion dans les preferences ? Je ne me souviens plus si cela existait en 1.4. C'est possible que https://github.com/PrestaShop/autoupgrade/blob/master/AdminSelfUpgrade.php#L310-L317 soit un peu foireux...Je vais verifier dès que possible.

 

Vous pouvez mettre un return true; en haut de cette fonction pour qu'il arette de s'aretter, probablement au renouvellement du token.

 

Sinon remplacez cette ligne https://github.com/PrestaShop/autoupgrade/blob/master/ajax-upgradetab.php#L82 dans le module par if (1 == 1).

 

Cordialement

Edited by Gregory Roussac (see edit history)
Link to comment
Share on other sites
mattheoh Newbie

mattheoh

Posted
Posted

En fait ça me délogguait suite à une inactivité si je comprends bien (j y avais pensé hier dans un moment de désespoir mais je n'aurais jamais su le corriger)

Pas trouvé l'option dans le back office (je crois pas qu'elle y soit en 1.4) donc j ai modifié la ligne dans le fichier ajax-upgradetab.php du module.

je viens de relancer une migration pas à pas avec affichage des erreurs php (en espérant que ça ne bloque pas une requête ajax comme c'est précisé)

verdict dans quelques dizaines de minutes.

merci encore pour votre aide ! super appréciable ce support.

Link to comment
Share on other sites
mattheoh Newbie

mattheoh

Posted
Posted

Parfait c'est passé ! même pas eu à relancer upgradeDB

un grand merci.

 

j ai juste eu une erreur :

SQL 1.5.0.1 1146 in ALTER TABLE `ps_cart_discount` CHANGE `id_discount` `id_cart_rule` int(10) unsigned NOT NULL: Table 'c0cravate16011.ps_cart_discount' doesn't existErreur(s) détectée(s) pendant la mise à jour.

mais tout le reste a l'air OK.

Encore merci.

 

PS : ce serait peut être bien de modifier le module autoupgrade avec la ligne qui concerne le token. Parce que je suppose que je suis pas le seul à avoir une base de plusieurs centaines de mégas et donc un upgrade qui dépasse le temps de connexion.

Link to comment
Share on other sites
  • 2 weeks later...
  • 1 month later...
mattheoh Newbie

mattheoh

Posted
Posted (edited)

Bonjour,

 

Je me permets de relancer ce post, car j'ai un nouveau un souci d'upgrade.

Nos différents échanges avec Grégory (que je remercie encore) m'ont permis de migrer vers la 1.6.0.11 dans un environnement de développement.

J'ai pu grâce à cela mettre à jour mon thème qui n'était pas du tout compatible 1.6.

Aujourd'hui je me prépare cette semaine à migrer la boutique de prod et fais donc des derniers essais avec la 1.6.0.14.

 

je fais donc quelques tests en local  sous Wamp pour des questions de praticité (mais le résultat est identique sur un serveur dédié).

Et il m'est impossible de migrer de la 1.4.11 vers la 1.6.0.14 avec le module autoupgrade.

- J'ai mis à fond les paramètres php et mysql pour éviter un max_execution_time (max_execution_time, max_alloweb_packet, key_buffer_size...)

- J'ai vidé mes tables de stats qui prenaient de la place.

- J'ai baissé les paramètres du module autoupgrade (max_written_allowed notamment)

et toujours le même résultat, au moment de l'upgrade de la base que ce soit en mode pas à pas ou normal. : 

 

[server Error] Timeout:La requête a dépassé le temps d"exécution maximum autorisé. Vous devez changer votre configuration serveur pour augmenter la durée de max_execution_time.

 

La seule erreur que j'ai pu trouver dans les logs est la suivante :

2015-03-21 21:37:10 4668 [ERROR] wampmysqld64: Can't find file: '.\prestashop16014\ps__module@000a@0009@0009where@0020name@003d@[email protected]' (errno: 22 - Invalid argument)
 
Aprés quelques recherches j'ai trouvé dans le  fichier install/upgrade/upgrade_cms_15.php , mais ça ne m'en dit pas plus :-/ :
// cms_block table is blockcms module dependant. Don't update table that does not exists
	// /!\ : _module is the wrong table name (fixed in 1.5.0.12.sql : upgrade_cms_15_rename() )
	$id_module_cms = Db::getInstance()->getValue('SELECT id_module from `'._DB_PREFIX_.'_module
		WHERE name="blockcms"`');
	if (!$id_module_cms)
		return $res;

Dans tous les cas, je ne suis même pas sur à 100% que le plantage vienne de là... Et je sèche totalement au bout de X tentatives !

 
Auriez vous une idée ? (je peux remettre la boutique sur une url si besoin)
 
Merci par avance de votre aide.
 
---------------------------------
 
Edit du 24/03/2015 :
Résultat identique sur un dédié. je relance deux fois l upgradeDB (mode pas à pas) qui n'aboutit pas (max execution time) - je le relance une troisieme, Prestashop me dit que je suis déjà en 1.6.0.14 :-(
j ai activé les logs MySQL, mais je ne vois rien de significatif.
 
---------------------------------
 
Edit du 25/03/2015 :
ça plante toujours... en fait quasi tout mon process d'upgradeDB se consacre en temps à la mise à jour de la table ps_tax_lang, et ne semble pas passé l'étape de mise à jour de cette table (quand ça a planté j en étais à 617 000 lignes !!!!).
Et je le relance en tout trois fois cette upgrade jusqu'à plantage et l'annonce que "je suis déjà en 1.6.0.14"
A noter : chaque durée d'upgradeDB semble être au max de 60 minutes jusque temps d'execution maxi bien que je n'ai aucun paramètre dans ma conf php à 3600).
 
Dans AdminSelfUpgrade.php, je viens de trouver le code ci dessous - c'est peut être celui qu'il faut que je gonfle. (à tester demain ! ^^) :
// set timeout to 60 minutes (before aborting an ajax request)
$.ajaxSetup({timeout:3600000})
J'ai suivi de loin le sujet sur la TVA, mais je suppose que la grosseur de cette table est proportionnelle aux nombres de commandes fois le nombre de langues, sinon je ne vois pas pourquoi j'aurais autant de lignes à insérer... Du coup ça devient trés lourd pour une MàJ de 1.4 vers 1.6 avec un grand nombre de commandes.
 
Sinon @Gregory Roussac,
pour info, la version du module autoupgrade actuellement sur l'addon plante sous Prestashop 1.4.11 quand on passe la boutique en maintenance depuis la page de conf du module (mais je crois avoir vu un commit passé à ce sujet)
 
-------
 
Edit du 26/03/2015 :
je viens de retenter une mise à jour (sans le mode pas à pas) en augmentant dans AdminSelfUpgrade.php à 3600000 (600 minutes), le timeout ajax.
Idem au bout de 4 heures de mise à jour : [server Error] Timeout:La requête a dépassé le temps d"exécution maximum autorisé. Vous devez changer votre configuration serveur pour augmenter la durée de max_execution_time.
par contre ma table ps_tax_lang, ne fait que 195 000 lignes (ce qui semble être la bonne valeur - absolument pas compris pourquoi hier elle a atteint les 300000 avec les mêmes données)
J ai bien accés au back office en version 1.6.0.14, mais des erreurs paypal sur la page des modules (ce qui confirme que ce module n'a pas été mis à jour, et donc que l upgrade n'est pas allé à son terme).
 
-------
 
Edit de la victoire ! ;-)
 
Bon c'est enfin passé !
 
A tous ceux qui galèrent, avec des time out et qui ont de grosses bases SQL. Voici ce que j'ai fait :
1. vider vos tables de stats (optionnel)
2. Modification du fichier AdminSelfUpgrade.php du module autoupgrade avant son installation (on monte le timeout ajax de 60 minutes à 600 pour assurer) :
 
	// set timeout to 600 minutes (before aborting an ajax request)
	$.ajaxSetup({timeout:36000000});
 
3. Mise à jour avec puissance serveur élevée (si vous êtes sur un shop qui met plus d'une heure d'upgrade pour la base, vous êtes forcément sur un dédié - enfin je l'espère !)
4. j ai privilégié le mode pas à pas, pour mieux maîtriser les étapes. (activer le mode DEV dans config/defines.inc.php)
 
Désolé pour le monologue et la surplus d'infos, mais bon si certains éléments peuvent servir à quelqu'un, c'est déjà ça !
Edited by mattheoh (see edit history)
  • Like 2
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share
Go to topic listing
×
×
  • Create New...