Partkeepr: Setup2/2 Warming Cache - Réponse non valide du serveur

Veuillez consulter le journal des erreurs de votre serveur Web ou l'endroit où votre installation PHP enregistre l'erreur

Sur les installations standard debian/ubuntu, les erreurs vont à /var/log/apache2/error_log

Ceci est le contenu de /var/log/apache2/error.log

errorLog.txt

EDIT: On dirait qu'il est vide, selon php.ini, il devrait écrire tous les types d'erreurs.
Umm, cela semble bizarre, mais être sous proxy peut avoir un impact ? De plus, j'ai vu beaucoup d'erreurs de code obsolètes - mais encore une fois, je ne sais pas si c'est celle-là.

Voici la dernière erreur sous partkeepr/app/logs/setup.log

php.INFO : définir la méthode getGlobals() dans l'extension "assetic" est obsolète sans implémenter explicitement Twig_Extension_GlobalsInterface.
Après beaucoup de texte, je vois que c'est un appel d'échauffement :
...,"class":"PartKeepr\SetupBundle\Controller\CacheWarmupSetupController"... {"function":"cacheWarmupAction"....

Maintenant regardé au début, c'est celui qui a déclenché cette erreur :
...{"type":16384,"file":"/var/www/partkeepr-1.2.0/app/cache/setup/classes.php","line":3494,"level":28928," stack":[{"function":"handleError","class":"Symfony\Component\Debug\ErrorHandler","type":"->"},{"file":"/var/www/partkeepr- 1.2.0/app/cache/setup/classes.php","line":3494,"function":"trigger_error"},{"file":"/var/www/partkeepr-1.2.0/app/cache /setup/classes.php","line":3455,"function":"initGlobals","class":"Twig_Environment","type":"->"},{....
@felicitus

salut
essayez-le
apt-get install php-apcu php-apcu-bc

@FinalHopee faut-il longtemps avant que le message de réponse invalide n'apparaisse ?

Oui, il me semble que 2 minutes. Je l'ai configuré à 120 comme recommandé.
J'ai réussi à installer apcu - plus aucun avertissement.
Mais même erreur.

Ensuite, vous devez augmenter le max_execution_time - l'avertissement que le cache est une opération gourmande en disque qui peut facilement expirer sur des disques lents.

Am 11. Février 2017 12:02:22 MEZ schrieb FinalHopee [email protected] :

Oui, il me semble que 2 minutes. Je l'ai configuré à 120 comme recommandé.
J'ai réussi à installer apcu - plus aucun avertissement.
Mais même erreur.

--
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail ou consultez-le sur GitHub :
https://github.com/partkeepr/PartKeepr/issues/811#issuecomment -279136866

--
Ce n'est pas le cas de mon Android-Mobiltelefon mit K-9 Mail gesendet.

définissez max_execution_time sur 600, mais pour une raison quelconque, il affiche une erreur exactement après avoir exécuté 2 minutes.
J'ai redémarré le service apache2, même redémarré l'hôte.

Demain, je vais essayer une nouvelle installation sur un PC physique.
Je vous tiendrai au courant, merci pour toute aide!

Pouvez-vous vérifier en utilisant un fichier phpinfo.php que le paramètre a pris effet ?

Am 11. Février 2017 13:20:32 MEZ schrieb FinalHopee [email protected] :

définissez max_execution_time sur 600, mais pour une raison quelconque, il affiche une erreur
exactement après avoir couru 2 minutes.
J'ai redémarré le service apache2, même redémarré l'hôte.

Demain, je vais essayer une nouvelle installation sur un PC physique.
Je vous tiendrai au courant, merci pour toute aide!

--
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail ou consultez-le sur GitHub :
https://github.com/partkeepr/PartKeepr/issues/811#issuecomment -279140451

--
Ce n'est pas le cas de mon Android-Mobiltelefon mit K-9 Mail gesendet.

oui, ça a l'air bien.
données phpinfo jointes.
Exporté phpinfo au format html, vous pouvez modifier la fin ou ouvrir via le navigateur pour une visualisation facile.
Est-ce que tout semble ok là-bas ?
info.html.txt

Mettre à jour:
Tout d'abord merci à tous pour votre aide et votre temps !
Deuxièmement, j'ai besoin d'approfondir mes connaissances dans ce domaine pour donner plus d'informations sur comment et pourquoi cela fonctionne.

Après tout, c'était un problème de proxy, comme je le pensais.
Ce que j'ai fait aujourd'hui, c'est que j'ai utilisé la nouvelle machine que nous avons, un bon PC - installé Ubuntu propre et tout le nécessaire selon le guide Partkeepr Wiki et cela n'a pas fonctionné.
Ensuite, j'ai voulu tester le proxy que notre place utilise, si c'est le cas.
Ce que j'ai fait, c'est débrancher le câble réseau du PC et réessayer le processus de configuration et après avoir attendu 5 à 10 secondes, l'échauffement est terminé !
Même test que j'ai fait sur un autre PC sur lequel je voulais utiliser Partkeepr, et ça a marché aussi !

En testant davantage le problème, j'ai branché le câble et relancé la configuration.
En utilisant la même adresse et le même navigateur ( localhost/setup ), j'ai de nouveau cette erreur - Réponse du serveur non valide
Je ne sais pas comment aller le déboguer plus loin d'ici, mais il semble que quelque chose bloque et cela a à voir avec le proxy de notre société. - Encore une fois, je fais cette procédure sur le PC en utilisant l'adresse localhost. À distance, cela ne fonctionnera pas aussi bien sûr.

Pour résumer, cela fonctionne maintenant, mais pourquoi cela n'a pas fonctionné, je ne suis pas encore sûr.

Hmm, c'est probablement un problème puisque PartKeepr exécute en fait les tâches cron lors du préchauffage du cache - c'est peut-être la raison pour laquelle il expire à cette position? Nécessité d'implémenter la prise en charge du proxy pour PartKeepr, laissant le problème ouvert

Un autre problème de proxy que j'ai trouvé est le support octopart.
Sans proxy, il trouve avec succès des éléments, mais en tournant le réseau sous proxy, il échoue.

Oui, pour le moment, il n'y a pas de prise en charge des proxys dans PartKeepr.

J'ai le même problème, mais impossible de désactiver le proxy. Existe-t-il un moyen de modifier l'étape "préchauffer le cache", pour qu'elle fonctionne sans connexion Internet ?

eh bien oui, vous pouvez essayer de trouver la ligne appropriée dans le code et la désactiver. Je n'ai pas le temps de résoudre le problème actuellement, désolé :(

J'ai peur que mes compétences en logiciel ne soient pas assez bonnes pour ça :(

Ressemble à web/setup/js/Cards/UserSetupCard.js
Ligne de commentaire // this.tests.push(new PartKeeprSetup.WarmupCacheSetup());

Commenter la partie de réchauffement du cache a également fait l'affaire pour moi (machine virtuelle Windows avec proxy).

Veuillez noter que le préchauffage du cache est nécessaire pour que PartKeepr fonctionne correctement - je ne recommande PAS de le faire - sinon cela conduit à un problème comme #962

PartKeepr suppose qu'il dispose d'une connectivité Internet fonctionnelle.

Pour résoudre ce problème, j'ai procédé comme suit :
1) J'ai désinstallé php7.2 avec la commande suivante :
apt-get supprimer php7.2*

2) J'ai ensuite installé php7.1 (les packages logiciels php7.1 ne sont plus disponibles sur les référentiels configurés par défaut d'Ubuntu 18.04.1)

Veuillez consulter le site suivant pour obtenir des instructions sur l'installation de php7.1 :
https://gist.github.com/wayanjimmy/f1679e4c9dc9251fd9df520f5bbe2b5b

Je vois également le même symptôme, mais aucune des discussions ici ne semble s'appliquer à ma situation. Quelques informations:

• L'erreur apparaît à peu près exactement après 2 min (comme @FinalHopee l' a également commenté), bien que j'aie défini le max_execution_time sur 240 s (j'ai également vérifié cela avec phpinfo.php)
• Aucun serveur proxy n'est utilisé. Depuis que @FinalHopee l'a fait fonctionner en débranchant le câble, j'ai coupé temporairement l'accès à Internet en filtrant l'ip dans mon routeur, mais cela n'a fait aucune différence.
• J'utilise un raspberry pi 2
• Le php installé est de version 7.0
• Le fichier setup.log ne contient aucune erreur autre que celles "obsolètes", également vues par d'autres.

