0

Sometimes i have a "Fatal error: Allowed memory size exhausted" on certain drupal installations with low php memory limit during module or core updates. After such an error i regularly increase this value with the help of my webhoster to avoid this for future updates...

But on the drupal side i'm lost a bit. The system report shows no indication that the update has to be done again and doing it manually shows that there's nothing to update. But this process failed before...

How do i find out if something went wrong during the update.php process?

| improve this question | |
  • 1
    This post handles everything you can do in order to deal with blank pages/memory issues: drupal.org/node/158043 The first thing I would check is the PHP error log on my server. Not sure where your php error log is located: Try phpinfo() and check for "error_log" – Fons Vandamme Feb 10 '15 at 15:44
3

Short Answer

You can't. Though comment F0ns's comment is a good start, depending on your PHP skills you may find this frustrating to impossible.

Long Answer

I am not sure that the easiest resolution is to deal with the (possible) problem after the event.

I would not normally suggest this as an answer except that you begin your question with 'Sometimes', implying that this a is a workflow consideration rather than a specific bugfix.

You should consider your upgrade process in general. Ideally you would put the site into maintenance mode if you absolutely must perform the upgrades on a live site, so there would be no changes to the site during the process. You should always take a database backup before performing core or contrib updates, and this is made easy using backup_migrate module. If you are updating core backup the files as well (if it is contrib simpler to just download previous version)

As long as you know which updates you are applying (I do not recommend applying many at the same time), and what version of core/module you are upgrading from, then you can now easily return to your pre-upgrade state by overwriting the db and files, rather than trying to pick apart potential problems caused by a failed upgrade.

Depending on the usage of your site, it might be preferable preferable to limit administrative access to the site temporarily (or put it into maintenance mode), perform updates on a local clone of the site, and overwrite the live version with the tested, working local version, restoring administrative access.

| improve this answer | |
  • Thanks for your thoughts on this. In the end it's probably less time consuming to backup everything and update a local clone first... I'll consider your suggestions for my future workflows. – Volker Feb 10 '15 at 19:45

Not the answer you're looking for? Browse other questions tagged or ask your own question.