Hello,
While upgrading through automatic update to Matomo 3.8.0-b4, from 3.8.0b3, I have got this message :
""Error in Matomo: Mysqli prepare error: Table 'piwik.piwik_brute_force_log' doesn't exist" while reading response header from upstream, client: xxx.xxx.xxx.xxx, server: domain.tld, request: "POST /index.php?module=CoreUpdater&action=oneClickResults HTTP/2.0", upstream: "fastcgi://unix:/var/php-nginx/xxxxxxxx.sock/socket:", host: "domain.tld", referrer: "https://domain.tld/index.php?module=CoreUpdater&action=oneClickUpdate"
Then the database upgrade screen appear as usual. Process.
All seems to have been well completed so Matomo is fonctional.
So, report it in case I missed something.
Thanks,
Eric
See also https://forum.matomo.org/t/updateprobleme-3-8-0-b4/30909
Seems like a regression from #13472
Interestingly the same update worked fine for me. (from 3.7.0)
I also experienced this issue a few times, to fix this problem please run the following SQL query:
CREATE TABLE `brute_force_log` (
`id_brute_force_log` bigint(11) NOT NULL,
`ip_address` varchar(60) DEFAULT NULL,
`attempted_at` datetime DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
ALTER TABLE `brute_force_log` ADD KEY `ip_address` (`ip_address`);
Note: you may need to replace brute_force_log by piwik_brute_force_log
I don't think we'll be able to fix it so this manual workaround might be the best option
Hello,
At now, through upgrade process, thus one error was displayed, I have the table created as this :
CREATE TABLE `piwik_brute_force_log` (
`id_brute_force_log` bigint(11) NOT NULL,
`ip_address` varchar(60) DEFAULT NULL,
`attempted_at` datetime DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
ALTER TABLE `piwik_brute_force_log` ADD KEY `ip_address` (`ip_address`);
This table is empty.
If I have understand, as my Matomo database is prefixed with piwik_, I just have to let it as it is ?
Thanks,
Eric
@eldk Sounds good. If someone enters an incorrect password it should show up in the table.
@mattab The question is if this is just the normal "update-failed-for-whatever-reason" or if something is special about this update. I was just suspicious because two people reported the same thing, but maybe that was just bad luck.
matomo.example.com/ or matomo.example.com/index.php) which should prompt you to run the upgrade, which should resolve the issue?(Edited above) I think the problem is that we added a couple different updates in beta4, (there was no 3.8.0b3) so if people use Matomo from Git or so, they would have had a partial update for a few days. It should only have happened I think when Matomo used from Git? closing as I don't think it's a bug
For what it's worth, I ran into this when updating from 3.8.0b2 using autoupdate, not Git. Also another more pressing issue with being unable to login, but I think that's separate so I'll file it separately.
ran into this when upgrading 3.7.0 to 3.8.0
i clicked "back to matomo" and it took me to the database upgrade screen
I clicked Continue and it asked me to sign in (!?)
i signed in and it seems to work ok... (so far)
Like @pavarnos but happened when updating from 3.6.0 to 3.8.0 release. The table was created, however, and everything seems to work.
Just updated 2 Matomo Installations to 3.8.0 release and both failed with this error. There seems to be something wrong with the db upgrade scripts. According to #13990 maybe a lot more...
Same problem when upgrade form 3.7.0 to 3.8.0
So I click on Go to Matomo and then on the "green button" to upgrade.
Only 3 Matomo go on. 6 Matomo gave a 503 error : I refresh and I came back to Matomo.
All my installations seem to be updated.
Same as @AlainRnet
Got this error while upgrading from 3.7.0 to 3.8.0. Found this thread since this is the only one mentioning this table.
Checking the DB, everything is good, the table is here.
Everything seems to work as expected.
Looks like my hypothesis above was wrong and there really is an issue to investigate and fix
Same issue for me. Upgrade from 3.7.0 to 3.8.0
Table does not exist in the database!
+1 with this issue, updated from 3.7.0 to 3.8.0. Manually creating the table solved the issue - not sure if we missed updating steps now though.
I just clicked on "Back to Matomo" and then continued the upgrade process. The table was created afterwards and everything seems to work.
matomo.example.com/ or matomo.example.com/index.php) which should prompt you to run the upgrade, which should resolve the issue?Same error here. And yes, if i visit the root page, the database upgrade runs.
Same message. "Back to Matomo" and then continued the upgrade process. worked out. thanks.
The changelog should be updated:
This release does not contain any major database upgrade.
@J0WI
The changelog is correct, this update doesn't include any majore database upgrades that change the database scheme in a way that migrations can take hours on huge instances, but instead only a database table is added which should be very quick.
But I agree that this could be made more clear in the future.
i can't login in two different installations.
First the table doesn't exist message while upgrading, then i checked it.... they are created.
I ran into the same issue of the table not existing. I clicked back to Matomo it prompted me to do a DB upgrade. I clicked upgrade and then I got a 500 error. Then I clicked the Back button and it then prompted me to log in and it seems to be working now. But I haven't checked the actual database to see if the table was created or not yet.
If you are able to get to the login page but submitting does nothing except clear the form info and loop back (not even an error message), flushing your cookies may help; it did for me.
flushing the cookie, helps me to login again! :-)
Um, kinda seems like 3.8 should be pulled before this ricochets around the rest of the Internet.

I'm currently entirely unable to use Piwik. Clearing cookies doesn't help. I guess I'll run that SQL command above and see if things magically get better....
FWIW, after I got the first error about piwik_brute_force_log not existing, I got the screenshot above. I went and created the table, as mentioned above, but continued getting the same screenshot above.
When I used the i_am_super_user parameter that it recommends (something that seems more than a little insecure, but onwards), I got an error page that explained that:
"Unable to write in the cache directory" (/var/www/piwik/tmp/templates_c/5a)
I looked in that directory and saw a bunch of tmp directories owned by root. Perhaps they got made temporarily during the failed upgrade attempt? Anyway, I fixed them with:
cd /var/www/piwik/tmp/templates_c
sudo chown -R www-data:www-data *
I then tried refreshing the i_am_super_user page, and it gave me the "DB Upgrade Required" page. Good! I ran that, and it returned a generic 500 error page. I refreshed that, and I guess now I get to log in. Good?
I'm always impressed with how smoothly Piwik upgrades go, but this one has been a mess. Cascading errors perhaps.
Good?
Good
updating two 3.7.0 to 3.8.0, I got error about missing table, I hit "back" and it promote me to update database on both instance. After that both works fine.
@diosmosis as people affected by this issue, do we have to do anything to prevent this from happening, or do we have to create that table by hand? or will it be created for us with next update?
@diosmosis as people affected by this issue, do we have to do anything to prevent this from happening, or do we have to create that table by hand? or will it be created for us with next update?
I think table has been created in spite of everything.
As indicated above, just click on "Go to Matomo" and the update continues correctly.
I think table has been created in spite of everything.
This is correct, if the table hadn't been created, you would still be getting the same error.
Thanks for clearing this out.
I went to the root page and it did NOT create the table, ended up having to create manually. (I confirmed my Matomo MySql account has permissions to CREATE and ALTER).
After manually creating the upgrade seems to have finished.
Most helpful comment
Looks like my hypothesis above was wrong and there really is an issue to investigate and fix