Une idée de comment je pourrais continuer à essayer de résoudre ce problème ? Ma seule supposition jusqu'à présent est qu'il y a de toute façon un délai d'attente de 2 minutes, ce qui est particulièrement trop peu pour le rpi.

Merci d'avance!

Je l'ai chronométré, et c'est exactement 2 min, le deuxième

Pareil ici :(
Installé sur un NAS synology.
Toutes les parties de configuration fonctionnent correctement après quelques réglages dans NAS-OS.
Mais, lors du "réchauffement du cache", il échoue après environ 2 minutes.

• Apache 2.2 & 2.4 testé
• PHP 5.6, 7.0 & 7.2 testé
• Délais d'attente PHP augmentés à de très grandes valeurs
• Paramètres testés avec phpinfo après modification
• "Timeout 600" dans "/usr/local/etc/apache24/conf/httpd24.conf" inclus

Pas moyen de le faire fonctionner - c'est un peu frustrant...

Je pense qu'il est possible d'exécuter l'installation via une ligne de commande ssh.
Peut-être que vous pouvez trouver une solution en lisant ce fil
https://github.com/partkeepr/PartKeepr/issues/916#issue -266508225
Je l'ai fait fonctionner sur un Synology et j'ai rencontré le même problème.

J'ai rencontré ce problème aujourd'hui avec une nouvelle installation (FreeBSD 11, PHP 7.2) et j'ai compris la fonction de ligne de commande pour ceci :

root<strong i="6">@server</strong>:/var/www/partkeepr # php ./app/console cache:warmup
 // Warming up the cache for the dev environment with debug true

 [OK] Cache for the "dev" environment (debug=true) was successfully warmed.

Maintenant, je suis sur le débogage de l'erreur suivante... qui semble être liée aux fonctions de rétrocompatibilité APCU.

vient de rencontrer ce même problème (sur Ubuntu 16.04, PHP 7.0, Apache 2.4.18)
cache manuel : le préchauffage fonctionne (voir le message ci-dessus), mais le préchauffage continue d'échouer via l'interface utilisateur Web
l'installation de php-apcu-bc échoue : 'n'a pas de candidat à l'installation'

je vais réessayer l'installation sur ubuntu 18.04

@thijz votre problème implique un proxy (forward), que vous ne pouvez pas éviter ?

Mon proxy inverse nginx avait un délai d'attente par défaut de 60 secondes, donc cela me faisait trébucher. Je ne suis pas exactement convaincu qu'il s'agit d'un problème de PartKeepr. Ressemble vraiment à un problème de configuration de proxy.

Aborder les bonnes valeurs de délai d'expiration du proxy a corrigé les choses pour moi.

Référence : https://www.smashinglab.com/fix-504-gateway-time-nginx/

Salut les gars! Je veux ajouter à ce bug. J'installe PartKeepr sur OrangePi (ce qui n'est pas du tout rapide) où le préchauffage du cache prend 2,5 min (et max_execution_time est réglé sur 3 min). Cependant, si je comprends bien, un délai d'attente de 2 minutes est défini quelque part dans le frontend :

Sur la capture d'écran, vous pouvez voir 2 requêtes warmupCache, l'une depuis l'interface Web effectuée lors de la procédure d'installation, l'autre effectuée manuellement via les outils de développement Chrome. Le premier est annulé à 2m, un autre réussit après 2,5 min (et renvoie OK). Ainsi, pendant que le préchauffage du cache fonctionne, l'interface met fin à la requête avant la fin. Existe-t-il un moyen d'augmenter le délai d'attente côté JS?

Oui, le délai d'expiration est ici : https://github.com/partkeepr/PartKeepr/blob/master/web/setup/js/SetupTests/AbstractTest.js#L96
Je ne sais pas comment le changer correctement pour cette demande uniquement

J'ai rencontré le même problème lors de la tentative de configuration de l'image Docker de développement sous Windows (à l'aide de Docker avec WSL2, dont les performances du système de fichiers sont terriblement mauvaises). Les journaux indiquent que le côté serveur renvoie finalement une réponse réussie, mais l'interface utilisateur a déjà généré une erreur au moment où elle est reçue, tout comme @ positron96 l' a indiqué.

Je vais essayer de tester la demande d'extraction de @ positron96 pour voir si cela fonctionne pour ce cas d'utilisation.