Partkeepr: Setup2/2 Warming Cache - Invalid Response from Server

Please have a look in your web server's error log or where your PHP installation logs the error

On stock debian/ubuntu installations the errors go to /var/log/apache2/error_log

This is the content of /var/log/apache2/error.log

errorLog.txt

EDIT: Looks like it is empty, according to php.ini it should write all error types.
Umm, this sounds weird but being under Proxy can have impact? Also, i saw a lot of deprecated code errors - but again not sure if it is the one.

The following is the last error under partkeepr/app/logs/setup.log

php.INFO: Defining the getGlobals() method in the "assetic" extension is deprecated without explicitly implementing Twig_Extension_GlobalsInterface.
After a lot of text i see this is warmup call:
...,"class":"PartKeepr\SetupBundle\Controller\CacheWarmupSetupController"... {"function":"cacheWarmupAction"....

Now looked at the beginning, is the one who triggered this error:
...{"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

Hi
try it
apt-get install php-apcu php-apcu-bc

@FinalHopee does it take long until the invalid response message appears?

Yes, it seems like 2 minutes. I did configure it to 120 as recommended.
I did succeeded installing apcu - no warnings anymore.
But same error.

Then you should increase the max_execution_time - warning up the cache is a disk intensive operation which can easily time out on slow disks.

Am 11. Februar 2017 12:02:22 MEZ schrieb FinalHopee notifications@github.com:

Yes, it seems like 2 minutes. I did configure it to 120 as recommended.
I did succeeded installing apcu - no warnings anymore.
But same error.

--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/partkeepr/PartKeepr/issues/811#issuecomment-279136866

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

set max_execution_time to 600, but for some reason it shows error exactly after running 2 minutes.
I did restart apache2 service, even rebooted the host.

Tomorrow i will try new installation on physical PC.
Will keep you posted, thanks for any help!

Can you verify by using a phpinfo.php file that the setting took effect?

Am 11. Februar 2017 13:20:32 MEZ schrieb FinalHopee notifications@github.com:

set max_execution_time to 600, but for some reason it shows error
exactly after running 2 minutes.
I did restart apache2 service, even rebooted the host.

Tomorrow i will try new installation on physical PC.
Will keep you posted, thanks for any help!

--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/partkeepr/PartKeepr/issues/811#issuecomment-279140451

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

yeah, looks good.
attached phpinfo data.
Exported phpinfo to html, you can edit the ending or open via browser for easy view.
Is everything seems ok there?
info.html.txt

Update:
First thanks all for help and time!
Second, i do need to increase in knowledge in this matter to give more input as for how and why it works.

After all it was proxy problem, as i thought.
What i did today is I used new machine we have, good PC - installed clean Ubuntu and everything needed according to Partkeepr Wiki guide and it did not work.
Then, i wanted to test the proxy that our place uses, if it is the matter.
What i did is plugged out the network cable from the pc and tried again the setup process and after waiting for 5 - 10 seconds warming up completed!
Same test i've done on another PC that i wanted to use Partkeepr on, and it did work too!

Testing the issue further i plugged the cable in and launched the setup again.
Using same address and same browser (localhost/setup) i got that error again - Invalid Server Response
Not sure how to go and debug it further from here but it does look like something is blocking and it has to do with our company's proxy. - Again i am doing this procedure on the PC iteslf using localhost address. Remotely it wont work too of course.

To sum up, it works now, but why it didn't work i am not sure yet.

Hmm this is probably an issue since PartKeepr actually runs the cronjobs when warming up the cache - maybe that's the reason why it times out at that position? Need to implement proxy support for PartKeepr, leaving the issue open

Another proxy issue I've found is octopart support.
Without proxy it successfully finds items but turning network under proxy it fails.

Yes, right now there's no support for proxies in PartKeepr.

Have same problem, but can not disable proxy. Is there a way to modify the "warming up the cache"-step, that it works without internet-connection?

well yes, you can try to find the relevant line in the code and disable it. I don't currently have time to fix the issue, sorry :(

i´m afraid my software-skills are not good enough for that :(

Looks like web/setup/js/Cards/UserSetupCard.js
Comment line // this.tests.push(new PartKeeprSetup.WarmupCacheSetup());

Commenting out the cache warming part did the trick for me as well (Windows VM with proxy).

Please note that warming up the cache is required for PartKeepr to run properly - I do NOT recommend doing it - otherwise it leads to issue like #962

PartKeepr assumes that it has functional internet connectivity.

To resolve this issue, I did the following:
1) I uninstalled php7.2 with the following command:
apt-get remove php7.2*

2) I then installed php7.1 (php7.1 software packages are no longer available on the default Ubuntu 18.04.1 configured repositories)

Please refer to the following site for instructions on how to install php7.1:
https://gist.github.com/wayanjimmy/f1679e4c9dc9251fd9df520f5bbe2b5b

I'm also seeing the same symptom, but none of the discussions here seem to apply to my situation. Some info:

• The error appears pretty much exactly after 2 min (as @FinalHopee also commented), although I've set the max_execution_time to 240 s (I also checked this with phpinfo.php)
• The is no proxy server in use. Since @FinalHopee made it work by plugging out the cable, I cut internet access temporarily by filtering the ip in my router, but that made no difference.
• I'm using a raspberry pi 2
• The installed php is of version 7.0
• The setup.log file does not contain any errors other than "depricated" ones, also seen by others.

Any idea how I could continue trying to solve this issue? My only guess so far is that there anyway is a 2 min timeout, which is especially too little for the rpi.

Thanks in advance!

I timed it, and it's exactly 2 min, on the second

Same here :(
Installed on a synology NAS.
All setup parts running properly after some tunings in NAS-OS.
But, on "warming up cache" it fails after around 2Minutes.

• Apache 2.2 & 2.4 tested
• PHP 5.6 , 7.0 & 7.2 tested
• PHP Timeouts increased to really big values
• Settings tested with phpinfo after change
• "Timeout 600" in "/usr/local/etc/apache24/conf/httpd24.conf" included

No way to get it work - Thats a bit frustrating...

I think it is solvable to run the installation trough a ssh commandline.
Maybe you can find a solution reading this thread
https://github.com/partkeepr/PartKeepr/issues/916#issue-266508225
I’ve got it running on a Synology, and encountered the same problem.

I ran into this issue today with a new install (FreeBSD 11, PHP 7.2) and figured out the command line function for this:

root@server:/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.

Now I'm onto debugging the next error... which seems to be related to the APCU backwards compatibility functions.

just ran into this same issue (on Ubuntu 16.04, PHP 7.0, Apache 2.4.18)
manual cache:warmup works (see post above), but warmup keeps failing via the web UI
installing php-apcu-bc fails : 'has no installation candidate'

i will retry the install on ubuntu 18.04

@thijz your problem has a (forward) proxy involved, that you cannot avoid?

My nginx reverse proxy had a default timeout of 60 seconds, so this was tripping me up. I'm not exactly sold that this is a PartKeepr issue, though. Really looks like a proxy configuration issue.

Addressing the proper proxy timeout values fixed things for me.

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

Hi guys! I want to add to this bug. I'm installing PartKeepr on OrangePi (which is not by all means fast) where cache warm up takes 2.5 min (and max_execution_time is set to 3 min). However, as I understand it, 2 min timeout is set somewhere in frontend:

On the screenshot you can see 2 warmupCache requests, one from web interface made during setup procedure, other made manually via Chrome devtools. The first one gets cancelled at 2m, another one succeeds after 2.5 min (and returns OK). So, while cache warmup works, the frontend terminates the request before completion. Is there a way to increase the timeout on JS side?

Yep, timeout is here: https://github.com/partkeepr/PartKeepr/blob/master/web/setup/js/SetupTests/AbstractTest.js#L96
Dunno how to change it correctly for this request only though

I saw this same issue when attempting to set up the development docker image on Windows (using Docker w/ WSL2, which has terribly bad file system performance). Logs indicate that the server side is eventually returning a successful response, but the UI has already errored out by the time it is received, just as @positron96 has indicated.

I will try and test @positron96's pull request to see if it works for this use case.