Partkeepr: Cache de aquecimento Setup2/2 - Resposta inválida do servidor

Por favor, dê uma olhada no log de erros do seu servidor web ou onde sua instalação PHP registra o erro

Em instalações debian/ubuntu padrão, os erros vão para /var/log/apache2/error_log

Este é o conteúdo de /var/log/apache2/error.log

errorLog.txt

EDIT: Parece que está vazio, de acordo com o php.ini deve escrever todos os tipos de erro.
Hum, isso soa estranho, mas estar sob Proxy pode ter impacto? Além disso, vi muitos erros de código obsoletos - mas novamente não tenho certeza se é o único.

O seguinte é o último erro em partkeepr/app/logs/setup.log

php.INFO: Definir o método getGlobals() na extensão "assetic" está obsoleto sem implementar explicitamente Twig_Extension_GlobalsInterface.
Depois de muito texto, vejo que esta é uma chamada de aquecimento:
..."class":"PartKeepr\SetupBundle\Controller\CacheWarmupSetupController"... {"function":"cacheWarmupAction"....

Agora olhado no início, é quem acionou esse erro:
...{"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

Oi
tente
apt-get install php-apcu php-apcu-bc

@FinalHopee demora muito até que a mensagem de resposta inválida apareça?

Sim, parece que 2 minutos. Eu configurei para 120 como recomendado.
Consegui instalar o apcu - não há mais avisos.
Mas mesmo erro.

Em seguida, você deve aumentar o max_execution_time - avisar que o cache é uma operação intensiva em disco que pode facilmente atingir o tempo limite em discos lentos.

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

Sim, parece que 2 minutos. Eu configurei para 120 como recomendado.
Consegui instalar o apcu - não há mais avisos.
Mas mesmo erro.

--
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente ou visualize-o no GitHub:
https://github.com/partkeepr/PartKeepr/issues/811#issuecomment -279136866

--
Diese Nachricht wurde meinem Android-Mobiltelefon com K-9 Mail geendet.

defina max_execution_time para 600, mas por algum motivo ele mostra o erro exatamente após a execução de 2 minutos.
Eu reiniciei o serviço apache2, até reiniciei o host.

Amanhã vou tentar nova instalação no PC físico.
Vou mantê-lo informado, obrigado por qualquer ajuda!

Você pode verificar usando um arquivo phpinfo.php que a configuração entrou em vigor?

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

defina max_execution_time para 600, mas por algum motivo mostra erro
exatamente após correr 2 minutos.
Eu reiniciei o serviço apache2, até reiniciei o host.

Amanhã vou tentar nova instalação no PC físico.
Vou mantê-lo informado, obrigado por qualquer ajuda!

--
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente ou visualize-o no GitHub:
https://github.com/partkeepr/PartKeepr/issues/811#issuecomment -279140451

--
Diese Nachricht wurde meinem Android-Mobiltelefon com K-9 Mail geendet.

sim, parece bom.
dados phpinfo anexados.
Exportado phpinfo para html, você pode editar o final ou abrir via navegador para facilitar a visualização.
Está tudo bem aí?
info.html.txt

Atualizar:
Primeiramente obrigado a todos pela ajuda e tempo!
Em segundo lugar, eu preciso aumentar o conhecimento sobre este assunto para dar mais informações sobre como e por que isso funciona.

Afinal, era problema de proxy, como eu pensava.
O que fiz hoje é que usei a nova máquina que temos, um bom PC - instalei o Ubuntu limpo e tudo o que era necessário de acordo com o guia Partkeepr Wiki e não funcionou.
Então, eu queria testar o proxy que nosso local usa, se for o caso.
O que eu fiz foi desconectar o cabo de rede do pc e tentar novamente o processo de configuração e depois de esperar 5 a 10 segundos, o aquecimento foi concluído!
O mesmo teste que fiz em outro PC em que queria usar o Partkeepr, e funcionou também!

Testando o problema ainda mais, conectei o cabo e iniciei a configuração novamente.
Usando o mesmo endereço e o mesmo navegador ( localhost/setup ), recebi esse erro novamente - Invalid Server Response
Não tenho certeza de como depurá-lo daqui, mas parece que algo está bloqueando e tem a ver com o proxy da nossa empresa. - Novamente estou fazendo este procedimento no próprio PC usando o endereço localhost. Remotamente não vai funcionar também, é claro.

Para resumir, funciona agora, mas por que não funcionou, ainda não tenho certeza.

Hmm, isso provavelmente é um problema, pois o PartKeepr realmente executa os cronjobs ao aquecer o cache - talvez seja essa a razão pela qual ele expira nessa posição? Necessidade de implementar suporte de proxy para PartKeepr, deixando o problema em aberto

Outro problema de proxy que encontrei é o suporte octopart.
Sem proxy, ele encontra itens com sucesso, mas ao girar a rede sob proxy, ele falha.

Sim, no momento não há suporte para proxies no PartKeepr.

Tem o mesmo problema, mas não pode desabilitar o proxy. Existe uma maneira de modificar a etapa "aquecer o cache", que funciona sem conexão com a Internet?

bem, sim, você pode tentar encontrar a linha relevante no código e desativá-la. No momento não tenho tempo para resolver o problema, desculpe :(

Receio que minhas habilidades de software não sejam boas o suficiente para isso :(

Parece web/setup/js/Cards/UserSetupCard.js
Linha de comentários // this.tests.push(new PartKeeprSetup.WarmupCacheSetup());

Comentar a parte de aquecimento do cache também funcionou para mim (Windows VM com proxy).

Observe que é necessário aquecer o cache para que o PartKeepr funcione corretamente - NÃO recomendo fazê-lo - caso contrário, isso leva a problemas como # 962

O PartKeepr assume que possui conectividade funcional com a Internet.

Para resolver esse problema, fiz o seguinte:
1) Desinstalei o php7.2 com o seguinte comando:
apt-get remove php7.2*

2) Eu instalei o php7.1 (os pacotes de software php7.1 não estão mais disponíveis nos repositórios configurados padrão do Ubuntu 18.04.1)

Consulte o seguinte site para obter instruções sobre como instalar o php7.1:
https://gist.github.com/wayanjimmy/f1679e4c9dc9251fd9df520f5bbe2b5b

Também estou vendo o mesmo sintoma, mas nenhuma das discussões aqui parece se aplicar à minha situação. Algumas informações:

• O erro aparece exatamente após 2 min (como @FinalHopee também comentou), embora eu tenha definido o max_execution_time para 240 s (também verifiquei isso com phpinfo.php)
• Não há servidor proxy em uso. Como o @FinalHopee fez funcionar desconectando o cabo, cortei o acesso à internet temporariamente filtrando o ip no meu roteador, mas isso não fez diferença.
• Estou usando um framboesa pi 2
• O php instalado é da versão 7.0
• O arquivo setup.log não contém nenhum erro além dos "depreciados", também vistos por outros.

Alguma ideia de como eu poderia continuar tentando resolver esse problema? Meu único palpite até agora é que há um tempo limite de 2 minutos, o que é especialmente muito pouco para o rpi.

Desde já, obrigado!

Eu cronometrei, e são exatamente 2 minutos, no segundo

Mesmo aqui :(
Instalado em um synology NAS.
Todas as partes de configuração funcionando corretamente após alguns ajustes no NAS-OS.
Mas, no "aquecimento do cache", ele falha após cerca de 2 minutos.

• Apache 2.2 e 2.4 testados
• PHP 5.6, 7.0 e 7.2 testado
• Tempos limite do PHP aumentados para valores realmente grandes
• Configurações testadas com phpinfo após a alteração
• "Timeout 600" em "/usr/local/etc/apache24/conf/httpd24.conf" incluído

Não há maneira de fazê-lo funcionar - Isso é um pouco frustrante ...

Eu acho que é solucionável executar a instalação através de uma linha de comando ssh.
Talvez você possa encontrar uma solução lendo este tópico
https://github.com/partkeepr/PartKeepr/issues/916#issue -266508225
Eu o tenho em execução em um Synology e encontrei o mesmo problema.

Eu encontrei esse problema hoje com uma nova instalação (FreeBSD 11, PHP 7.2) e descobri a função de linha de comando para isso:

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.

Agora estou depurando o próximo erro... que parece estar relacionado às funções de compatibilidade com versões anteriores do APCU.

acabei de encontrar esse mesmo problema (no Ubuntu 16.04, PHP 7.0, Apache 2.4.18)
cache manual: o aquecimento funciona (veja a postagem acima), mas o aquecimento continua falhando por meio da interface do usuário da web
a instalação do php-apcu-bc falha: 'não tem candidato à instalação'

vou tentar novamente a instalação no Ubuntu 18.04

@thijz seu problema tem um proxy (de encaminhamento) envolvido, que você não pode evitar?

Meu proxy reverso nginx tinha um tempo limite padrão de 60 segundos, então isso estava me atrapalhando. Eu não estou exatamente convencido de que este é um problema do PartKeepr, no entanto. Realmente parece um problema de configuração de proxy.

Abordar os valores de tempo limite de proxy adequados corrigiu as coisas para mim.

Referência: https://www.smashinglab.com/fix-504-gateway-time-nginx/

Oi pessoal! Eu quero adicionar a este bug. Estou instalando o PartKeepr no OrangePi (que nem sempre é rápido), onde o aquecimento do cache leva 2,5 minutos (e max_execution_time é definido como 3 minutos). No entanto, pelo que entendi, o tempo limite de 2 minutos é definido em algum lugar no frontend:

Na captura de tela, você pode ver 2 solicitações de warmupCache, uma da interface da Web feita durante o procedimento de configuração, outra feita manualmente via devtools do Chrome. O primeiro é cancelado em 2m, outro é bem-sucedido após 2,5 min (e retorna OK). Portanto, enquanto o aquecimento do cache funciona, o frontend encerra a solicitação antes da conclusão. Existe uma maneira de aumentar o tempo limite no lado JS?

Sim, o tempo limite está aqui: https://github.com/partkeepr/PartKeepr/blob/master/web/setup/js/SetupTests/AbstractTest.js#L96
Não sei como alterá-lo corretamente apenas para esta solicitação

Eu vi esse mesmo problema ao tentar configurar a imagem do docker de desenvolvimento no Windows (usando o Docker com WSL2, que tem um desempenho do sistema de arquivos terrivelmente ruim). Os logs indicam que o lado do servidor está retornando uma resposta bem-sucedida, mas a interface do usuário já apresentou erro no momento em que é recebida, assim como @positron96 indicou.

Vou tentar testar o pull request do @positron96 para ver se funciona para este caso de uso.