Can't cancel orders in Magento 1.7.0

Hello there!

We are experiencing this issue for about a week, and after a lot of investigation we still couldn't find any solution. I really hope someone here nails it!

So here we go...

Here is the error that shows up when we try to cancel any order through Magento admin panel:

Warning: include(Zend/Log.php) [function.include]: failed to open stream: Too many open files in /www/lib/Varien/Autoload.php on line 93

Warning: include(Zend/Log.php) [function.include]: failed to open stream: Too many open files in /www/lib/Varien/Autoload.php on line 93

Warning: include() [function.include]: Failed opening 'Zend/Log.php' for inclusion (include_path='/www/app/code/local:/www/app/code/community:/www/app/code/core:/www/lib:.:~/') in /www/lib/Varien/Autoload.php on line 93

Fatal error: Class 'Zend_Log' not found in /www/app/code/core/Mage/Core/functions.php on line 247

Open in new window

And this is the URL we are at while viewing this error:


And here is some background information on our environment and other infos:

- Running Magento on a shared server

- Apache/2.0 - PHP Version 5.2.14 - MySQL Version 5.1.32

- We've never had this problem before (after a year of operation).

- We haven't installed any new extension before this problem came up.

- Most answers related to this problem (found on Google) points to available resources issues. Our php.ini has memory_limit set on 128M.

- Could this have something to do with admin session? When we login, the session file that appears in "/var/session/" is way bigger than others. About 130Kb, when most of the session files are all around 4kb. Maybe this is related to available resources and this session issue could be overloading it. Already tried emptying session folder, and browser cookies and cache, but nothing. Our session duration is set at 360000 on Magento admin panel.

