Magento: all pages keep loading forever - php

The problem is when I open any Magento page in browser, including /admin, it doesn't load properly and keeps loading forever. No files where changed - yesterday it was working, today it stopped working.
Can anyone recommend how to debug it? And what might be the reason for this?
There are no any errors in logs, php works fine, we tried rebooting server.
Thank you.

there wont be any errors unless you have low server resources, or maybe you have some content from external servers that probably down right now. first quick debug - open page in chrome and inspect element, you will see what slows your page. or you can check top, no IO problems, enough RAM, no processes running with >100% CPU?
rebooting server never fixes your problems. check if you have cache enabled.
not much information here to tell you exactly whats going on.

I recently ran into this problem too. My Magneto 2 site (on Ubuntu 16.04) worked fine one day and then would continuously load the next. Cleaning the cache and deleting/rebuilding static files made it work briefly, but it would go back to not loading the pages within a few clicks... even the admin.
My fix happened to be that the disk was full. I didn't realize it until I went in command line and updated composer which kept giving me a disk full error.
I switched to the desktop on Ubuntu and ran a disk analyzer, which pinpointed exactly where all my space was being used.
gksudo baobab
I didn't have gksu installed, so I had to install it first by typing:
sudo apt install gksu
It turns out I had backups that had not been deleted. Large tar files that I no longer needed.
I hope this helps!
Edited to include which OS I am using.

Related

Strange Server-Side Caching issue with Local Development Setup

