Sites freezing in middle of update process

Support Version 1.x
21

Just to add I can say the same has happened a few times to me also. I just deleted the maintenance file in root. It was also with synergy hosting.
Did not really have time to dig deep into why it happened i just needed the site up. It appeared to me it was stuck at retrieving the archive from github. I think its was github…

Synergy is a Litespeed web server.

2 Likes
22

I just set up a new site on Zuver, fresh install of WP4.9.11 and the migration plugin worked perfectly, as did the upgrade from CP1.0.1 to CP1.0.2.

Here’s another weird bit of random information.

On the sites that do work the browser shows a RED spinning circle icon in the browser tab. On the sites that don’t work the spinning circle is GREY.

23

I think Zuver is VentraIP and VentraIP is Synergy, probably all the same litespeed web server.

24

@mathewcallaghan When you have time, can you check the files on those sites and see if there are any “remnants” left in your uploads or upgrade folders in wp-content.

I’ve found a lot of junk in there in the past that needed removing. I am thinking now it was probably leftovers from processes that never really finished and got cleaned up properly.

25

I just checked three sites and all the upgrade folders are empty. Nothing unusual.

26

What about uploads? I found temp files in there too.

27

There is nothing unusual.

28

OK - thanks Mathew. Must just be me. :roll_eyes:

29

Just wanted to say that I have run the update on a Litespeed server, and everything worked perfectly. So I think that detail might be a red herring.

1 Like
30

@ozfiddler Not sure what you’re trying to achieve. Are you trying to debug the upgrade process (for interest’s sake) or actually unable to upgrade your site?

The reason I asked is, why not simply do the manual upgrade as described here.

Just a thought. But I don’t really know what I’m talking about :thinking:

I know it’s for migration, but wouldn’t it be just as suitable for upgrading?

31

@Aussie - yes, I can do the upgrade a number of ways. But, in general, it’s not good to have an upgrade process that fails midway and leaves your site down. It’s the sort of thing that makes a user think: “This is no good, I’m going back to WP”.

It seems to be happening randomly on a few servers. Would be nice to know why.

3 Likes
32

Yeah of course as they have to be identical configurations :slight_smile:

33

I agree with @ozfiddler an upgrade process that fails is not good. This is one of the reasons I like wp over drupal for example. It is a very solid foundation.

2 Likes
34

I had a similar problem when I was trying to do the automatic update on my site, it got stuck on the unpacking stage. I waited a while but nothing happened, so I right clicked on the Dashboard tab and opened in a new window, which at the top reported an update was available.

When I the tried again, presuming there was an error, as the site never as far as I know went into maintenance mode, it said i had to wait 15 minutes as it was already updating or tried to (can’t remember the exact wording).

So I waited and tried again and it updated without any problems, so just presumed the fault was with the server i was on, I thought perhaps it was doing maintenance so my site temporary lost connection.

Anyway the update completed ok, so didn’t think anything of it.

3 Likes
35

Which is why I wrote “might”. :wink:

2 Likes
36

Did you get any errors in the logs.

I’ve just tried the troublesome site a few more times and I am now getting this:

[09-Sep-2019 08:45:02 Australia/Sydney] PHP Fatal error: require(): Failed opening required '/home/avmaorga/public_html/wp-includes/load.php' (include_path='.:/opt/alt/php72/usr/share/pear') in /home/avmaorga/public_html/wp-settings.php on line 19 [09-Sep-2019 08:46:03 Australia/Sydney] PHP Warning: require(/home/avmaorga/public_html/wp-includes/load.php): failed to open stream: No such file or directory in /home/avmaorga/public_html/wp-settings.php on line 19 [09-Sep-2019 08:46:03 Australia/Sydney] PHP Warning: require(/home/avmaorga/public_html/wp-includes/load.php): failed to open stream: No such file or directory in /home/avmaorga/public_html/wp-settings.php on line 19 [09-Sep-2019 08:46:03 Australia/Sydney] PHP Fatal error: require(): Failed opening required '/home/avmaorga/public_html/wp-includes/load.php' (include_path='.:/opt/alt/php72/usr/share/pear') in /home/avmaorga/public_html/wp-settings.php on line 19 [09-Sep-2019 08:47:02 Australia/Sydney] PHP Warning: require(/home/avmaorga/public_html/wp-includes/load.php): failed to open stream: No such file or directory in /home/avmaorga/public_html/wp-settings.php on line 19 [09-Sep-2019 08:47:02 Australia/Sydney] PHP Warning: require(/home/avmaorga/public_html/wp-includes/load.php): failed to open stream: No such file or directory in /home/avmaorga/public_html/wp-settings.php on line 19 [09-Sep-2019 08:47:02 Australia/Sydney] PHP Fatal error: require(): Failed opening required '/home/avmaorga/public_html/wp-includes/load.php' (include_path='.:/opt/alt/php72/usr/share/pear') in /home/avmaorga/public_html/wp-settings.php on line 19