- Our site has a frontend script problem on category/filter pages that exceeds maximum execution time (30 seconds), and we are working on resolving this (it's another issue), however, this is not new, and this problem to cancel orders just started happening, so it seems it is not related directly to this issue. But I don't know if a frontend script problem should affect the backend. Maybe only if it would be a resources issue, and that is what this is looking like it is.

  Still on this note, our hosting company told us this frontend issue is consuming way more resources for a page load than it should (on frontend), and that because of this they had to limit resources for our domain so it wouldn't affect other clients on the same shared server. And I'm wondering if this imposed resources limitation could be the cause of this problem, because this problem started happening about a day after they said they've done this.

- Our site receives about 400 visits per day. Already tried cancelling orders on a low traffic time of the day, but it makes no difference.

- Other things to add is that we CAN edit address in order, and do actually anything else on the admin panel, just "cancel orders" that we are not able to do. And the admin panel as a whole sometimes displays "Internal Server Error" on any page, but displays correctly after page reloads. This started happening together with the order cancel problem.

Well.. I hope I've given enough info.

If any additional information is needed please ask and I'll update promptly.

Any help would be a life saver at this point!

Thanks in advance for anyone who can solve this!

Also if you know an alternative safe method to cancel orders in Magento please share.

Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

You will have to talk to the host to see if they will increase the open files limit.
On shared hosting they probably won't
Magento isn't really designed for shared hosting, but there are shared hosters that do specialize in Magento sites and tweak their servers for it.
It is a hungry beast even with minimal products and visitors.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Jose_FAuthor Commented:
Thanks Gary!

Can you confirm 100% there is no other possible cause for this problem ?

Also, can this open files limit increase be done via php.ini ?

If yes, how would this line be ?

Thanks a lot for your help!

No this is a MySQL setting, how much access do you have to the server?
Not going to say I am 100% sure this is the problem but it definitely looks like it, and the shared hosting makes me more certain.
You would really need to contact your host and see if they are willing to increase it, I doubt it because they would be giving your site more dominance over the DB at the expense of other sites.
The Ultimate Tool Kit for Technolgy Solution Provi

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy for valuable how-to assets including sample agreements, checklists, flowcharts, and more!

Jose_FAuthor Commented:

I have ssh access but I think the ssh commands are very limited.

I also think it's a resources issue, but I don't understand why this only happens when we try to cancel orders. Is it because the "order cancellation" process is one of the most intensive processes we could execute in the admin panel ?

Do you know what would be a good limit for this open files setting, for a Magento store on a shared server ?

We probably had a larger limit before they took action to limit us further, so I'm guessing the actual limit for our hosting plan should be able to handle it, the thing is, they have largely limited us due to our current frontend maximum execution time script errors that happens on certain pages.

We didn't have this problem before they announced this limitation on our domain.

So I'm thinking if we fix this frontend issue, and ask them to normalize our available resources, things could go back to normal.

If everything was working fine before, it should work then when they set the limits as before, don't you think ?

Also, would you try to trace this error deeper? How would you do it?

Thanks a lot again for your help!

Most operations in Magento are DB intensive, mainly because of the way it works using linked tables - a single operation in Magento may involve 10+ tables being accessed/updated
Look at trying to add 3000 products, its unbearable. But then look at Magmi which can do the same thing in under 10 minutes - better code.

Optimum setting would depend, what is it now? Probably 1024, try increasing to about 1500

If you are having frontend time issues you should look at any plugins, also having configurable products is a cause for loading delays (see point 1) - the more complicated the configuration options the longer the delay. On one site I changed from configurable to product options which is a lot less intensive.

They restricted you because you (or rather Magento) was using too many resources, namely the DB access.

Tracing the error may be possible but to be honest I wouldn't bother - you know what the problem is, finding the exact cause is not going to solve it.

My best advice would be to move to a specialised host.

Also make sure you are cleaning the db up, Magento stores everything in logs - even if you sneeze it makes a record of it.
Thinking on it further have you run through the optimization tips?
Is there a caching mechanism on the server that you can utilize like APC and Varnish?
There are a few plugins that you can incorporate that can cache pages using things like Varnish and eliminate db calls (or at least keep them to a minimum).
There is one on the plugins page that uses Varnish
Worked quite well even tho there were a few bugs - this caching software can really make your site fly.
Jose_FAuthor Commented:
Thanks again Gary!

We are indeed in the process of implementing a full page cache solution, but unfortunately our shared host doesn't allow Varnish, so we are considering an alternative for now.

And yes, all our products are configurable, so this surely weights up. We have about 140 configurable products, and around 400 associated simple products. To change this would mean re-creating all products, and this is something I actually have considered, but we need time. I think the problem with product options, is that there is no way to have separate stock for each product variation, can you confirm this ? Or there is a way to manage stock for each option ?

About DB maintenance, we do clean the log tables regularly, Magento really fills them up fast.

For now, I've decided to fix the script errors so to ask the host to normalize our resources the way it was before, because the way it was we didn't have this problem to cancel orders.

About the open files limit you mentioned ("1024" or "1500"), is there a way I can check our limit with a simple script or something ?

What is the exact term for this setting, so I can talk to my host ?

I found this: max_open_files

Is this it ?

Is there another important setting that is related to this issue, that we need to keep at a healthy minimum for Magento ?

Thanks again for your great help!

Jose_FAuthor Commented:
Another thing Gary, if I may ask...

Could you share some tips on how I can debug / log the exact cause of this error that shows up in our system.log file:

ERR (3): Notice: Undefined index:  1424  in /www/app/code/local/CJM/ColorSelectorPlus/Helper/Data.php on line 426

This is actually from a color swatch extension that we use, and we get about a hundred lines of this error per day.

There is really something wrong happening here, and even though we need to use full page cache and optimize everything else, we really need to fix this error to solve this whole issue.

I tried a few "Mage::log()" variations before the error line, but couldn't make it work so to log the root of the problem. But it is working, I just couldn't find the right "Mage::log" to make it reveal the problem.

Thanks for any insight...

There is a plugin that adds stock control for product options - but it costs money.

Check my.ini for open-files-limit
Have you got logging enabled?
System/Configuration/Developer/Log Settings

That should record when things go wrong, exceptions etc.
Failing that I would contact the author - sounds like an array is screwed up.

I no longer use Magento so I cannot remember the belly of the beast in too much detail (wrote my own cart instead)
Jose_FAuthor Commented:

Our host normalized our resources and the problem has been resolved!

Thanks a lot for your help!

It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.