fisharebest / webtrees

Online genealogy
https://webtrees.net
GNU General Public License v3.0
478 stars 301 forks source link

[Feature Request] Upgrade timeout values in the Admin interface #4523

Closed gsmitheidw closed 2 years ago

gsmitheidw commented 2 years ago

Hi,

I run webtrees on a low end device. It's perfectly sufficient hardware for my needs in normal use. However upgrades always seem to require a manual upgrade because of hitting the timeout value.

In the file "....app/Services/UpgradeService.php", I see there are values in constants here:

   private const GUZZLE_OPTIONS = [ 
     'connect_timeout' => 25,
     'read_timeout'    => 25,
     'timeout'         => 55,
];

I presume from reading GuzzlePHP options that I can change 55 to a larger value say 120 seconds and it'll likely upgrade cleanly?

But ideally it would be great to be able for users to amend these values from the web front end in the panel.

fisharebest commented 2 years ago

55 seconds was chosen because most webservers have a 60 second timeout.

If no response is received from PHP in 60 seconds, apache/nginx will usually send a 502 gateway timeout error.

So you are just replacing one error with another. The upgrade wizard will still stop because the "download ZIP file" action will have failed.

gsmitheidw commented 2 years ago

What happened on my this upgrade was as follows - I ran the upgrade in the panel, got the timeout error. I deleted the data/offline. txt text file and opened webtrees cleanly in my browser. It looked like the upgrade worked successfully. Can I trust that seeing the version change has incremented would mean that all is ok? It looks to me that the download happened within the time provided but the unzip operation did not.

I'm using apache2 - and the timeout is 300 so php timeout occurred first. It's Apache 2.4.54 on a Raspberry Pi ("Raspian" Debian 11), so I presume in the pi or Arm variants of Debian have a longer value than others. Certainly I agree 55 seems a sane default for most deployments.

fisharebest commented 2 years ago

Can I trust that seeing the version change has incremented would mean that all is ok?

No. That would simply indicate that one file was copied (app/Webtrees.php).

It looks to me that the download happened within the time provided but the unzip operation did not.

We unzip first, and then copy (move) the files afterwards. These are separate steps, and each one has a success/fail message onscreen.

If one file was updated, then we can assume the unzip worked. and there should be a success message on screen.

But you say that there wasn't - which doesn't make sense. You say that the unzip step failed, but a file was copied.

Based on that, I'm not sure what is going on. Probably best to do a manual upgrade to be sure.

gsmitheidw commented 2 years ago

I don't know if the unzip operation completed successfully or not because the php timeout occurring first meant that was never shown. The unzip may have worked in the background. But unless I knew the order of the files or a log file to indicate success it's hard to figure that out.

Yes I'll do a manual upgrade over what is there just to be sure. For future I'll consider amending the timeout value prior to upgrade. Each upgrade may revert to the default timeout value, so I may have to keep setting prior to each upgrade. Or just do manual upgrades hereafter.

fisharebest commented 2 years ago

I don't know if the unzip operation completed successfully or not because the php timeout occurring first meant that was never shown.

If the unzip operation timed out, then it would not have sent a "sucess response" back to the upgrade wizard page.

And if this request wasn't received, then the upgrade wizard page wouldn't have sent the request to copy the files.

But you say at least one file was copied...

For future I'll consider amending the timeout value prior to upgrade.

This timeout is for fetching the ZIP file - not for unzipping it. These are two separate steps in the upgrade.

You say that you have at least one file from the ZIP - so the fetch presumably worked OK....

gsmitheidw commented 2 years ago

I've started working on a shell script to run a manual upgrade, It's a bit crude at the moment: webtrees upgrade but might be handy for others who stumble across this thread.

fisharebest commented 2 years ago

See my script here:

https://www.webtrees.net/index.php/en/forum/help-for-release-2-1-x/37099-automatic-upgrade-via-cli

gsmitheidw commented 2 years ago

That's a good point in yours about potentially running out of space during upgrade, I should add a few similar checks into mine. Shame GitHub doesn't implement a path to latest including the version number to save me doing some url parsing. In theory with a bit of checking, DB & media backup (and log files for debugging should something go wrong), this could be wrapped into a cron job to automatically upgrade.