For some reason my Magento 1.6.2 site has gone into maintenance mode twice in the past 12 days, yet I haven't installed or updated any extensions (as far as I'm aware) during that time. It's pretty frustrating, since I don't even realize my site is down until I hear it from a potential customer. I can easily fix the problem by deleting the maintenance.flag that gets created in my root directory, but I want to know how to stop this from occurring. I'd hate for my Website to go down while I'm sleeping or over the weekend, and lose out on hours-days of potential revenue.
Has anyone else encountered this issue of phantom maintenance.flags being created? Is it possible one of my previously installed extensions is automatically updating and causing a problem? Is there any way to disable my site going in to maintenance mode without my consent? Any help is appreciated!
The problem might be error in one of your page rendering, like your one of file might contain error and on execution of that particular page(on request by customer) it gets error and goes into maintenance mode.
If you check index.php file, you’ll notice one interesting thingy, it checks for existence of “maintenance.flag” file in store root, if it’s found your store is put into maintenance mode. Service Temporarily Unavailable page is displayed with Please try again later message.
Related
I don't know exactly why my drupal 7 website became suddenly slow last week, after few days in production.
With xhprof, i see that at each page load,the system_list_reset() function triggers a call to cache_clear_all() function.
I deactivated all cache features.
I've read that it may due to missing files in modules and/or themes, but I didn't find missing files (except a wrong issue in 'missing module message fixer' module that indicates a missing module in view_export sub-module of view module).
I manually searched them , I didn't find where drupal can list these missing files.
Or maybe it's due to another problem.
Regards,
Open page inspector of your browser and in network tab check what files have unusually long loading time. It maybe be that some external service is causing this. Also it can be that your site is hacked...
Check most banal reason, the storage space - maybe disc of your server is full?
Check if file paths drupal is using are writable. Go to Configuration -> Median -> File system and just click Save. If some path is not writable it will get red outline.
Go to Reports -> Recent log message and check if some issue is maybe logged there. Also check for web server/php logs.
Try updating modules and drupal core - maybe some bug caused that and it's hopefully fixed in module update.
If not, try disabling modules one by one and see will that still happen. If you don't find problematic module try the same method with your theme. Would be good not to try this in production development and/or make backup before doing this.
thanks a lot,
by disabling module one by one, and by "datamining" in drupal DB, i've found that ADVAGG module was guilty.
The clean was difficult, because some entires remains in some tables of Drupal DB afther the module removing, but I hope it Ok.
BEWARE OF ADVAGG MODULE !
Funny :-/ with 'top', I've found a mining soft in /var/tmp/
systemd-private-a5422b1e6694466bbb0b63203573cad1-apache2.service-jMBN4U : nullcrew (from https://github.com/xmrig/xmrig)
I will investigate how it could land on my webserver
Best regards,
A relative asked me to fixed a Joomla website (v2.5.16) who has been hacked last year, probably due to lack of update (is up to date now), unfortunately I have no information about this. The issue is that the front end take 2~ min to load. The administration is loading normally so whatever the issue is, it depend of the front end. I already disabled all modules one by one and switched the template with another one to make sure that thebug is not in template or plugins folders, without success.
I must add that the problem is "probably" more recent than the hack, according to this person. So maybe there was a script somewhere reaching a random server which may not work anymore.
PS : the website is on a shared hosting. I have the FTP access but no ssh.
I know that I don't give any details which can lead to resolve this, but I need more a method to track what can go wrong and where than a solution.
Thanks in advance,
We have written a lengthy post explaining why a website might be slow: http://www.itoctopus.com/20-questions-you-should-be-asking-yourself-if-your-joomla-website-is-slow
From the looks of it, it might that the website is still hacked. Try overwriting the Joomla files with a fresh Joomla install and see if that addresses the problem.
Solving this issue will probably involve some or all of the following:
updating Joomla and all third party extensions to the latest versions
checking for and fixing malicious files using http://myjoomla.com or
https://sucuri.net or similar
analysing the performance of the website using http://gtmetrix.com
(it's free) or similar to pinpoint and fix what is taking the most time to
load
If the website has been hacked, you may need to reset passwords etc once the malicious files have been removed. See https://joomla.stackexchange.com/a/180/120 for more information about securing the website once it is fixed.
I've been working on a Magento site for a few months now. About 2 weeks ago, the site suddenly seemed broken. All the css was gone and I was unable to log into the admin (which was also missing its styles).
I was able to access the database through my host's control panel & found that the unsecure_base_url and secure_base_url were both changed. I had set them to:
mysubdir.mysite.com/
but now they had /magento on the end like this:
mysubdir.mysite.com/magento/
This was the default value upon installation. But since the entire site is in magento, I took it out of this directory and moved it into the web root when I started the project.
I manually changed the values in the database, along with my admin password, which was also not working. About a week later, the same thing happened again. Then a couple days later, it happened again. Then it happened again in the next day and again in the same day after I fixed it.
In the meantime, I've been scouring the server looking for any scripts that could be running that would change these values. I haven't found anything. I looked at every file that had a date matching the time this started & verified with my host that they were legitimate files.
I've also been looking through the magento code, looking for every instance of "core_config_data" to see if I can find any code that sets that value but I haven't found anything yet.
I'm using the community edition. Is there some code in there that resets the base urls after a trial period or something? I've searched but can't find anyone else who's experienced this problem.
I did find some magento cache files that contained mysubdir.mysite.com/magento/. Could it be that it's reverting to cached values? I've flushed the magento cache and cache storage. caching is actually disabled on the site at the moment anyway because it's still in development but it was enabled previously.
Thanks in advance for ANY help, leads, or advice.
If it's being set programmatically via some kind of observer or Magento-configured cron, this is the most probable syntax:
$config->saveConfig('web/unsecure/base_url', 'http://www.example.com/', 'default');
$config->saveConfig('web/secure/base_url', 'https://www.example.com/', 'default');
Knowing this, I'd do a search for this string:
grep -Ri "saveConfig('web/secure/base_url" .
grep -Ri "saveConfig('web/unsecure/base_url" .
I'd start in app/code, and if that turns up nothing, I'd sit through a grep in the Magento root directory.
That will at least rule that out if nothing else.
I have been trying to get my Magento site to take some changes but it is still not refreshing the changes. I have disabled caching and flushed all of them on every single occasion I have also cleared my browser cache and it still does not take changes. I have gone as far to delete several files from the server that the theme relies on but it still functions like nothing was ever removed! What could be my issue?
You keep editing those files. I do not think those files are the files you think they are.
You question is pretty short on details, but my first guess if your system is running with the compiler enabled, which means it's loading its class files from
includes/src
Googling around to learn about the compiler would be a good idea.
I'd try adding the following to the end of your index.php file
echo '<--';
print_r(get_included_files());
echo '-->';
This will list every file PHP used during the request. Compare the full paths with the ones you're editing, and I bet you'll find a discrepancy.
I took a backup of my live Magento site yesterday (zipped up the files and took a DB dump then created the site from those dumps).
Oddly though, on my local machine I get a firebug error that states "$ is not a function" and this error occurs every 500ms or so. So after a minute or 2 I have thousands of errors in the console all the same.
The site is an exact replica of my live site and I don't get the error on that so I'm stumped!
Usually I would think this is a prototype/jquery conflict, but it only seems to happen on my local machine.
Any one have a clue what might be going on?
Thanks
Load a page where you see the error.
View the source of the page.
Find the line that's supposed to load prototype.js by searching for the string prototype.js.
ex. http://magento.example.com/js/prototype/prototype.js
Discover that, for one of myriad reasons, the file isn't loading. (wrong URL, permissions, corrupt file, etc.)
Address problem discovered above.
Ok so this was the problem:
The reason it worked on live and not dev was because I had merge JS enabled on live and not on dev. Live was therefore looking at an old cached bunch of js. Disabling merge js on live highlighted that the problem did in fact occur on the live site.
This knowledge allowed me to debug further and I discovered that the problem lay with my jquery.hove.intent.js file. I updated this to the latest version and it solved everything! :)
Thanks all for your help and input though.