Updater Problem: Timeout during Backup: Update from 12.0.1 to 12.0.2

ℹ️ Support
1

*During the update from 12.0.1 to 12.0.2 I got the following error:
(Had same error before during update from 11.0.2? to 12.0.1)

Create backup
Parsing response failed. <html> <head><title>504 Gateway Time-out</title></head> <body bgcolor="white"><center><h1>504 Gateway Time-out</h1></center> <hr><center>nginx</center> </body> </html>

*After click “retry update” same error again.
*Again click “retry update” shortly after the error pops up, it shows:

Create backup
Parsing response failed. Step 4 is currently in process. Please reload this page later.
  • Reload page: Page is in maintenance mode.
  • config.php -> set mantanance mode off
  • Open updater again: Create Backup shows (OK)
  • Click “Continue Update”
  • Update finishes successfully
2

I have the same problem with update from nexcloud 12.0.4 to 13.0.1
but, after 1 week, i always have the message “Step 4 is currently in process. Please reload this page later.” launching the update from the admin panel or from the updater directory …

my nextcloud is on a mutualized hosting at OVH

PHP

Version: 7.0.27
Memory Limit: 536870912
Max Execution Time: 3600
Upload max size: 511 MB

Database

Type: mysql
Version: 5.6.34
Size: 2.7 MB

I have this errors in logging:
|Error|PHP|Zend OPcache API is restricted by “restrict_api” configuration directive at /home/[…]/cloud/lib/private/legacy/util.php#1369 x 3 times
|Error|PHP|Function create_function() is deprecated at /home/[…]/cloud/lib/private/Route/Route.php#155 x 10 or more times

i have made maintenance mode off in config.php, but i still have the problem.
is there other thing to do to restart the updating process from the beginning ?

edit

in config/config.php i change ‘maintenance’ to false
in data i remove the directory updater-[…]
and after that i could run again the updater and it works fine

3

I know that it’s issue is old, but i’m updating from 22 to 23 and it continue happing. The good new is that i discovered how to solve it:

  1. You probably run the web updater and it returned a timeout error in one of the steps (in my case when making backup, and also on removing old files)

  2. when you see that error on web browser, you MUST WAIT FOR 30-60 seconds (it can vary depending on the length of your data to be backed up AND your server speed) and then REFRESH webpage (classic F5 keyboard).

This is possible because although the webpage showed a “non-response from server” like answer, the server is STILL RUNNING THE LAST CALL… so you only must give it time to finish the last step task :slight_smile:

  1. Maybe, when reloading updater page you will see a text message “error” saying something like “the server is still doing the last request step”… so you must waiting for another minute time, and try again with F5.

  2. Finally, when the PHP process at server is finished, your reload of the webpage (using F5) will be without errors: all the steps already done will be marked as green-tick OK. Then, you must click the “continue with update” button :slight_smile:

Cheers.

4

@caos30

Thank you for the tipp. But i think the best way is - if possible - not to use the web updater.
On one of my Managed Nextcloud (only web updater) the web updater works fine. No timeout problems.

On self installation Nextcloud i use
sudo -u www-data php /path/to/nextcloud/occ /path/to/nextcloud/updater/updater.phar

Because of risk of network aborts while upgrading i use ssh and then tmux on the server.
Command to re-attach or new if not exists: tmux attach || tmux new

1 Like
5

Yes, it probably is a best/safer way to make the update. Maybe because i’m a web developer have the tendence to use web browser whenever is possible. Hehehe, except to use “web shell consoles”… which is something that i’ve never had very trust.

Your suggestion to use tmux is very interesing!! yes… it will avoid interruption of connection between your remote location and the server! yeah!!

But i think that you also must to check php-cli settings to modify max_execution_time limit. Or is it not necessary? i’m not very sure about it.

Cheers!
Sergi

6

I never had problems with using “updater.phar”.

7

I ended up with a trashed system last night due to failed upgrade to 27.1.2 from 27.1.0. It failed to run the backup, as often happens due to timeout. But it then failed to extract the documents due to version.php missing. So switched to manual but whilst deleting the .step file allowed updater.phar to run but failed on extracting.

When I looked in the nextcloud folder, all the source files were missing. I suspect this is because they had been moved into the backup folder ready to be overwritten by the new extraction. I started to panic but know enough about the architecture to know that I can could manually unzip the original version - which worked! Albeit with the original version.

The moral of this story is make sure you have a backup before any upgrade. I foolishly didn’t run the Azure backup of the VM which only takes 10 minutes to create the snapshot.

But also, considering the backup often times out, is there any setting you can change to give it more time for the backup?

Or is the other moral of the story to always run updater.phar manually from the console?