Partkeepr: Setup2/2 온난화 캐시 - 서버의 잘못된 응답

웹 서버의 오류 로그 또는 PHP 설치에서 오류가 기록되는 위치를 확인하십시오.

재고 debian/ubuntu 설치 시 오류는 /var/log/apache2/error_log로 이동합니다.

이것은 /var/log/apache2/error.log의 내용입니다.

errorLog.txt

편집: php.ini에 따르면 모든 오류 유형을 작성해야 하므로 비어 있는 것 같습니다.
음, 이상하게 들리지만 프록시 아래에 있으면 영향을 미칠 수 있습니까? 또한 사용되지 않는 코드 오류를 많이 보았지만 오류인지는 확실하지 않습니다.

다음은 partkeepr/app/logs/setup.log 아래의 마지막 오류입니다.

php.INFO: "assetic" 확장에서 getGlobals() 메서드를 정의하는 것은 Twig_Extension_GlobalsInterface를 명시적으로 구현하지 않고 더 이상 사용되지 않습니다.
많은 텍스트 후에 이것이 준비 호출임을 알 수 있습니다.
...,"class":"PartKeepr\SetupBundle\Controller\CacheWarmupSetupController"... {"함수":"cacheWarmupAction"....

이제 시작 부분을 살펴보면 이 오류를 일으킨 사람이 다음과 같습니다.
...{"유형":16384,"파일":"/var/www/partkeepr-1.2.0/app/cache/setup/classes.php","줄":3494,"레벨":28928," 스택":[{"함수":"handleError","class":"Symfony\Component\Debug\ErrorHandler","유형":"->"},{"파일":"/var/www/partkeepr- 1.2.0/app/cache/setup/classes.php","line":3494,"function":"trigger_error"},{"파일":"/var/www/partkeepr-1.2.0/app/cache /setup/classes.php","line":3455,"function":"initGlobals","class":"Twig_Environment","유형":"->"},{....
@felicitus

안녕
시도 해봐
apt-get php-apcu php-apcu-bc 설치

@FinalHopee 잘못된 응답 메시지가 나타날 때까지 시간이 오래 걸리나요?

네, 2분 정도 걸린 것 같습니다. 권장대로 120으로 구성했습니다.
나는 apcu 설치에 성공했습니다 - 더 이상 경고가 없습니다.
하지만 같은 오류.

그런 다음 max_execution_time을 늘려야 합니다. 캐시 경고는 느린 디스크에서 쉽게 시간 초과될 수 있는 디스크 집약적인 작업입니다.

오전 11. 2017년 2월 12:02:22 MEZ schrieb FinalHopee [email protected] :

네, 2분 정도 걸린 것 같습니다. 권장대로 120으로 구성했습니다.
나는 apcu 설치에 성공했습니다 - 더 이상 경고가 없습니다.
하지만 같은 오류.

--
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/partkeepr/PartKeepr/issues/811#issuecomment -279136866

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

max_execution_time을 600으로 설정했지만 어떤 이유로 실행 2분 후에 정확히 오류가 표시됩니다.
apache2 서비스를 다시 시작하고 호스트를 재부팅했습니다.

내일 나는 물리적 PC에 새로운 설치를 시도할 것입니다.
계속 알려 드리겠습니다. 도움을 주셔서 감사합니다!

phpinfo.php 파일을 사용하여 설정이 적용되었는지 확인할 수 있습니까?

오전 11. 2017년 2월 13:20:32 MEZ schrieb FinalHopee [email protected] :

max_execution_time을 600으로 설정하지만 어떤 이유로 오류가 표시됩니다.
정확히 2분 실행 후.
apache2 서비스를 다시 시작하고 호스트를 재부팅했습니다.

내일 나는 물리적 PC에 새로운 설치를 시도할 것입니다.
계속 알려 드리겠습니다. 도움을 주셔서 감사합니다!

--
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/partkeepr/PartKeepr/issues/811#issuecomment -279140451

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

예, 좋아 보입니다.
첨부된 phpinfo 데이터.
phpinfo를 html로 내보낸 후 엔딩을 편집하거나 쉽게 볼 수 있도록 브라우저를 통해 열 수 있습니다.
거기는 다 괜찮아 보이나요?
info.html.txt

업데이트:
먼저 도움과 시간을 주셔서 감사합니다!
둘째, 어떻게 그리고 왜 작동하는지에 대한 정보를 더 많이 제공하기 위해 이 문제에 대한 지식을 늘려야 합니다.

결국 내가 생각한대로 프록시 문제였습니다.
오늘 내가 한 것은 우리가 가지고 있는 새 컴퓨터, 좋은 PC - 설치된 깨끗한 Ubuntu 및 Partkeepr Wiki 가이드에 따라 필요한 모든 것을 사용했지만 작동하지 않는다는 것입니다.
그런 다음 문제가 되는 경우 우리 장소에서 사용하는 프록시를 테스트하고 싶었습니다.
내가 한 것은 PC에서 네트워크 케이블을 뽑고 설정 프로세스를 다시 시도하고 5-10초 동안 기다린 후 워밍업이 완료되었습니다!
Partkeepr을 사용하고 싶었던 다른 PC에서 동일한 테스트를 수행했는데 역시 작동했습니다!

문제를 추가로 테스트하고 케이블을 연결하고 설정을 다시 시작했습니다.
동일한 주소와 동일한 브라우저( localhost/setup )를 사용하여 해당 오류가 다시 발생했습니다. - 잘못된 서버 응답
여기에서 더 나아가 디버깅하는 방법을 잘 모르겠지만 뭔가 차단된 것 같으며 우리 회사의 프록시와 관련이 있습니다. - 다시 localhost 주소를 사용하여 PC 항목에서 이 절차를 수행하고 있습니다. 원격으로도 물론 작동하지 않습니다.

요약하자면, 지금은 작동하지만 왜 작동하지 않는지 아직 확실하지 않습니다.

흠 이것은 PartKeepr이 캐시를 워밍업할 때 실제로 cronjob을 실행하기 때문에 아마도 문제일 것입니다. 아마도 이것이 해당 위치에서 시간 초과되는 이유일 것입니다. 문제를 미해결 상태로 두고 PartKeepr에 대한 프록시 지원을 구현해야 함

내가 찾은 또 다른 프록시 문제는 octopart 지원입니다.
프록시가 없으면 성공적으로 항목을 찾지만 프록시에서 네트워크를 전환하면 실패합니다.

예, 지금은 PartKeepr에서 프록시를 지원하지 않습니다.

동일한 문제가 있지만 프록시를 비활성화할 수 없습니다. 인터넷 연결 없이 작동하도록 "캐시 워밍업" 단계를 수정하는 방법이 있습니까?

네, 코드에서 관련 라인을 찾아 비활성화할 수 있습니다. 현재 문제를 해결할 시간이 없습니다. 죄송합니다. :(

내 소프트웨어 기술이 충분하지 않습니다.

web/setup/js/Cards/UserSetupCard.js처럼 보입니다.
주석 줄 // this.tests.push(new PartKeeprSetup.WarmupCacheSetup());

캐시 워밍업 부분을 주석 처리하는 것도 나에게 도움이 되었습니다(프록시가 있는 Windows VM).

PartKeepr이 제대로 실행되려면 캐시 워밍업이 필요합니다. 권장하지 않습니다. 그렇지 않으면 #962와 같은 문제가 발생합니다.

PartKeepr은 기능적인 인터넷 연결이 있다고 가정합니다.

이 문제를 해결하기 위해 다음을 수행했습니다.
1) 다음 명령으로 php7.2를 제거했습니다.
apt-get 제거 php7.2*

2) 그런 다음 php7.1을 설치했습니다(php7.1 소프트웨어 패키지는 기본 Ubuntu 18.04.1 구성 리포지토리에서 더 이상 사용할 수 없음).

php7.1 설치 방법에 대한 지침은 다음 사이트를 참조하십시오.
https://gist.github.com/wayanjimmy/f1679e4c9dc9251fd9df520f5bbe2b5b

저도 같은 증상이 나타나는데 여기 있는 논의 중 제 상황에 해당하는 내용이 없는 것 같습니다. 일부 정보:

• max_execution_time을 240초로 설정했지만 오류는 2분 후에 거의 정확하게 나타납니다( @FinalHopee 도 언급함).
• 사용 중인 프록시 서버가 없습니다. @FinalHopee 가 케이블을 뽑아서 작동하게 했기 때문에 라우터에서 IP를 필터링하여 인터넷 액세스를 일시적으로 차단했지만 아무런 차이가 없었습니다.
• 저는 라즈베리파이2를 사용하고 있습니다.
• 설치된 PHP는 버전 7.0입니다.
• setup.log 파일에는 다른 사람들도 볼 수 있는 "사용하지 않는" 오류 이외의 오류가 포함되어 있지 않습니다.

이 문제를 해결하기 위해 계속 노력할 수 있는 방법이 있습니까? 지금까지 내 유일한 추측은 어쨌든 2분 제한 시간이 있다는 것인데, 이는 특히 rpi에 대해 너무 적습니다.

미리 감사드립니다!

시간을 재어보니 정확히 2분.

여기도 마찬가지 :(
Synology NAS에 설치되었습니다.
NAS-OS에서 일부 조정 후 모든 설정 부분이 올바르게 실행됩니다.
그러나 "캐시 워밍업"에서는 약 2분 후에 실패합니다.

• Apache 2.2 및 2.4 테스트됨
• PHP 5.6, 7.0 및 7.2 테스트됨
• PHP 시간 초과가 정말 큰 값으로 증가했습니다.
• 변경 후 phpinfo로 테스트한 설정
• "/usr/local/etc/apache24/conf/httpd24.conf"에 "Timeout 600"이 포함됨

작동하게 할 방법이 없습니다 - 약간 실망스럽습니다...

ssh 명령줄을 통해 설치를 실행하는 것이 해결될 수 있다고 생각합니다.
이 스레드를 읽고 솔루션을 찾을 수 있습니다.
https://github.com/partkeepr/PartKeepr/issues/916#issue -266508225
Synology에서 실행했는데 동일한 문제가 발생했습니다.

저는 오늘 새로운 설치(FreeBSD 11, PHP 7.2)로 이 문제에 부딪쳤고 이에 대한 명령줄 기능을 알아냈습니다.

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.

이제 다음 오류를 디버깅하는 중입니다... APCU 이전 버전과의 호환성 기능과 관련된 것으로 보입니다.

방금이 동일한 문제가 발생했습니다 (Ubuntu 16.04, PHP 7.0, Apache 2.4.18)
수동 캐시:워밍업 이 작동하지만(위의 게시물 참조) 웹 UI를 통해 워밍업이 계속 실패합니다.
php-apcu-bc 설치 실패: '설치 후보가 없습니다'

우분투 18.04에서 설치를 다시 시도합니다.

@thijz 귀하의 문제에는 피할 수 없는 (전달) 프록시가 포함되어 있습니까?

내 nginx 리버스 프록시의 기본 시간 초과가 60초였으므로 문제가 발생했습니다. 하지만 이것이 PartKeepr 문제라는 사실을 정확히 알 수는 없습니다. 실제로 프록시 구성 문제처럼 보입니다.

적절한 프록시 시간 초과 값을 해결하면 문제가 해결되었습니다.

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

안녕 얘들아! 이 버그에 추가하고 싶습니다. 저는 캐시 워밍업이 2.5분( max_execution_time 이 3분으로 설정됨)이 걸리는 OrangePi(빠르지는 않음)에 PartKeepr을 설치하고 있습니다. 그러나 내가 이해하는 것처럼 2분 제한 시간은 프론트엔드 어딘가에 설정되어 있습니다.

스크린샷에서 2개의 warmupCache 요청을 볼 수 있습니다. 하나는 설정 절차 중에 수행된 웹 인터페이스에서, 다른 하나는 Chrome devtools를 통해 수동으로 수행한 것입니다. 첫 번째 것은 2m에 취소되고 다른 것은 2.5분 후에 성공합니다(그리고 OK를 반환합니다). 따라서 캐시 워밍업이 작동하는 동안 프런트엔드는 완료되기 전에 요청을 종료합니다. JS 측에서 시간 초과를 늘리는 방법이 있습니까?

예, 시간 초과가 있습니다. https://github.com/partkeepr/PartKeepr/blob/master/web/setup/js/SetupTests/AbstractTest.js#L96
이 요청에 대해서만 올바르게 변경하는 방법을 모릅니다.

Windows에서 개발 도커 이미지를 설정하려고 할 때 이와 동일한 문제를 보았습니다(WSL2를 사용하여 파일 시스템 성능이 매우 나쁜 Docker 사용). 로그는 서버 측이 결국 성공적인 응답을 반환하고 있음을 나타내지만 @positron96 이 표시한 것처럼 수신될 때 UI는 이미 오류가 발생했습니다.

@positron96 의 pull 요청이 이 사용 사례에서 작동하는지 확인하기 위해 시도하고 테스트하겠습니다.