I noticed similar issues since the update to Cloudron 8, but in my case it was caused by the fact that the backup storage wasn't mounted correctly.
After clicking the "remount storage" button this was fixed and backups started working again.
I'm using sshfs and had this issue on 2 Cloudrons.
Maybe there is a general regression in the update procedure that causes the backup storage location to be in an unmounted state, resulting in failed backups?
@girish That's great to hear!
@girish since PHP 8.1 isn't supported anymore for almost 6 months now, aren't there any plans yet to upgrade to 8.2 or higher? Also some Nextcloud plugins require at least 8.2 in the meantime.
So both for security reasons and support reasons it's recommended to have at least v8.2.
And we're up and running again!
Thanks again @girish , without your help I wouldn't be able to get it running again.
@girish indeed, I just managed to get passed the failed migrations by making a new baseline and then telling prisma that all migrations have already run.
Unfortunately the app still won't start after the successful database migration.
It seams it tries to run another database migration during startup 
Any clues?
/app/pkg/start.sh
==> Changing ownership
NOTICE: extension "pgcrypto" already exists, skipping
CREATE EXTENSION
=> Running build script that generates the migrations
yarn run v1.22.19
$ npm-run-all check-env build-db check-db build-tracker build-geo build-app
$ node scripts/check-env.js
$ npm-run-all copy-db-files build-db-client
$ node scripts/copy-db-files.js
Database type detected: postgresql
Copied /app/code/db/postgresql to /app/code/prisma
$ prisma generate
Prisma schema loaded from prisma/schema.prisma
✔ Generated Prisma Client (v5.12.1) to ./node_modules/@prisma/client in 219ms
Start using Prisma Client in Node.js (See: https://pris.ly/d/client)
import { PrismaClient } from '@prisma/client'
const prisma = new PrismaClient()
or start using Prisma Client at the edge (See: https://pris.ly/d/accelerate)
import { PrismaClient } from '@prisma/client/edge'
const prisma = new PrismaClient()
See other ways of importing Prisma Client: http://pris.ly/d/importing-client
┌────────────────────────────────────────────────────────────────┐
│ Supercharge your Prisma Client with global database caching, │
│ scalable connection pooling and real-time database events. │
│ Explore Prisma Accelerate: https://pris.ly/cli/-accelerate │
│ Explore Prisma Pulse: https://pris.ly/cli/-pulse │
└────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────┐
│ Update available 5.12.1 -> 5.13.0 │
│ Run the following to update │
│ yarn add --dev prisma@latest │
│ yarn add @prisma/client@latest │
└─────────────────────────────────────────────────────────┘
$ node scripts/check-db.js
✓ DATABASE_URL is defined.
✓ Database connection successful.
✓ Database version check successful.
Error: P3005
The database schema is not empty. Read more about how to baseline an existing production database: https://pris.ly/d/migrate-baseline
✗ Command failed: prisma migrate deploy
Error: P3005
The database schema is not empty. Read more about how to baseline an existing production database: https://pris.ly/d/migrate-baseline
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
ERROR: "check-db" exited with 1.
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
@girish said in Umami not responding:
@guyds we are in sync about the situation
Haha 
But to clarify, you should still be able to follow upstream instructions. It might be a bit different on Cloudron but you should atleast be able to try them out.
- You have to put the app in recovery mode. Repair -> Recovery
- Then, in a web terminal of the app, you can run whatever commands you want.
https://git.cloudron.io/cloudron/umami-app/-/blob/master/start.sh?ref_type=heads is the startup script of Cloudron. When in recovery mode, the app container is created but the start up script is not executed. So, you have to then execute the exports at https://git.cloudron.io/cloudron/umami-app/-/blob/master/start.sh?ref_type=heads#L11 manually in the web terminal. Hopefully, all this makes sense (if you have dealt with Docker before, it should be straightforward).
Thanks for the pointers regarding the exports!
Initially, after the exports, I got the same error:
npx @umami/migrate-v1-v2@latest
Running v0.15.0
/app/code/node_modules/.prisma/client/default.js:43
throw new Error(
^
Error: @prisma/client did not initialize yet. Please run "prisma generate" and try to import it again.
In case this error is unexpected for you, please report it in https://pris.ly/prisma-prisma-bug-report
at new PrismaClient (/app/code/node_modules/.prisma/client/default.js:43:11)
at /root/.npm/_npx/429c6c96e109f52c/node_modules/@umami/migrate-v1-v2/index.js:298:12
at Object.<anonymous> (/root/.npm/_npx/429c6c96e109f52c/node_modules/@umami/migrate-v1-v2/index.js:323:3)
at Module._compile (node:internal/modules/cjs/loader:1256:14)
at Module._extensions..js (node:internal/modules/cjs/loader:1310:10)
at Module.load (node:internal/modules/cjs/loader:1119:32)
at Module._load (node:internal/modules/cjs/loader:960:12)
at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:86:12)
at node:internal/main/run_main_module:23:47
Node.js v18.18.0
But I was able to locate the schema.prisma file, run prisma generate and then fix some other node issues until the migration finally worked:
npx @umami/migrate-v1-v2@latest
Running v0.15.0
✓ DATABASE_URL is defined.
✓ Database connection successful.
✓ Database v1 tables ready for migration.
✓ Database v2 tables found.
✓ Database is ready for migration.
✓ Starting v2 data migration. Please do no cancel this process, it may take a while.
✓ Ran sql file /db/postgresql/data-migration-v2.sql.
✓ Data migration from V1 to V2 tables completed.
✔ Do you want to delete V1 database tables? (Y/N) … n
✓ Migration successfully completed.
Now let's try to restart the app... 
@girish I understand this is not Cloudron's fault in any way.
i'm also aware that v2 is not backwards compatible with v1 in that the events can't be migrated.
And while that's definitely a real bummer, it should still be possible according to their docs to upgrade from v1 to v2 and keep all the existing accounts as well as all the websites and therefore also all the website ID's which are used by other people to look into the stats.
If I have to reinstall, I'll lose all the accounts and website id's.
Rolling back to v2.4.2 is obviously not the best solution, but even if that could temporarily solve the situation I still can't because the backups can't be restored to a running state for some reason.
But yeah, I guess I have no other option than just starting from scratch.
That'll conclude a nice end of the week after having to deal with several other incompatible software upgrades this week 
Thanks anyway for you support!
And I know it's not your (nor Cloudron's) fault
@girish said in Umami not responding:
@guyds said in Umami not responding:
Isn't there any way I can try to manually run the migration script in recovery mode?
Sure, you should be able to run the migration script in recovery mode. But the issue was that the upstream migration script is not working/complete in all situations, from what I remember. But yes, give it a try .
And how can I do that?
I already tried the instructions from the Umami website, but that doesn't work at all (some npm errors about prisma)
As for backups, restoring should work. What was the issue there? Just clone the app from backup and check the logs?
The issue was that whenever I restored a backup, recent or from several weeks ago, the app still didn't start with the same errors in the logs.
Btw, what also worries me is that the restores from older backups always resulted in a none working app.
Shouldn't backups be a safety net to be able to roll back to a previous state where everything was working correctly?
Hi @girish , I considered that already but what's holding me back is that I'll lose all the site ID's (more than 30).
Isn't there any way I can try to manually run the migration script in recovery mode?
Earlier this week Umami was still working fine, but today I noticed I couldn't access it anymore.
In the Cloudron logs there were a lot of errors related to yarn.
I tried restoring to several older backup versions, but they all resulted in the same errors.
Also updating to newer Umami versions didn't help.
Since the host was still running Ubuntu 20.04 I decided to update to Ubuntu 22.04 as explained in the docs.
Unfortunately there were several issues during the upgrade process (rebuilding the containers hanged for several hours, nginx couldn't start because config file was missing, ...) but in the end I got everything up and running again... except Umami.
So I decided to again restore to an older backup from several weeks ago, a point in time I'm sure it was working fine, but still the app didn't start.
Then I updated again, version after version, to the most recent version 2.11.2 (package version 3.11.2) but still it won't start.
I have the impression that the cause might be that the database isn't migrated correctly from v1 to v2, but I have no clue how I can verify and/or fix this manually.
Here are the relevant log entries:
Apr 25 22:19:00 box:apptask startApp: starting container
Apr 25 22:19:00 box:tasks update 7264: {"percent":90,"message":"Configuring reverse proxy"}
Apr 25 22:19:00 ==> Changing ownership
Apr 25 22:19:00 box:tasks update 7264: {"percent":100,"message":"Done"}
Apr 25 22:19:00 box:taskworker Task took 87.51 seconds
Apr 25 22:19:00 box:tasks setCompleted - 7264: {"result":null,"error":null}
Apr 25 22:19:00 box:tasks update 7264: {"percent":100,"result":null,"error":null}
Apr 25 22:19:01 NOTICE: extension "pgcrypto" already exists, skipping
Apr 25 22:19:01 CREATE EXTENSION
Apr 25 22:19:01 => Running build script that generates the migrations
Apr 25 22:19:01 yarn run v1.22.19
Apr 25 22:19:01 warning Skipping preferred cache folder "/usr/local/share/.cache/yarn" because it is not writable. <30>1 2024-04-25T20:19:01Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - warning Selected the next writable cache folder in the list, will be "/tmp/.yarn-cache-0".
Apr 25 22:19:01 $ npm-run-all check-env build-db check-db build-tracker build-geo build-app
Apr 25 22:19:01 warning Cannot find a suitable global folder. Tried these: "/usr/local, /usr/local/share/.yarn"
Apr 25 22:19:01 warning Skipping preferred cache folder "/usr/local/share/.cache/yarn" because it is not writable.
Apr 25 22:19:01 warning Selected the next writable cache folder in the list, will be "/tmp/.yarn-cache-0".
Apr 25 22:19:01 $ node scripts/check-env.js
Apr 25 22:19:01 warning Cannot find a suitable global folder. Tried these: "/usr/local, /usr/local/share/.yarn"
Apr 25 22:19:02 warning Skipping preferred cache folder "/usr/local/share/.cache/yarn" because it is not writable.
Apr 25 22:19:02 warning Selected the next writable cache folder in the list, will be "/tmp/.yarn-cache-0".
Apr 25 22:19:02 $ npm-run-all copy-db-files build-db-client
Apr 25 22:19:02 warning Cannot find a suitable global folder. Tried these: "/usr/local, /usr/local/share/.yarn"
Apr 25 22:19:02 warning Skipping preferred cache folder "/usr/local/share/.cache/yarn" because it is not writable. <30>1 2024-04-25T20:19:02Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - warning Selected the next writable cache folder in the list, will be "/tmp/.yarn-cache-0".
Apr 25 22:19:02 $ node scripts/copy-db-files.js
Apr 25 22:19:02 warning Cannot find a suitable global folder. Tried these: "/usr/local, /usr/local/share/.yarn"
Apr 25 22:19:02 Database type detected: postgresql
Apr 25 22:19:02 Copied /app/code/db/postgresql to /app/code/prisma
Apr 25 22:19:03 warning Skipping preferred cache folder "/usr/local/share/.cache/yarn" because it is not writable.
Apr 25 22:19:03 warning Selected the next writable cache folder in the list, will be "/tmp/.yarn-cache-0".
Apr 25 22:19:03 $ prisma generate
Apr 25 22:19:03 warning Cannot find a suitable global folder. Tried these: "/usr/local, /usr/local/share/.yarn"
Apr 25 22:19:03 Prisma schema loaded from prisma/schema.prisma
Apr 25 22:19:04 <30>1 2024-04-25T20:19:04Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - ✔ Generated Prisma Client (v5.12.1) to ./node_modules/@prisma/client in 219ms <30>1 2024-04-25T20:19:04Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - <30>1 2024-04-25T20:19:04Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - Start using Prisma Client in Node.js (See: https://pris.ly/d/client) <30>1 2024-04-25T20:19:04Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - ``` <30>1 2024-04-25T20:19:04Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - import { PrismaClient } from '@prisma/client' <30>1 2024-04-25T20:19:04Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - const prisma = new PrismaClient() <30>1 2024-04-25T20:19:04Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - ``` <30>1 2024-04-25T20:19:04Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - or start using Prisma Client at the edge (See: https://pris.ly/d/accelerate)
Apr 25 22:19:04 ``` <30>1 2024-04-25T20:19:04Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - import { PrismaClient } from '@prisma/client/edge' <30>1 2024-04-25T20:19:04Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - const prisma = new PrismaClient() <30>1 2024-04-25T20:19:04Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - ``` <30>1 2024-04-25T20:19:04Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - <30>1 2024-04-25T20:19:04Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - See other ways of importing Prisma Client: http://pris.ly/d/importing-client <30>1 2024-04-25T20:19:04Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - <30>1 2024-04-25T20:19:04Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - ┌────────────────────────────────────────────────────────────────┐ <30>1 2024-04-25T20:19:04Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - │ Supercharge your Prisma Client with global database caching, │ <30>1 2024-04-25T20:19:04Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - │ scalable connection pooling and real-time database events. │ <30>1 2024-04-25T20:19:04Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - │ Explore Prisma Accelerate: https://pris.ly/cli/-accelerate │ <30>1 2024-04-25T20:19:04Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - │ Explore Prisma Pulse: https://pris.ly/cli/-pulse │ <30>1 2024-04-25T20:19:04Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - └────────────────────────────────────────────────────────────────┘ <30>1 2024-04-25T20:19:04Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 -
Apr 25 22:19:05 warning Skipping preferred cache folder "/usr/local/share/.cache/yarn" because it is not writable. <30>1 2024-04-25T20:19:05Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - warning Selected the next writable cache folder in the list, will be "/tmp/.yarn-cache-0".
Apr 25 22:19:05 $ node scripts/check-db.js
Apr 25 22:19:05 warning Cannot find a suitable global folder. Tried these: "/usr/local, /usr/local/share/.yarn"
Apr 25 22:19:05 ✓ DATABASE_URL is defined.
Apr 25 22:19:05 ✓ Database connection successful.
Apr 25 22:19:05 ✓ Database version check successful.
Apr 25 22:19:05 ✗ Umami v1 tables detected. For how to upgrade from v1 to v2 go to https://umami.is/docs/migrate-v1-v2.
Apr 25 22:19:05 error Command failed with exit code 1.
Apr 25 22:19:05 info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
Apr 25 22:19:05 ERROR: "check-db" exited with 1.
Apr 25 22:19:05 error Command failed with exit code 1.
Apr 25 22:19:05 info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
Apr 25 22:19:06 ==> Changing ownership
Apr 25 22:19:06 NOTICE: extension "pgcrypto" already exists, skipping <30>1 2024-04-25T20:19:06Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - CREATE EXTENSION
Apr 25 22:19:06 => Running build script that generates the migrations
Apr 25 22:19:06 yarn run v1.22.19
Apr 25 22:19:06 warning Skipping preferred cache folder "/usr/local/share/.cache/yarn" because it is not writable.
Apr 25 22:19:06 warning Selected the next writable cache folder in the list, will be "/tmp/.yarn-cache-0".
Apr 25 22:19:06 $ npm-run-all check-env build-db check-db build-tracker build-geo build-app
Apr 25 22:19:06 warning Cannot find a suitable global folder. Tried these: "/usr/local, /usr/local/share/.yarn"
Apr 25 22:19:07 warning Skipping preferred cache folder "/usr/local/share/.cache/yarn" because it is not writable.
Apr 25 22:19:07 warning Selected the next writable cache folder in the list, will be "/tmp/.yarn-cache-0".
Apr 25 22:19:07 $ node scripts/check-env.js
Apr 25 22:19:07 warning Cannot find a suitable global folder. Tried these: "/usr/local, /usr/local/share/.yarn"
Apr 25 22:19:07 warning Skipping preferred cache folder "/usr/local/share/.cache/yarn" because it is not writable.
Apr 25 22:19:07 warning Selected the next writable cache folder in the list, will be "/tmp/.yarn-cache-0".
Apr 25 22:19:07 $ npm-run-all copy-db-files build-db-client
Apr 25 22:19:07 warning Cannot find a suitable global folder. Tried these: "/usr/local, /usr/local/share/.yarn"
Apr 25 22:19:07 warning Skipping preferred cache folder "/usr/local/share/.cache/yarn" because it is not writable.
Apr 25 22:19:07 warning Selected the next writable cache folder in the list, will be "/tmp/.yarn-cache-0".
Apr 25 22:19:08 $ node scripts/copy-db-files.js
Apr 25 22:19:08 warning Cannot find a suitable global folder. Tried these: "/usr/local, /usr/local/share/.yarn"
Apr 25 22:19:08 Database type detected: postgresql
Apr 25 22:19:08 Copied /app/code/db/postgresql to /app/code/prisma
Apr 25 22:19:08 warning Skipping preferred cache folder "/usr/local/share/.cache/yarn" because it is not writable.
Apr 25 22:19:08 warning Selected the next writable cache folder in the list, will be "/tmp/.yarn-cache-0".
Apr 25 22:19:08 $ prisma generate
Apr 25 22:19:08 warning Cannot find a suitable global folder. Tried these: "/usr/local, /usr/local/share/.yarn"
Apr 25 22:19:09 Prisma schema loaded from prisma/schema.prisma
Apr 25 22:19:09 <30>1 2024-04-25T20:19:09Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - ✔ Generated Prisma Client (v5.12.1) to ./node_modules/@prisma/client in 207ms <30>1 2024-04-25T20:19:09Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - <30>1 2024-04-25T20:19:09Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - Start using Prisma Client in Node.js (See: https://pris.ly/d/client) <30>1 2024-04-25T20:19:09Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - ``` <30>1 2024-04-25T20:19:09Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - import { PrismaClient } from '@prisma/client' <30>1 2024-04-25T20:19:09Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - const prisma = new PrismaClient() <30>1 2024-04-25T20:19:09Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - ```
Apr 25 22:19:09 or start using Prisma Client at the edge (See: https://pris.ly/d/accelerate) <30>1 2024-04-25T20:19:09Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - ``` <30>1 2024-04-25T20:19:09Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - import { PrismaClient } from '@prisma/client/edge' <30>1 2024-04-25T20:19:09Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - const prisma = new PrismaClient() <30>1 2024-04-25T20:19:09Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - ``` <30>1 2024-04-25T20:19:09Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - <30>1 2024-04-25T20:19:09Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - See other ways of importing Prisma Client: http://pris.ly/d/importing-client <30>1 2024-04-25T20:19:09Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - <30>1 2024-04-25T20:19:09Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - ┌────────────────────────────────────────────────────────────────┐ <30>1 2024-04-25T20:19:09Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - │ Supercharge your Prisma Client with global database caching, │ <30>1 2024-04-25T20:19:09Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - │ scalable connection pooling and real-time database events. │ <30>1 2024-04-25T20:19:09Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - │ Explore Prisma Accelerate: https://pris.ly/cli/-accelerate │ <30>1 2024-04-25T20:19:09Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - │ Explore Prisma Pulse: https://pris.ly/cli/-pulse │ <30>1 2024-04-25T20:19:09Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - └────────────────────────────────────────────────────────────────┘ <30>1 2024-04-25T20:19:09Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 -
Apr 25 22:19:09 ┌─────────────────────────────────────────────────────────┐ <30>1 2024-04-25T20:19:09Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - │ Update available 5.12.1 -> 5.13.0 │ <30>1 2024-04-25T20:19:09Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - │ Run the following to update │ <30>1 2024-04-25T20:19:09Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - │ yarn add --dev prisma@latest │ <30>1 2024-04-25T20:19:09Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - │ yarn add @prisma/client@latest │ <30>1 2024-04-25T20:19:09Z cloudron-host-01 b6acced1-aa35-45f1-a274-2badf0b1b962 781 b6acced1-aa35-45f1-a274-2badf0b1b962 - └─────────────────────────────────────────────────────────┘
Apr 25 22:19:10 => Healtheck error: Error: connect ECONNREFUSED 172.18.16.182:3000
Apr 25 22:19:10 warning Skipping preferred cache folder "/usr/local/share/.cache/yarn" because it is not writable.
Apr 25 22:19:10 warning Selected the next writable cache folder in the list, will be "/tmp/.yarn-cache-0".
Apr 25 22:19:10 $ node scripts/check-db.js
Apr 25 22:19:10 warning Cannot find a suitable global folder. Tried these: "/usr/local, /usr/local/share/.yarn"
Apr 25 22:19:10 ✓ DATABASE_URL is defined.
Apr 25 22:19:10 ✓ Database connection successful.
Apr 25 22:19:10 ✓ Database version check successful.
Apr 25 22:19:10 ✗ Umami v1 tables detected. For how to upgrade from v1 to v2 go to https://umami.is/docs/migrate-v1-v2.
Apr 25 22:19:10 error Command failed with exit code 1.
Apr 25 22:19:10 info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
Apr 25 22:19:10 ERROR: "check-db" exited with 1.
Apr 25 22:19:10 error Command failed with exit code 1.
Apr 25 22:19:10 info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
How can I get Umami up and running again?
@girish since I recently had another issue as well, I was just thinking that maybe all this is related to the fact that I initially migrated from an older Piwik installation.
With that, I mean that after I installed the Cloudron app about 2 years ago, I imported existing data from that older Piwik installation. This might explain why I'm faced with those issues during upgrades while others aren't
My Matomo installation was automatically upgraded to v5.0.0 and as a result a database upgrade was needed upon first access.
When I proceeded with the upgrade step, I got an Update error after several seconds:
Critical Error during the update process:
/app/code/core/Updates/5.0.0-b1.php: Error trying to execute the migration 'ALTER TABLE `log_visit` ADD INDEX `index_idsite_idvisitor_time` (`idsite`, `idvisitor`, `visit_last_action_time` DESC);'. The error was: SQLSTATE[42000]: Syntax error or access violation: 1178 The storage engine for the table doesn't support descending indexes
Googling for the exact error didn't return anything useful, but by broadening my search I was able to narrow it down to a query incompatibility with the MyISAM engine, more specifically the "DESC" clause isn't supported.
So to solve the issue, I opened the MySQL cli and manually performed the query without the DESC modifier, like this:
ALTER TABLE `log_visit` ADD INDEX `index_idsite_idvisitor_time` (`idsite`, `idvisitor`, `visit_last_action_time`);
Then I restarted the upgrade procedure from the web interface and everything finished successfully.
I'm not sure if this is something that should be fixed in the Cloudron package, e.g. by upgrading to a newer MySQL version and/or switching to the InnoDB engine?
In any case, this information might be valuable for others as well.
Edit: fixed typo
@girish, fair enough.
I definitely understand your reasoning, but on the other side there is probably a good reason why the issue was added to the Matomo FAQ
Thanks @girish, I'm glad you found the issue.
Before posting here, I did a search on the error but that didn't bring me to the Matomo FAQ. Probably my search was too specific.
The question now is if/how this can be prevented in the future
For starters it might be a good idea to add this info to the documentation for the Matomo app?
@girish sure, I just sent an email to support.
Unfortunately, since I'm using a free version of Cloudron I can only have 2 apps on a single Cloudron and therefore I'm not in the possibility to clone from an older version because I already have another app on that same Cloudron.
And when importing a backup on another Cloudron, the versions of the old and new app should be identical and I can only install the latest version of the app on the new Cloudron, so I would only be able to clone from the latest version.
Or is there a way to clone an older version of the app to another server?
Thanks for the suggestions.
Running the migration manually doesn't have any effect though:
/app/code# sudo -E -u www-data -- /app/code/console core:update --yes
Everything is already up to date.
I'll try to revert to an older backup or set up a clone from an older backup
Suddenly I can't login anymore on my Matomo instance.
Whenever I try to login, I get the following SQL error:
SQLSTATE[42S22]: Column not found: 1054 Unknown column 'login' in 'where clause'
In the Cloudron logs:
Nov 08 10:10:18[Wed Nov 08 09:10:18.623617 2023] [php:notice] [pid 225] [client 172.18.0.1:49142] [<domain-name-redacted>] Error in Matomo: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'login' in 'where clause', referer: https://<domain-name-redacted>/index.php
Nov 08 10:10:1894.227.68.6 - - [08/Nov/2023:09:10:18 +0000] "POST /index.php?module=Login HTTP/1.1" 500 1733 "https://<domain-name-redacted>/index.php" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/118.0"
Nov 08 10:10:18172.18.0.1 - - [08/Nov/2023:09:10:18 +0000] "POST /index.php?module=Login HTTP/1.1" 500 2051 "https://<domain-name-redacted>/index.php" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/118.0"
Nov 08 10:10:20172.18.0.1 - - [08/Nov/2023:09:10:20 +0000] "GET / HTTP/1.1" 200 30862 "-" "Mozilla (CloudronHealth)"
I'm not 100% sure, but I think this happens since the latest update to 1.42.0 which includes a migration to OIDC login.