Create backup - Parsing response failed. Step 3 is currently in process. Please reload this page later.

[stefan123t]

Current error message is:
Create backup
Parsing response failed. Step 3 is currently in process. Please reload this page later.

I can not alter/update the PHP max_execution_time parameter being on a shared hosting env.

When running the update on said shared webhosting system the backup step 3 times out while copying the files. There is no option to resume the copying of files from where it left due to the recursiveDelete($backupFolderLocation); eventually also running into the same timeout.

I can retry several times using the Retry update button without success.

The result of removing the .step file and pressing the Retry button several times after the first timeout is reported in the updater.log:

2019-12-05T07:52:30+0100 ej4tAJs27j [info] request to updater
2019-12-05T07:52:30+0100 ej4tAJs27j [info] currentStep()
2019-12-05T07:52:30+0100 ej4tAJs27j [info] POST request for step "3"
2019-12-05T07:52:30+0100 ej4tAJs27j [info] startStep("3")
2019-12-05T07:52:30+0100 ej4tAJs27j [info] createBackup()
2019-12-05T07:52:30+0100 ej4tAJs27j [info] backup folder location exists
2019-12-05T07:58:18+0100 47yeJCqHrX [info] request to updater
2019-12-05T07:58:18+0100 47yeJCqHrX [info] currentStep()
2019-12-05T07:58:18+0100 47yeJCqHrX [info] Step 3 is in state "start".
2019-12-05T07:58:19+0100 erF0CelErD [info] request to updater
2019-12-05T07:58:19+0100 erF0CelErD [info] currentStep()
2019-12-05T07:58:19+0100 erF0CelErD [info] Step 3 is in state "start".
2019-12-05T07:58:20+0100 kteQ1WBhiB [info] request to updater
2019-12-05T07:58:20+0100 kteQ1WBhiB [info] currentStep()
2019-12-05T07:58:20+0100 kteQ1WBhiB [info] Step 3 is in state "start".

As you can see retry update has no effect.

Here is my updater.log with the past updates since NextCloud 12 till version 16.0.3.0 until now failing with version 16.0.6.0:

updater.log

[stefan123t]

I am aware of the following help forum entry, which is not applicable as I am on a shared hosting env. Also space is sufficiently available 10GB of 50GB used and file ownership has been checked and updated via the shared hosting menu.

Please help us to fix UPDATE ERROR FROM 16.0.3 TO 16.0.4 - It is frozen in Step 3 is currently in process. Please reload this page later
https://help.nextcloud.com/t/please-help-us-to-fix-update-error-from-16-0-3-to-16-0-4-it-is-frozen-in-step-3-is-currently-in-process-please-reload-this-page-later/60335/4

My assumption is that the copying of the backup files takes longer than the default max_execution_time and therefor breaks step 3 somewhere in between. The target nextcloud-16.0.3.0 directory has been created and contains already 32.233 items totalling 288,6 MB. It eventually might have (almost) finished already.
Old backups I have were almost same size, eg. nextcloud-15.0.10.0 is 294,2 MB with 26.123 items.
Also filesystem is rather spacious, according to Properties dialog.

[stefan123t]

Calling the https://example.com/nextcloud/updater/ will return only the partial response: "Step 3 is currently in process. Please reload this page later."
Ie. the index.php does not allow reloading of the Updater page with all the steps and the option to "Retry Update", while the button itself on the page I still have open only returns the above error message from the updater, but does not really trigger a new retry of the backup step from where it left off.

To fill in the max_execution_time value here is the preset from the hosting provider: max_execution_time: 60 s

Any other questions regarding failure situation just ask.

[stefan123t]

In a way this is similar to nextcloud/server#10082 and nextcloud/server#13990 which are suffering from similar limitations.

It would be beneficial for the updater to be more resilient and allow resume of backup, download and move file / cleanup steps, as they can take pretty long (more than the default 60 seconds in this case).

If the connection between client (SPA) and server (updater/index.php) expires the current step can not be resumed, it will retry the step from beginning. It should be sufficient to give a status update, e.g. files backed up, bytes downloaded, files moved, files cleaned up and continue the necessary actions for the step.

[stefan123t]

Adding screenshot for evidence

[stefan123t]

Funny, I retried it after more than two weeks with the Tab still open in my browser and somehow it succeeded to get past the dreaded third step with the newer upgrade to 16.0.7. But I doubt something to the updater.php has been changed without me noticing.

