@prbt2016 opened this Issue on November 27th 2020

Hello,

I was in the process of upgrading Matomo from 3.14.1 to 4.0.1 on Centos 6.9 with PHP 7.2.24, MYSQL 5.5.62, Apache 2.2.34.
However when I click on 'Upgrade Matomo', I get the following error i.e :

Critical Error during the update process:
Mysqli statement execute error : 
Duplicate entry '55cdd8c124c5596e271454c6624a8cc3c6acf2d9a93502acb225dd897d1ab5df' for key 'PRIMARY'

Here is the attached screenshot of the same :

matomoerrr

Could you please replicate and fix this issue?.

@keesbran commented on November 27th 2020

I had the same problem but was able to upgrade after changing the version number to 4.0.1 in the 'option' table as noted in the error message.

But that introduced a new problem. I can't login anymore. This is without error message. I can change the password, which shows that the update seems to work correctly on the server, but with the new password logging in is still impossible.

@C0rn3j commented on November 27th 2020

Same issue for 3.14.1 -> 4.0.1 on Arch Linux.

nginx-mainline 1.19.3
php 7.4.13
mariadb 10.5.8

I updated the app, ran ./console core:convert-to-utf8mb4 and upon running sudo -u http php ./console core:update I get the same issue.

The log isn't very clear as to where the issue is happening.

matomo_upgrade.log

@sgiehl commented on November 27th 2020 Member

Could you maybe check if the table matomo_session has an entry with the id reported as duplicate?
If so it should help to simply truncate that table (which would log out all users)

@C0rn3j commented on November 27th 2020
MariaDB [matomo]> select * from matomo_session where id like '33fea16f739e0d5a5c1fa3087ea2a1be99af881fc8a976ae8a5ed2ff1e2e2%';
+----------------------------------------------------------------------------------------------------------------------------------+------------+----------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| id                                                                                                                               | modified   | lifetime | data                                                                                                                                                                                                                                                                                               |
+----------------------------------------------------------------------------------------------------------------------------------+------------+----------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| 33fea16f739e0d5a5c1fa3087ea2a1be99af881fc8a976ae8a5ed2ff1e2e224dd7f91f684587416fca1fba6b35377af38f3e65c1598633238e910c8e4500e01d | 1606468842 |  1209600 | a:1:{s:4:"data";s:264:"YToyOntzOjI2OiJMYW5ndWFnZXNNYW5hZ2VyLnNlbGVjdGlvbiI7YToxOntzOjU6Im5vbmNlIjtzOjMyOiI3NjhhNzNlNTU1MTdkMWIzMzk2YzMzZjAzNWNjOWJhNyI7fXM6NDoiX19aRiI7YToxOntzOjI2OiJMYW5ndWFnZXNNYW5hZ2VyLnNlbGVjdGlvbiI7YToxOntzOjQ6IkVOVlQiO2E6MTp7czo1OiJub25jZSI7aToxNjA2NDY5NDQwO319fX0=";} |
+----------------------------------------------------------------------------------------------------------------------------------+------------+----------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.001 sec)
MariaDB [matomo]> truncate matomo_session;
Query OK, 0 rows affected (0.714 sec)

That indeed seem to have helped, the update is now going through.

EDIT: Update went through, I can access the app, but it's kinda broken, but I guess that's for another issue.

SQLSTATE[42S22]: Column not found: 1054 Unknown column 'log_visit.config_director' in 'field list' - in plugin DevicePlugins.

EDIT2: Reinstalling matomo and rebooting the server fixed the above, for some reason.

@sgiehl commented on November 27th 2020 Member

Ok. Thanks for checking this. Will look into it how to prevent that error.

@prbt2016 guess truncating that table should help for you too.

@keesbran you might need to set back the version number in the option table, so the update will be triggered again

@utrenkner commented on November 27th 2020

For information (and maybe others who experience the same problem).

Our installation was running 3.14.1, update via web did produce the same error, update via command-line (as suggested for high-traffic sites) also the same error. Had to go to the database and truncate table piwik_session (or truncate table matomo_session on newer installations). Then, running the command-line the suggested command php /<path>/<to>/matomo/console core:update (login into the backend would produce the same error again - update via command-line must be done immediately after truncating matomo_session or piwik_session, respectively).

Thanks for the great software. And the help, here!

@Findus23 commented on November 27th 2020 Member
@keesbran commented on November 27th 2020

Hi, I can confirm that the solution from @sgiehl worked for me. I changed the the version_core back to 3.14.1, ran the updater from the terminal and am now able to login again and the updater changed the version number to 4.0.1

thanks!

kees

@Flaschenzug commented on November 27th 2020

Could you maybe check if the table matomo_session has an entry with the id reported as duplicate? If so it should help to simply truncate that table (which would log out all users)

I couldn't find an entry with the session.

Hi, I can confirm that the solution from @sgiehl worked for me. I changed the the version_core back to 3.14.1, ran the updater from the terminal and am now able to login again and the updater changed the version number to 4.0.1

Can't confirm that. version_core ist defined as 3.14.1 in my settings (database)

So I Truncated the table piwik_session and reload the updater.
Now it works again. Thanks for the quick support.

@keesbran commented on November 27th 2020

Can't confirm that. version_core ist defined as 3.14.1 in my settings (database)

To be clear, this is what I did:

  1. I updated normally and got the error from the first entry
  2. changed version_core to 4.0.1
  3. updated from terminal
  4. update went well but impossible to login
  5. changed version_core back to 3.14.1 as @sgiehl mentioned
  6. ran the update again
    7 was able to login again, all is working as expected and:
    8.the version_core is changed to 4.0.1 by the updater

kees

@jameshibbard commented on November 27th 2020

The ~fix~ workaround listed above worked for me, with the additional step that I had to truncate the session table.

@C0rn3j commented on November 27th 2020

@jameshibbard That's not a fix, changing the version_core is wrong in this case.

Just truncate the session table.

@jameshibbard commented on November 27th 2020

I tried truncating the table. On its own, this didn't work.

@tsteur commented on November 27th 2020 Member

There's a PR in https://github.com/matomo-org/matomo/pull/16829/files

Does it help to adjust the file core/Updates/4.0.0-b1.php with that patch and then try to redo the database upgrade? Or do you no longer see the DB upgrade screen?

@tsteur commented on November 29th 2020 Member

This was fixed in 4.0.2.

If you experience this issue applying the patch from previous comment should help. Let me know if this is not the case and we'll have a look what else can be done.

Executing the SQL query DELETE FROM matomo_session before the update might help too.

This Issue was closed on November 29th 2020
Powered by GitHub Issue Mirror