Which database version do you use? It's possible that the utf8mb4 takes too long because of your database and table size you have

Hmm since this is in the extraction phase it shouldn't be the database problem. Did you recovered it in the meantime?

I don't know... I never got the update successful message However everything seems to work ok and it shows joomla 3.9.19.
Should i reinstall? Should i restore a backup? Or everything must be ok?

If not, check if all tables have collations starting with „utf8mb4_“ and the value of column „converted“ in table „#__utf8_conversion“ and report back the result here. I don’t think it’s an utf8mb4 conversion issue, but to be sure check this and let us know. Thanks in advance.

You can do 2 things, first check the database administrator/index.php?option=com_installer&view=database and try the reinstall button on the joomla updater this should install missing files if any.

the above are the only ones that don't have utf8mb4

and the link from HLeithner show all ok|

The tables are not core tables so it's ok, I think there was a connection problem with your host and it seams all is good.

:) Thanks! awesome help even though it's not something core related!
Thanks a lot both of you!

@peteruoi we are also seeing this issue when updating from 3.9.18 to 3.9.19 on 4 joomla instances (about 20 more to update).
We have centos 7, apache httpd 2.4, php-fpm 7.3, mariadb 5,5.
I've restarted httpd but with no effect. The update screen hangs at 85.6%

The last line in joomla_update.php is Deleting removed files and folders.

Please reopen this issue.

The last line in joomla_update.php is Deleting removed files and folders.

@level420 That happens after all database changes have been applied, so it is not a database problem. The probelm with this issue here seems to happen at an earlier point of time if the screenshot provided in the description is correct. But maybe the page in the browser just was not updated due to that timeout, so that it shows this earlier stage? @peteruoi What is the last log of that broken update which you can see in administrator/logs/joomla_update.php? Is it the Deleting removed files and folders.?

@HLeithner Shall I reopen this?

@richard67 what is the expected last message in joomla_update.php for a complete update run?

@level420 can you check the browser developer console and check if there is an error message in the javascript console or in the ajax request?

@level420 Here comes the complete log of a successful update from 3.9.18 to 3.9.19, long IP v6 address replaced by xxx.xxx.xxx.xxx for better readablility and a few things anonymized or shortened.

