Partkeepr: Setup2/2 Warming Cache - Respuesta no válida del servidor

Eche un vistazo al registro de errores de su servidor web o donde su instalación de PHP registra el error

En las instalaciones de stock de Debian/ubuntu, los errores van a /var/log/apache2/error_log

Este es el contenido de /var/log/apache2/error.log

errorLog.txt

EDITAR: parece que está vacío, según php.ini, debería escribir todos los tipos de error.
Umm, esto suena raro, pero estar bajo Proxy puede tener un impacto. Además, vi muchos errores de código obsoletos, pero nuevamente no estoy seguro de si es el indicado.

El siguiente es el último error en partkeepr/app/logs/setup.log

php.INFO: La definición del método getGlobals() en la extensión "assetic" está obsoleta sin implementar explícitamente Twig_Extension_GlobalsInterface.
Después de mucho texto, veo que esta es una llamada de preparación:
...,"clase":"PartKeepr\SetupBundle\Controller\CacheWarmupSetupController"... {"función":"cacheWarmupAction"....

Ahora mirado al principio, es el que disparó este error:
...{"tipo":16384,"archivo":"/var/www/partkeepr-1.2.0/app/cache/setup/classes.php","línea":3494,"nivel":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":"->"},{....
@felicito

Hola
intentalo
apt-get install php-apcu php-apcu-bc

@FinalHopee , ¿tarda mucho hasta que aparece el mensaje de respuesta no válida?

Sí, parece como 2 minutos. Lo configuré a 120 como se recomienda.
Logré instalar apcu, ya no hay advertencias.
Pero mismo error.

Luego, debe aumentar max_execution_time: advertir que el caché es una operación intensiva del disco que puede agotarse fácilmente en discos lentos.

Am 11. Februar 2017 12:02:22 MEZ schrieb FinalHopee [email protected] :

Sí, parece como 2 minutos. Lo configuré a 120 como se recomienda.
Logré instalar apcu, ya no hay advertencias.
Pero mismo error.

--
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente o véalo en GitHub:
https://github.com/partkeepr/PartKeepr/issues/811#issuecomment-279136866

--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

establezca max_execution_time en 600, pero por alguna razón muestra un error exactamente después de ejecutar 2 minutos.
Reinicié el servicio apache2, incluso reinicié el host.

Mañana intentaré una nueva instalación en la PC física.
Los mantendré informados, gracias por cualquier ayuda!

¿Puedes verificar usando un archivo phpinfo.php que la configuración tuvo efecto?

Am 11. Februar 2017 13:20:32 MEZ schrieb FinalHopee [email protected] :

establezca max_execution_time en 600, pero por alguna razón muestra un error
exactamente después de correr 2 minutos.
Reinicié el servicio apache2, incluso reinicié el host.

Mañana intentaré una nueva instalación en la PC física.
Los mantendré informados, gracias por cualquier ayuda!

--
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente o véalo en GitHub:
https://github.com/partkeepr/PartKeepr/issues/811#issuecomment-279140451

--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

si, se ve bien
datos phpinfo adjuntos.
Exportado phpinfo a html, puede editar el final o abrir a través del navegador para una fácil visualización.
¿Todo parece estar bien allí?
info.html.txt

Actualizar:
Primero gracias a todos por la ayuda y el tiempo!
En segundo lugar, necesito aumentar mi conocimiento en este asunto para dar más información sobre cómo y por qué funciona.

Después de todo, era un problema de proxy, como pensé.
Lo que hice hoy es que usé una nueva máquina que tenemos, una buena PC, instalé Ubuntu limpio y todo lo necesario de acuerdo con la guía Wiki de Partkeepr y no funcionó.
Luego, quería probar el proxy que usa nuestro lugar, si es el caso.
¡Lo que hice fue desconectar el cable de red de la PC e intentar nuevamente el proceso de configuración y después de esperar de 5 a 10 segundos, se completó el calentamiento!
La misma prueba que hice en otra PC en la que quería usar Partkeepr, ¡y funcionó también!

Probando más el problema, conecté el cable y volví a iniciar la configuración.
Usando la misma dirección y el mismo navegador ( localhost/setup ) recibí ese error nuevamente - Respuesta del servidor no válida
No estoy seguro de cómo ir y depurarlo más allá de aquí, pero parece que algo está bloqueando y tiene que ver con el proxy de nuestra empresa. - Nuevamente, estoy haciendo este procedimiento en la PC usando la dirección localhost. De forma remota, tampoco funcionará, por supuesto.

En resumen, funciona ahora, pero todavía no estoy seguro de por qué no funcionó.

Hmm, esto es probablemente un problema ya que PartKeepr en realidad ejecuta los cronjobs cuando se calienta el caché, ¿tal vez esa es la razón por la que se agota el tiempo de espera en esa posición? Necesita implementar soporte de proxy para PartKeepr, dejando el problema abierto

Otro problema de proxy que he encontrado es el soporte de octopart.
Sin proxy, encuentra elementos con éxito, pero al convertir la red en proxy, falla.

Sí, en este momento no hay soporte para proxies en PartKeepr.

Tiene el mismo problema, pero no puede deshabilitar el proxy. ¿Hay alguna manera de modificar el paso de "calentar el caché" para que funcione sin conexión a Internet?

bueno, sí, puede intentar encontrar la línea relevante en el código y deshabilitarla. Actualmente no tengo tiempo para solucionar el problema, lo siento :(

Me temo que mis habilidades con el software no son lo suficientemente buenas para eso :(

Parece web/setup/js/Cards/UserSetupCard.js
Línea de comentarios // this.tests.push(new PartKeeprSetup.WarmupCacheSetup());

Comentar la parte de calentamiento de caché también funcionó para mí (Windows VM con proxy).

Tenga en cuenta que se requiere calentar el caché para que PartKeepr funcione correctamente; NO recomiendo hacerlo; de lo contrario, generará un problema como el n. ° 962

PartKeepr asume que tiene conectividad a Internet funcional.

Para resolver este problema, hice lo siguiente:
1) Desinstalé php7.2 con el siguiente comando:
apt-get eliminar php7.2*

2) Luego instalé php7.1 (los paquetes de software php7.1 ya no están disponibles en los repositorios predeterminados configurados de Ubuntu 18.04.1)

Consulte el siguiente sitio para obtener instrucciones sobre cómo instalar php7.1:
https://gist.github.com/wayanjimmy/f1679e4c9dc9251fd9df520f5bbe2b5b

También estoy viendo el mismo síntoma, pero ninguna de las discusiones aquí parece aplicarse a mi situación. Algo de información:

• El error aparece casi exactamente después de 2 minutos (como también comentó @FinalHopee ), aunque configuré max_execution_time en 240 s (también verifiqué esto con phpinfo.php)
• No hay ningún servidor proxy en uso. Dado que @FinalHopee hizo que funcionara al desconectar el cable, corté el acceso a Internet temporalmente al filtrar la ip en mi enrutador, pero eso no hizo ninguna diferencia.
• estoy usando una raspberry pi 2
• El php instalado es de la versión 7.0
• El archivo setup.log no contiene ningún error además de los "obsoletos", también vistos por otros.

¿Alguna idea de cómo podría seguir tratando de resolver este problema? Mi única suposición hasta ahora es que, de todos modos, hay un tiempo de espera de 2 minutos, que es demasiado poco para el rpi.

¡Gracias por adelantado!

Lo cronometré, y son exactamente 2 minutos, en el segundo

Aquí igual :(
Instalado en un Synology NAS.
Todas las partes de la configuración funcionan correctamente después de algunos ajustes en NAS-OS.
Pero, al "calentar el caché", falla después de unos 2 minutos.

• Apache 2.2 y 2.4 probado
• PHP 5.6, 7.0 y 7.2 probado
• Los tiempos de espera de PHP aumentaron a valores realmente grandes
• Configuraciones probadas con phpinfo después del cambio
• "Tiempo de espera 600" en "/usr/local/etc/apache24/conf/httpd24.conf" incluido

No hay manera de hacerlo funcionar - Eso es un poco frustrante...

Creo que es solucionable ejecutar la instalación a través de una línea de comandos ssh.
Tal vez puedas encontrar una solución leyendo este hilo.
https://github.com/partkeepr/PartKeepr/issues/916#issue -266508225
Lo tengo funcionando en un Synology y encontré el mismo problema.

Me encontré con este problema hoy con una nueva instalación (FreeBSD 11, PHP 7.2) y descubrí la función de línea de comando para esto:

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.

Ahora voy a depurar el siguiente error... que parece estar relacionado con las funciones de compatibilidad con versiones anteriores de APCU.

acabo de encontrarme con este mismo problema (en Ubuntu 16.04, PHP 7.0, Apache 2.4.18)
caché manual: el calentamiento funciona (consulte la publicación anterior), pero el calentamiento sigue fallando a través de la interfaz de usuario web
la instalación de php-apcu-bc falla: 'no tiene ningún candidato de instalación'

volveré a intentar la instalación en ubuntu 18.04

@thijz , ¿su problema tiene un proxy (reenviado) involucrado, que no puede evitar?

Mi proxy inverso nginx tenía un tiempo de espera predeterminado de 60 segundos, por lo que esto me estaba haciendo tropezar. Sin embargo, no estoy exactamente convencido de que este sea un problema de PartKeepr. Realmente parece un problema de configuración de proxy.

Abordar los valores adecuados de tiempo de espera del proxy solucionó las cosas para mí.

Referencia: https://www.smashinglab.com/fix-504-gateway-time-nginx/

¡Hola tios! Quiero agregar a este error. Estoy instalando PartKeepr en OrangePi (que no es para nada rápido), donde el calentamiento de la memoria caché tarda 2,5 minutos (y max_execution_time se establece en 3 minutos). Sin embargo, según tengo entendido, el tiempo de espera de 2 minutos se establece en algún lugar de la interfaz:

En la captura de pantalla, puede ver 2 solicitudes de warmupCache, una desde la interfaz web realizada durante el procedimiento de configuración, otra realizada manualmente a través de las herramientas de desarrollo de Chrome. El primero se cancela a los 2 m, otro tiene éxito después de 2,5 min (y regresa OK). Entonces, mientras el calentamiento de caché funciona, la interfaz finaliza la solicitud antes de completarse. ¿Hay alguna manera de aumentar el tiempo de espera en el lado JS?

Sí, el tiempo de espera está aquí: https://github.com/partkeepr/PartKeepr/blob/master/web/setup/js/SetupTests/AbstractTest.js#L96
Sin embargo, no sé cómo cambiarlo correctamente solo para esta solicitud

Vi este mismo problema al intentar configurar la imagen de la ventana acoplable de desarrollo en Windows (usando Docker con WSL2, que tiene un rendimiento del sistema de archivos terriblemente malo). Los registros indican que el lado del servidor eventualmente devuelve una respuesta exitosa, pero la interfaz de usuario ya ha fallado en el momento en que se recibe, tal como lo indicó @ positron96 .

Intentaré probar la solicitud de extracción de @ positron96 para ver si funciona para este caso de uso.