37

…and of course when the support team at Synergy tried it, it went through perfectly.
:man_shrugging:

I give up.

38

I have been thinking some more about this thread. First of all this is definitely not the experience we want people to have with ClassicPress, and of course I agree with this:

From the errors you posted, it looks like sometimes the update is aborting partway through the process. This may leave files in an inconsistent/broken state.

It is pretty difficult to identify an exact cause for this issue, because it doesn’t happen consistently even on the same server, as you’ve seen. I have also never seen this issue myself. However here are a few factors that are possibly relevant:

  • The upgrade process will attempt to set an execution time limit of 5 minutes, which should be much more than enough for an upgrade to complete under any circumstances, but hosts can choose not to honor this request which makes a failure more likely.
  • Exceeding the memory limit during an upgrade request is also a possibility.
  • Servers with slower download speeds (to download the upgrade package) or disk access (to unpack it) would take longer to process an update and therefore be more likely to experience a timeout.
  • Shared hosting servers with many clients will experience higher load, taking a bit longer to do just about everything, and therefore failures are more likely in these environments too.
  • The first update attempted on a given site would be more likely to fail, since none of the files being upgraded would be present in the server’s filesystem cache.
  • WordPress does partial upgrades where possible, only overwriting the files that need to be updated. We have not implemented this yet. (This would help with upgrades in between ClassicPress versions, but not so much with migration from WordPress as almost every file needs to be changed.)

This theory about the upgrade process being killed before it completes is definitely what is happening resulting in the above errors, but it does not explain everything. For example, I would expect any execution time or memory limit errors to appear in the error log also.

Still, the hosting environment is a huge factor in this type of issue, and one or more of the above factors coming into play would be enough to cause this. If you want to prove this for yourself then you can try the upgrade on a private server backed by solid-state storage and good network bandwidth (for example, Digital Ocean) and it will complete in 5-10 seconds every time. However this is not a feasible option for every site, and part of the appeal and success of WordPress and ClassicPress is that they can run almost anywhere.

So here is what I think we should do in order to improve the robustness of the upgrade process:

  • Launch the upgrade as a background process using an AJAX action. The initial action should just start the upgrade without waiting for a response, and it should write to a “journal” file which indicates its progress.
  • The upgrade page should poll for the current status of the upgrade using this “journal” file on the backend, and show progress messages via AJAX instead of during the course of a “normal” page load as it does today.
  • The upgrade page needs to be able to detect if the upgrade has “stuck” and re-initiate it. The upgrade process in the backend needs to know how to resume from a partial update.

This should fix any and all issues with upgrades aborting partway through and also output buffering making the upgrade appear to “freeze”. (If output compression is enabled at the server level I think this will also effectively cause output to be buffered until the page load finishes, which doesn’t play nice with the way the upgrade process currently works.)

A couple of open questions here:

  • When JavaScript is disabled, what should happen? Should the upgrade proceed as it does today, or should we block it altogether?
  • The above plan makes sense for user-initiated upgrades, but what about truly automatic upgrades via wp-cron? I have not seen any reports of “my site broke itself” so maybe this code path doesn’t actually need any changes?
  • This is a big chunk of work, so how do we schedule it? Should we delay v2 in order to improve the robustness of the upgrade process?

Finally another thing that would be helpful is a way to see this issue myself, @ozfiddler I will reach out to you separately about this.

5 Likes
39

Thanks for looking into this James.

Yes. I do think this is happening. On one of the sites that was causing problems (but I thought eventually worked) I have just had a Shield warning about a file that was not recognised. When I investigated I found it was the edit-comments.php file, which ended abruptly at line 292 (there should be 334 lines).

I’m not sure about it being a hosting environment issue. I have sites on “budget” hosting and “good” hosting and had problems on both, and also no issues on both.

40

And I suspect this is related. I’m finding this sort of thing in my uploads folders:

files
files673×520 74.2 KB