2020-06-02T17:15:18+00:00	INFO xxx.xxx.xxx.xxx	update	Update started by user xx (xx). Old version is 3.9.18.
2020-06-02T17:15:23+00:00	INFO xxx.xxx.xxx.xxx	update	Downloading update file from https://s3-us-west-2.amazonaws.com/joomla-official-downloads/joomladownloads/joomla3/Joomla_3.9.19-Stable-Update_Package.zip ...
2020-06-02T17:15:44+00:00	INFO xxx.xxx.xxx.xxx	update	File Joomla_3.9.19-Stable-Update_Package.zip downloaded.
2020-06-02T17:15:45+00:00	INFO xxx.xxx.xxx.xxx	update	Starting installation of new version.
2020-06-02T17:16:06+00:00	INFO xxx.xxx.xxx.xxx	update	Finalising installation.
2020-06-02T17:16:06+00:00	INFO xxx.xxx.xxx.xxx	update	Ran query from file 3.9.19-2020-05-16. Query text: ALTER TABLE `#__ucm_content` MODIFY `core_title` varchar(400) NOT NULL DEFAULT '.
2020-06-02T17:16:06+00:00	INFO xxx.xxx.xxx.xxx	update	Ran query from file 3.9.19-2020-06-01. Query text: INSERT INTO `#__postinstall_messages` (`extension_id`, `title_key`, `description.
2020-06-02T17:16:06+00:00	INFO xxx.xxx.xxx.xxx	update	Deleting removed files and folders.
2020-06-02T17:16:12+00:00	INFO xxx.xxx.xxx.xxx	update	Cleaning up after installation.
2020-06-02T17:16:12+00:00	INFO xxx.xxx.xxx.xxx	update	Update to version 3.9.19 is complete.

@HLeithner no failed requests and no error messages in the console so far Chrome 83). The view remained at exactly that state as in the screenshot above and now after about 10min it changed to the expected view for a successful update with the message "the site was updated. the new joomla version is now: 3.9.19" (rawly translated from German).

apache access log:

x.x.x.x - - [03/Jun/2020:10:37:16 +0200] "GET /media/com_joomlaupdate/js/json2.js?6746cbc02c51be7052d84af64aa1bf6b HTTP/1.1" 200 3381 "https://my-server.tld/administrator/index.php"
x.x.x.x - - [03/Jun/2020:10:37:16 +0200] "GET /media/com_joomlaupdate/js/encryption.js?6746cbc02c51be7052d84af64aa1bf6b HTTP/1.1" 200 19508 "https://my-server.tld/administrator/index.php"
x.x.x.x - - [03/Jun/2020:10:37:16 +0200] "GET /media/com_joomlaupdate/js/update.js?6746cbc02c51be7052d84af64aa1bf6b HTTP/1.1" 200 8348 "https://my-server.tld/administrator/index.php"
x.x.x.x - - [03/Jun/2020:10:37:16 +0200] "POST /administrator/components/com_joomlaupdate/restore.php HTTP/1.1" 200 58 "https://my-server.tld/administrator/index.php"
x.x.x.x - - [03/Jun/2020:10:37:16 +0200] "POST /administrator/components/com_joomlaupdate/restore.php HTTP/1.1" 200 7522 "https://my-server.tld/administrator/index.php"
x.x.x.x - - [03/Jun/2020:10:37:16 +0200] "POST /administrator/components/com_joomlaupdate/restore.php HTTP/1.1" 200 8770 "https://my-server.tld/administrator/index.php"
x.x.x.x - - [03/Jun/2020:10:37:19 +0200] "POST /administrator/components/com_joomlaupdate/restore.php HTTP/1.1" 200 122 "https://my-server.tld/administrator/index.php"
x.x.x.x - - [03/Jun/2020:10:37:19 +0200] "POST /administrator/components/com_joomlaupdate/restore.php HTTP/1.1" 200 64 "https://my-server.tld/administrator/index.php"
x.x.x.x - - [03/Jun/2020:10:36:11 +0200] "GET /administrator/index.php?option=com_installer&view=update&task=update.ajax&72a7afacc266849d1a64dd7260f8265a=1&eid=0&skip=700 HTTP/1.1" 503 385 "https://my-server.tld/administrator/index.php" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.61 Safari/537.36"

apache error log:

[Wed Jun 03 10:41:01.176717 2020] [proxy_fcgi:error] [pid 30384:tid 140648728405760] (104)Connection reset by peer: [client x.x.x.x:63732] AH01075: Error dispatching request to :, referer: https://my-server.tld/administrator/index.php

can you provide the log from administrator/logs/joomla_update.php ?

@HLeithner and the messages in joomla_update.php are (in German):

2020-06-03T08:37:09+00:00       INFO x.x.x.x        update  Aktualisierung wurde vom Nutzer xxx (xxx) gestartet. Die frühere Version war 3.9.18.
2020-06-03T08:37:12+00:00       INFO x.x.x.x        update  Aktualisierungsdatei von https://s3-us-west-2.amazonaws.com/joomla-official-downloads/joomladownloads/joomla3/Joomla_3.9.19-Stable-Update_Package.zip?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIZ6S3Q3YQHG57ZRA%2F20200603%2Fus-west-2%2Fs3%2Faws4_request&X-Amz-Date=20200603T083707Z&X-Amz-Expires=60&X-Amz-SignedHeaders=host&X-Amz-Signature=b2c87ee25666e9fcf6b39e28fd56ceccaa4f3417eaeaa6208c5629b0139204e3 wird heruntergeladen.
2020-06-03T08:37:15+00:00       INFO x.x.x.x        update  Datei Joomla_3.9.19-Stable-Update_Package.zip erfolgreich heruntergeladen.
2020-06-03T08:37:16+00:00       INFO x.x.x.x        update  Neue Version wird jetzt installiert.
2020-06-03T08:37:19+00:00       INFO x.x.x.x        update  Installation abschließen.
2020-06-03T08:37:21+00:00       INFO x.x.x.x        update  Abfrage von Datei „3.9.19-2020-05-16“. Abfrage: „ALTER TABLE `#__ucm_content` MODIFY `core_title` varchar(400) NOT NULL DEFAULT '“.
2020-06-03T08:37:23+00:00       INFO x.x.x.x        update  Abfrage von Datei „3.9.19-2020-06-01“. Abfrage: „INSERT INTO `#__postinstall_messages` (`extension_id`, `title_key`, `description“.
2020-06-03T08:37:24+00:00       INFO x.x.x.x        update  Nicht mehr benötigte Dateien und Verzeichnisse werden gelöscht.
2020-06-03T08:51:35+00:00       INFO x.x.x.x        update  Aufräumen nach der Installation.
2020-06-03T08:51:35+00:00       INFO x.x.x.x        update  Aktualisierung auf Version 3.9.19 ist vollständig.

Please note the delay between the 2nd and 3rd line from bottom (14 minutes)

It may be that the previous timeouts occurred because of the lower request timeout values set for those instances/servers.

@richard67 seams to be the database update since the utf8 conversation happens after this line.

		try
		{
			JLog::add(JText::_('COM_JOOMLAUPDATE_UPDATE_LOG_DELETE_FILES'), JLog::INFO, 'Update');
		}
		catch (RuntimeException $exception)
		{
			// Informational log only
		}

		// This needs to stay for 2.5 update compatibility
		$this->deleteUnexistingFiles();
		$this->updateManifestCaches();
		$this->updateDatabase();
		$this->clearRadCache();
		$this->updateAssets($installer);
		$this->clearStatsCache();
		$this->convertTablesToUtf8mb4(true);
		$this->cleanJoomlaCache();

If it is the utf8 (which it looks like) the installation seams to hang in the mysql query execution, this query will run till it's finished or got killed by the mysql server (which normally not happens). That means it's possible that the conversation is not complete.

Can you please post the content of the table #__utf8_conversion ?

@level420 Can you please post the content of the table #__utf8_conversion?

content of table #__utf8_conversion:

| converted  |
--------------
| 5,000000   |

5 means ok, the conversion was complete.

btw: those joomla instances timed out have relatively big databases of about 12MByte resulting from large amounts of finder index entries from DOCman documents and lots of articles.

@HLeithner You are right, the conversion comes after the "normal" database changes. But the conversion seems to have ended with success, see previous comment.

@level420 If you can do that on the other sites before the update, clear the finder index before starting the update. That could help a lot. After the update you could reindex again.

the succeeded update where it took 14min for the success message has a db size of 3MByte.

@level420 Finally, can you check on the updated site which had the problem if all database of the CMS core (i.e. not 3rd party extensions) tables have either collation utf8mb4_unicode_ci or utf8mb4_general_ci? If that is the case, the updated site should be ok.

@richard67 do you have some mysql meta information select for me to check this?

@level420 Do you have phpMyAdmin? If so, you can see the collations in the list of tables.

@richard67 It's

SELECT TABLE_NAME, TABLE_COLLATION
FROM INFORMATION_SCHEMA.TABLES where table_schema = '<my-joomla-db-name>'

and it seems that all core tables have got utf8mb4_general_ci as collation.

But it may be helpful then to split the update process regarding collation conversion into smaller steps to avoid the timeout.

and it seems that all core tables have got utf8mb4_general_ci as collation.

That should not be the case. All tables with names starting with #__finder_ (replace #__ by your table prefix) should have utf8mb4_general_ci, but all other core tables should have utf8mb4_unicode_ci.

But it may be helpful then to split the update process regarding collation conversion into smaller steps to avoid the timeout.

The SQL script is not run as one piece. It is split into the single statements, and these are executed then in SQL. I.e. regarding SQL we can't split anything further.

and it seems that all core tables have got utf8mb4_general_ci as collation.

That should not be the case. All tables with names starting with #__finder_ (replace #__ by your table prefix) should have utf8mb4_general_ci, but all other core tables should have utf8mb4_unicode_ci.

@richard67 you're right: the #_finder_ tables have utf8mb4_general_ci and all others have utf8mb4_unicode_ci.

@level420 So I would say the database is ok. If you really wanna be sure, install a brand new 3.9.19 on some testing webspace with some empty database, e.g. locally, then export database (if possible only structure and not content), do the same export on the updated site and compare the exports regarding data structure. The structure should be the same.

@richard67 then maybe write each sql statement into joomla_update.php so we get the information on which table the timeout occurs.

And it would be great to have the conversion in the database repair option in the backend, which would allow to repeat the conversion if it fails.

@level420 So I would say the database is ok. If you really wanna be sure, install a brand new 3.9.19 on some testing webspace with some empty database, e.g. locally, then export database (if possible only structure and not content), do the same export on the updated site and compare the exports regarding data structure. The structure should be the same.

And do this for about 25 Joomla instances? Not really!

@level420 When we've implemented the conversion in some 2016 or so, we had decided not to log each statement because that would have been too much. When a missing conversion is detected, it is already shown in the database checker (Extensions - Manage - Database), and it can be fixed then with the database repair.

Regarding compare the structure it is enough if you do that for the one site you have had the problem first.

For the other sites, if you haven't updated them yet: Would be be possible that you clear the index in Smart search before you start the update and then after the update rebuild the index again? Both can be done with buttons in the backend for the Smart Search component. That could help to avoid that timeout problem.

Any chance to update your database? I mean there shouldn't be a problem with a 3mb database but it looks like the conversation takes too long which is strange.

@richard67 So if the database update fails: is it possible to re-initialize the conversion via the database checker in the backend?

@level420 Not with an explicit button. But in such case there is a database problem shown, which includes the problem that the Multibyte Character conversion has not been done yet, and when using the "Fix" button the conversion is run. If there is no database problem shown in the checker, there is nothing to be done.

@richard67 then we should be done either when there are no errors in the database structure displayed in Extensions -> Manage -> Database or if there are errors shown and we hit the "Fix" button, right?

Right, except if the timeout happens again when using the fix button. As i said, clearing the finder index before the conversion could help to avoid the timeout and other possible problems.

i am lost... Do you need anything from me? The database from the site is around 600mb, and when tried the upload and install the full joomloa 3.9.19 package in executed successfully till the end

@peteruoi on everything fine, it seams we found the problem.

@peteruoi Please check on your updated Joomla if there are database problems shown in "Extensions -> Manage -> Database".

If no problems found, then you are fine.

But if there are problems found, then first clear the index of the Smart Search Component, then use the "Fix" button in "Extensions -> Manage -> Database" to fix the database problems, and if that worked you can go to the Smart Search Component and rebuild the index. This does not need to be done with every update, but this time with the 3.9.19 update it can help. This info also for other readers who might have such problems with the update.

But what should be done after each update, even if successful, is to go to "Extensions -> Manage -> Database" and check if all is ok.

no problems found:)

@richard67 It would be helpful to display a message after the update completed which contains the text which is shown when navigating to "Extensions -> Manage -> Database". If inconsistencies are shown, then inform the user on how to fix this by going to "Extensions -> Manage -> Database" and clicking the "Fix" button.

It would be helpful to display a message after the update completed which contains the text which is shown when navigating to "Extensions -> Manage -> Database". If inconsistencies are shown, then inform the user on how to fix this by going to "Extensions -> Manage -> Database" and clicking the "Fix" button.

@level420 That's a good idea. The only thing to be mentioned is that it is not just to add display of a message. It would mean that after an update the database schema check has to be triggered like it is the case when you visit "Extensions -> Manage -> Database". So it is not that trivial to implement it, but it is possible, and I think I could do that. In fact I thought about this in past but lost it out of focus because busy with other things.

I'll keep it in mind for improvement.

Maybe it can't be added in J3 but in J4, but that's not on me to decide that.

We will see. Stay tuned.

Update: Of course if someone else already has an idea: Go ahead, no need to wait for me in this case.

I think this can be closed meanwhile.