I kept my fingers crossed so that I do not run into #249 and it worked so far to succeed to 16.0.7.

I actually would like to get to NC 17, but I guess I have also been hitting #250 up till now, as 16.0.6/16.0.7 were the only available updates, but not 17.0.1.

See new screenshot from 2019-12-23

[kesselb]

updater/index.php

Lines 1267 to 1268 in 96234eb

	ini_set('display_errors', '0');
	ini_set('log_errors', '1');

We should try to overwrite the default limits here. This will probably fix this kind of issues for some people. If higher limits not allowed the webspace is not capable of running nextcloud. Still the manual update is always possible.

[bpcurse]

I've just encountered this updating 18.0.1 RC1 to 18.0.1 RC2 on a server with root access. On a second try it succeeded.
Running manjaro i3, nginx 1.16.1, php 7.3.11, mariaDB 10.4.10

The question is, why is the updater not able to parse a simple gateway timeout error and return something more meaningful to the user?

It could instead return something like:
Gateway timeout error, please retry the update. If the issue persists please have a look at https://some_site_with_specific_help_content.

[stefan123t]

1. As far as I have seen the code the Webpage is only loaded once. Any further calls to the updater simply return the status message.
2. If the updater is stuck at a certain step it is only by luck that it will get past the dreaded timeout. Though the updater could call / trigger the server every X seconds as the AjaxCron does it when NextCloud is running normally.
3. If the actions within the steps are either more granular (ie. keep a list of files to backup etc.) or at least re-entrant, then the Retry Update button would have more effect than just returning the same step status as before. That way the server could progress each step little by little.
4. If the response from the Server is having some Http status (504) there could be a cleaner error message. But @bpcurse mentioned he was able to retry and succeed.

[kesselb]

If your shared hosting has strict limitations I would recommend to use the shell to update or the manual update. A web server involved in a update process is always a point of failure for such long running operations.

Making it possible to skip the backup or retry able without starting from scratch sounds like a plan. Patches are always welcome ;)

[rasos]

Same issue here, it stopped backing up after ~30 apps (total 73 including built in apps). We rely on a rather slow NFS mount and have a 1,1 GB mysql DB. No chance to restart the upgrade from within the web UI.

Yes, please allow to skip the backup.

What we try now is to do all steps manually (backup, move apps, download new version, remove, continue with occ). This is our step-by-step guide (in German language). Successfully upgraded to NC 17.0.7.

[kesselb]

Same issue here, it stopped backing up after ~30 apps (total 73 including built in apps). We rely on a rather slow NFS mount and have a 1,1 GB mysql DB. No chance to restart the upgrade from within the web UI.

If you are able to upgrade via cli - do it ;)

Yes, please allow to skip the backup.

I see three options to add this feature:

• Build it your self (and contribute it)
• Contact Nextcloud GmbH and ask them to implement it.
• Pay me to implement it ;)

But again! Update via cli (and restart php-fpm afterwards) is the most reliable way to upgrade.

[stefan123t]

Dear @rasos thanks for feedback.

I actually made an upgrade from 16.0.7 through 16.0.11 and 17.0.7 to 18.0.6 last week. This time again the automated upgrade failed because of some spreed issue at some stage.
To be honest, I would rather like an option to skip the backup if it repeatedly fails.

I have in the end resorted to manual upgrade (i.e. unzipping the files locally and transfer them via SFTP, which takes about 50 minutes for 16.000 small files). This seems to have worked seamlessly and I might use it in the future as it is more predictable than the automated approach on my shared hosting env, where I do not have shell access.

I wonder if there is an option to have the new version downloaded manually and just stage the whole zip file in the nextcloud-data/updater-/downloads folder and have some PHP process unzip the files on the webserver with right permissions. This usually takes about 10 seconds on my desktop and probably not much longer on the server.

@kesselb any suggestions on how one would implement the two features, ie. skipping steps and/or starting at a specific step in the automated upgrade process.
As far as I understood that process, it keeps track in the nextcloud-data/updated-/.step files.
Though for the manual upgrade approach it doesn't update / touch this file.

Where should I start implementing it myself, if I would like to download and stage the zip file in the above downloads folder and continue without/after a manual backup (a move on the server is again an atomic SFTP operation) ?

Kind regards,
Stefan