I've been experiencing an odd issue where something is getting cached somewhere and I'm not sure which item to blame and it's not only driving me nuts, but slows down my development workflow (and is VERY confusing).
The Problem: I save changes made to a PHP file and refresh my browser, however the changes do not show up.
Expected Behavior: The refreshed browser shows the updated file.
Actual Behavior: The most recent changes do not show up.
For some background, here are the possible factors that could be contributing to this problem:
Macbook Pro (16-inch, 2019, 2.6 GHz 6-Core Intel Core i7)
Mac OS (Monterey v12.5)
Chrome (v104.0.5112.79)
MAMP Pro (6.6 Build 33836), Apache (2.4.46), PHP (7.4.21), MySQL (5.7.34)
Xdebug
PhpStorm (2022.2 Build #PS-222.3345.135)
Gulp (v4.0.2) - Unlikely
BrowserSync (v2.26.14) - Unlikely
I work with WordPress although I don't think that's a factor here. Basically what is happening is I'll go to make a change to a PHP file, which could be just adding more code, fixing an error, or maybe even doing a var_dump, and when BrowserSync refreshes, the changes are not reflected, so the new code does nothing, or the error still exists, or the var_dump doesn't show up. Another example is once var_dump does work, if I go to remove that debugging line, it will still show up.
I haven't figured out a fix either, other than just repeatedly refreshing the browser or re-saving the file (sometimes after adding a few blank lines to "trick" whatever it is causing it to think the file has not been changed). This can happen with or without running Gulp/BrowserSync, but I don't want to rule this out as a potential part of the problem. It's behaving like the file has not been saved.
I sometimes will quit gulp and restart to see if that resolves the issue, although it's hard to tell if it has any effect since the problem persists for maybe 30 seconds and then I'm able to see the updated file.
This is something that has recently started to happen but doesn't happen consistently. Sometimes everything works as expected, but it's hard to tell what factors are contributing to when the issue starts happening again. Most recently it started again after I restarted PhpStorm (to apply an update).
Has anyone else experienced something like this? I'm not even sure what other information would be helpful, but would be happy to post more details if I'm missing something. Thanks!

Laravel Installation on Apache - index.php issues

I've been encountering a slew of issues with a fresh install of Laravel on Ubuntu recently but this latest one has me baffled. I was receiving the WSOD with zero errors in apache/php logs or laravel logs, despite having debug set to true and error display in PHP enabled. I updated the index.php file in public to add a die("Test"); line just to see if that was at least working.
It was, which was great - Test displayed on the site. However, now it won't go away. I've tried updating the text to something else, completely removing the line, etc., artisan cache-clear, composer cache clear and dump-autoload, and I've cleared out any cached items in the storage folders. I've cleared my personal cache and tried different browsers, also, so it's not a personal cache issue. I also tried restarting apache.
All of my chmod permissions should be correct at this point (bootstrap/cache is 755, all of the storage and subfolders are 755). I have had laravel write to the log for another issue (from CLI - a test I did just to make sure permissions were working) so that shouldn't be the problem.
I have this working perfectly fine in laragon on my local Windows machine but have had nothing but issues getting this guy up and running on this Ubuntu server. I have another prod instance of laravel that never gave me this much trouble, either, on another Ubuntu server (and usually it was just a permissions issue). Really not sure what to do at this point or what information might be useful. Hoping that someone else has run into something similar and can shed some light....
what kind of error show's the file /var/log/apache2/error_log?
what is the content of your laravel file storage/logs/laravel.logs?
how did you configure the vhost?
did you install laravel with composer?
give us more information please
Turns out the problem lay with the opcache PHP extension. This was enabled on all versions of PHP installed on my prod environment by default and wasn't something I was utilizing on my dev environment. Writing a test to clear opcache resolved this particular problem and I have since disabled the extension, as I was not intending to use it, anyways.
If anyone else runs into this problem and wants to disable, I simply went through WHM Easy Apache 4 and removed the opcache PHP extensions and then edited the php.ini files for all versions of PHP to set any opcache enabled type of flags to 0 (off).

Symfony2.5 slow Initialization time compared to Symfony2.4

I just installed both Symfony2.4.4 and Symfony2.5.1 and set up a hello world page + some basic things I use (assetic js/css management etc). Configuration and setup for both projects are exactly the same.
I noticed that in app_dev the Symfony2.5.1 needs around 1100ms to generate the page, while Symfony2.4.4 only needs around 130ms to generate the same page. Both numbers come from the Symfony debug toolbar.
When I take a look at the profiler's timeline I noticed Symfony2.5.1 uses around 900-1000ms for something called "Initialization time", while with 2.4.4 that only takes 50-60 ms.
Symfony2.5.1
Symfony2.4.4
Does anyone have an idea why it takes Symfony2.5.1 so much longer to initialize the project? I've checked the changelog for 2.5.x but haven't found anything so far. (https://github.com/symfony/symfony/blob/master/CHANGELOG-2.5.md)
Edit: Apparently the 2.5.1 rebuilds the entire dev cache on each page load, while the 2.4.4 does not. Not sure why.
Edit2: Noticed the chromehelper on my mac was running rogue (eating CPU), so I restarted the browser. Afterwards 2.5.1 doesn't rebuild dev cache anymore and load times are similar to 2.4.4. I don't get how it can be related though, how can a rogue browser influence the rebuilding of dev cache? FYI: The 2 projects are running on a virtualbox with centOS on that same mac.
The initialization time difference between both version was happening because Symfony2.5.1 was completely rebuilding its dev cache every time I loaded the page. I 'solved' it by killing off my mac/chrome browser which was running rogue.
After browser restart, 2.5.1 cache behaved the same as 2.4.4, with loading times around 130ms.
How a rogue browser can influence dev cache, I have no clue though.

Laravel templates/controllers not updating on save

I'm running a Laravel 4 for a simple app on OS X.
Basically, changes to controllers and templates don't take effect for a long time after I save changes to those files. For example, I add a word to /app/views/index.blade.php, and don't see any change when constantly refreshing my browser for another minute or so. This makes iterative development understandably painful.
I have tried to chmod 777 app/storage/ and all enclosed files, which has no effect. I have also verified this is not a browser cache issue, because it happens (a) in both Chrome and Safari, and (b) regardless of clearing the cache in those browsers. The problem still occurs even when the app is in "local" and not "production" mode.
I should mention that I am running an updated DP version of OS X 10.9 Mavericks. I can't imagine that would have any effect on Laravel, though.
Edit
I tried calling clearstatcache() in start.php to see if that had any effect, and the problem still remained.
This isn't a laravel issues but a PHP 5.5.3 + MAMP. OP Cache is on by default. see this answer for more: Stop caching for PHP 5.5.3 in MAMP
Having the same issue as as autibyte (note: also recently upgraded to Mavericks, but besides File System permissions not sure how this would be impacting) --- but my blade templates no longer seem to be updating. I've tried permissions + clearing out the views folder. No joy.
I was able to fix the issue by uninstalling MAMP (the app package), then installing PHP, Nginx, and MySQL with homebrew. Now all of my templates update, yay! I am pretty sure that the problem lied with the combination of Apache and Mavericks.
I had the same issue and tried for almost 1 hour to fix the problem. All I did was to restart my computer and then everything worked like a charm for me. Some times computers misbehave and the only solution is to restart or do a cold boot.

APC is corrupting output

I've recently switched my web server to Centos 6.3, with apache 2.2.15, PHP 5.4.11 and APC 3.1.14.
I started receiving complaints from customers from time to time, that a page is not working, or strange errors appear. I saw that the affected pages have question marks and other strange symbols in random places in the output, even though the sources are OK. When I change a single letter in the source file, the page starts working fine.
I suspect APC, but I cannot find any clue when and why this happens.
I use mercurial to push changes to production, but I've used this approach for years with no problem. Maybe something in the configuration is new now, but sadly I don't keep my old configuration.
Below is a screenshot from the last corruption.
Edit: Here's the response after I've changed a single character in the source, saved it, and then undo the files (same is if I just restart the web server or clear APC opcode cache):
Notice the line numbers didn't match, but it's 100% the same request, so the response should be the same also. The line 111 from the first screenshot should not be there at all. It seems that it's from another source file...
I've changed apc.stat_ctime to 1
Verification with ctime will avoid problems caused by programs such as svn or rsync by making sure inodes haven't changed since the last stat. APC will normally only check mtime.
I'll be watching closely on the problem, because it's occurring once or twice a week and post here if this fixed it.

Categories