Updater app runs into timeout

ℹ️ Support
, ,
1

I tried to update via updater app (like I did several times before). This time I get in the steps backup and extracting this error: 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> <!-- a padding to disable MSIE and Chrome friendly error page --> <!-- a padding to disable MSIE and Chrome friendly error page --> <!-- a padding to disable MSIE and Chrome friendly error page --> <!-- a padding to disable MSIE and Chrome friendly error page --> <!-- a padding to disable MSIE and Chrome friendly error page --> <!-- a padding to disable MSIE and Chrome friendly error page ----->

During the backup step it also said that I should reload the page later, which I did and then ran into “Nextcloud is in maintenance mode” message. I had to disable maintenance mode via command line and could then continue the update where I left. And at the extracting stage it timed out again. And then again on moving files step.

The update process itself succeeded thanks to the updater app that finished the steps in background and let me continue but it is annoying that I had to disable maintenance mode and restart every step. This never happened before and the last times some steps ran for minutes.

I haven’t changed anything on Apache side but can it be that this is a webserver issue?.

Nextcloud version (eg, 10.0.2):
Operating system: Synology
Apache 2.2
PHP version: 5.6

2

I’ve the same issue.
Nextcloud 12.0.3 -> v.12.0.4
OS Debian Jessie
NGinx 1.12.2
PHP version 7.0.24

3

You can either increase the time spans for timeouts, on larger systems it is better to start the upgrade from command line where normally no timeouts apply. E.g. for Debian:

sudo -u www-data php /var/www/nextcloud/updater/updater.phar

After that you have perhaps to start the occ upgrade command as well and turn off maintenance mode:

  sudo -u www-data php /var/www/nextcloud/occ upgrade
  sudo -u www-data php /var/www/nextcloud/occ maintenance:mode --off
2 Likes
4

I still run into this crap on 15.0.3. In my case its a really tiny instance with only about 1GB of data.
Errors went away after putting extra timeout parameters to Apache’s ProxyPass directive like:
ProxyPass /path/updater/ https://backend/nextcloud/updater/ connectiontimeout=6000 timeout=6000

Connectiontimeout defaults to 5 sec, I guess. This kills the connection if after 5 sec still no data is received from the backend. Timeout specifies the overall timeout even if data is allready transmitted.

Nginx does have a similar directive called proxy_read_timeout 6000s;

1 Like
5

I’m hitting this with the 14.0.2 → 15.0.4 update (running in an unRAID Docker container).

I have no idea how to edit connection timeouts but was able to use the following to make some progress - but not an actual upgrade. (Hopefully others seeing this won’t run into the"Delete old files" error I saw.)

I ended up needing to check ownership of updater.phar (ls -aFl /config/www/nextcloud/updater/updater.phar) which turned out to be user abc then using the following to run the update from the console.

sudo -u abc php /config/www/nextcloud/updater/updater.phar
sudo -u abc php /config/www/nextcloud/occ upgrade
sudo -u abc php /config/www/nextcloud/occ maintenance:mode --off

However, I did end up getting getting the following during the updater.phar step. Oddly, it appeared empty when I looked in the folder…

[ ] Delete old files ...PHP Warning:  rmdir(/config/www/nextcloud/updater/../lib/private/legacy): Directory not empty in phar:///config/www/nextcloud/updater/updater.phar/lib/Updater.php on line 843
[✘] Delete old files failed
Could not rmdir: /config/www/nextcloud/updater/../lib/private/legacy

Update failed. To resume or retry just execute the updater again.

I tried a re-run of the update and ended up getting a different error:

[✔] Verify integrity
[ ] Extracting ...PHP Warning:  require(/config/www/nextcloud/updater/../version.php): failed to open stream: No such file ordirectory in phar:///config/www/nextcloud/updater/updater.phar/lib/Updater.php on line 640
PHP Fatal error:  require(): Failed opening required '/config/www/nextcloud/updater/../version.php' (include_path='.:/usr/share/php7') in phar:///config/www/nextcloud/updater/updater.phar/lib/Updater.php on line 640

So because I have no other option, I decided to ran the updater yet-again and got the following - not really sure how to proceed from there. I like Nextcloud but I must admit - it shouldn’t be this hard…

Nextcloud Updater - version: v14.0.2RC2-1-g21ab216

Step 6 is currently in process. Please call this command later.

Edit: I have no idea if this is the ‘right’ thing to do, but I got out of my “Step 6 is currently in process” loop by deleting the /data/updater-octucxxxxxxx/.step file as described here:

Re-ran the updater, but got the same “failed to open stream” error and again stuck in “Step 6” loop. :frowning:

1 Like
6

The fix that worked for me for this issue was PHP config, at Upgrade stuck at "Step 4 is currently in process. Please reload this page later"

7

See also Upgrade woes -- experiences from ownCloud to nextCloud migration.

8

Since I have no access to the commandline-tool, I finally figured out a way to work this issue out in the updater-tool, when updating to 18.0.6

My Update timed out during download. So I downloaded the new version with the browser and uploaded it via ftp into the folder “data/updater-xyz/downloads”. Then I edited the .step-file in folder “updater-xyz”: I changed “state”:“start” to “state”:“end”. Next I only had to retry the updating-process.

9
  1. click Download now , just download .zip file use your computer.
  2. use scp copy .zip file to your server /var/lib/nextcloud/data/updater-[random string]/downloads/ .
  3. update /var/lib/nextcloud/data/updater-[random string]/.step change start to end
  4. Open Updater again, and click continue on top

check this blog
10

That was causing my timeout issue. Thanks for the informative answer! :slight_smile:

11

I encountered the same issue while upgrading 23.0.0 to 23.0.12 using Chrome.
I switched to Edge and the problem disappeared… sad but true.

Cheers