Fatal error: Maximum execution time of 60 seconds exceeded (when fetching update status data)
| Project: | Update Status |
| Version: | 5.x-2.2 |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Hi all,
I think I must have corrupted something in my 5.7 drupal install as update status refuses to work anymore.
If I click on available updates I get the above error. It used to work not long ago. I even deinstalled and reinstalled the module (using the normal deinstall feature). But it refuses to install (same problem above).
Before that I was hacking out modules from my website manually using MySQL Query Browser because a few modules haven't got a deinstaller and I wanted to thin out my install. I followed this procedure:
* deinstalled manually eCommerce, Send SpreadFirefox Affiliates, Webform Report and Proxy Hack modules:
o remove all entry with module name in system table using MySQL Query Broswer:
SELECT * FROM `db225858978`.`motivatedsellers_system` where filename like '%ecommerce%'
o remove all entry with module name in variable table using MySQL Query Broswer:
SELECT * FROM `db225858978`.`motivatedsellers_variable` where name like '%send%'
o and then delete module direcory from sites\modules
Can anybody shed some light on this problem please?
Kind regards,
Marc.
#1
I'm having the same problems, but with XAMPP install on USB Key. Something, I'm able to get past the ''Choose your language'' page, but I can't get past the database setup page without geting this error message...
#2
Try this patch: http://drupal.org/files/issues/update_status_fetch_timeout.patch.txt
Which I posted (but never committed) for #168828-6: "Unable to fetch any information" on manual check
#3
(better title)
#4
I do not believe this will be sufficient. I had an issue with update_status on a D5 install where the server was behind a reverse proxy. The server admin also had outgoing requests blackholed. That meant on *every* admin page, update_status would try to refresh itself and send a request to the mothership. That request would get dropped, and for whatever reason PHP wouldn't realize it and time out for up to 5 minutes, after which the page would continue normally. (I suspect those 5 minutes were not credited to PHP, so PHP didn't time out.).
This may be a separate issue from the one listed here, but it is still a rather serious problem. Increasing PHP's timeout limit won't help. (If it is, I can refile it as a separate issue. However, I no longer have access to that client's site so I cannot test a patch. We simply disabled update_status.)
#5
Then we need a timeout. We should also remember that we failed and make sure we don't keep rechecking on every page. Patches welcome.
#6
So let's fix up the original issue first, because that one is pretty annoying and happens on almost every site that has a bloat load of contrib modules enabled.
grrrr.... d.o attachments again...
#7
I think the right way to solve this is via the refactoring we're discussing over at #238950: Reduce RAM resource consumption. That would fix this problem, too.
#8
Well, since #238950: Reduce RAM resource consumption contains no patches yet, and we actually need to patch update_status on each and every site with the patch provided in #6, and furthermore ensure that it's still patched after an update of the module, I would like to propose to commit this patch as an interim solution until the overall processing time and/or RAM consumption issue has been fixed, please.
You can always do it better, but for now it fixes this is annoying issue. As mentioned before, patch in #6 has been tested on a variety of sites and is actually RTBC.
#9
With I meant completely different servers, like shared hosting, dedicated hosting, PHP as module, PHP as CGI, aso.
#10
Running into the same problem, I think.
The Available updates page will not reload, it keeps spinning for a very long time, and eventually gets back with "Unable to fetch any information on available new releases and updates."
This happens for one site in a multi site install, and it works for others (did not check all of them). This started happening right after I applied a patch to the Contemplate module, but that could be just a coincidence.
#11
@mariuss: Did you test the patch in #6 ?
#12
Yes, I did try patch #6 and in my case it does not make any difference. Safe mode is off.
So I guess I must be dealing with a different issue.
#13
It turns out that in my case it was a DNS issue.
But the patch should have work. I tried with small values for the time limit and I expected the pages to load faster (even if update status was failing), but that was not the case. Not sure why.
#14
@mariuss: I think you're having a completely different issue.
As it stands, we have to apply this patch to each and every Drupal site, which is pretty annoying. I still do not understand why this patch cannot be committed and hence fix this issue for at least all users that are allowed to alter maximum_execution_time at runtime.
Even if it is just a temporary fix that will not work for everyone - what is the benefit from not applying it?
#15
#6 is far from RTBC. @set_time_limit() is evil -- it's slow and it suppresses potential errors. I went with my original patch linked from #2, modified to use 300 seconds (5 minutes).
The benefit from not applying it is that it's a mostly a band-aid masking deeper problems. As crell pointed out in #4, if you're behind a proxy, this code will actually make things worse, not better. But, it's true that updates.drupal.org can sometimes be slow to reply, and if you're dealing with a site with tons of contribs, I could imagine 60 seconds not being enough. So, I committed, although I might live to regret this decision.
I guess I'll just call this fixed, and we can fix it for real over at #238950: Reduce RAM resource consumption. @sun: Feel free to actually help that issue, instead of complaining about my lack of progress. ;)
Thanks,
-Derek
#16
Automatically closed -- issue fixed for two weeks with no activity.