Cloudron Forum

Updates cannot be skipped. This is how all the app packages are tested by us and by (most) upstream projects.

@senthilkumaran https://github.com/TryGhost/Ghost/releases . there were 5 releases just this week. You can change update schedule in the settings -> update

This is not possible because nobody is testing update of the app from 1.0 to 1.8 directly. Neither is Cloudron and nor is the upstream app. You can use the CLI tool if you want to do direct updates like this, but as mentioned, nobody knows what will happen.

Ok that file is showing regular checks but no packages marked for upgrade. I will keep an eye on this. Thanks for the support.

@girish said in WordPress app container stuck on updating from package version 3.7.2 to 3.7.3:

This happens with apps which contains files that change their size when the backup is going on. ... Maybe you have some plugin that writes to somewhere periodically?

Thank you @girish Great advice and just the clue we needed. We figured out what that was, stopped it and then we could take a WP backup manually; and then we were also able to update to the latest packaged WP version 3.8.0

Thank you once again; your prompt help is much appreciated

You can mark this ticket as resolved; cheers! 🙂

In the meantime, I have pushed a fix to cleanup old artifacts for the next release.

@dvlexp you have to ask these questions upstream in the n8n forum - https://community.n8n.io/ . We can only provide help here with the packaging aspect of n8n itself. App related issues are best asked upstream.

This does not apply to Cloudron packages, only to the upstream composer deployment as far as I understand.

I can confirm.Thank you!

@girish Thanks for the complete and thorough explanation. I guess I was fooled by the apt update I saw in one of your docker image definitions (thinking that others would be following your best practice). If you are comfortable with the risk/reward balance then I am comfortable:)

Can confirm that the update to Immich v1.91.4 is going well.

If you are running Immich, just think about how much work and time and effort Cloudron has saved us by supporting this application. No headaches. Just one-click.

Thank you so much for Cloudron!

FWIW, I just upgraded from Ubuntu 18 this evening. Cloudron's documentation from going from 18 to 20 was quite helpful, re: a collectd edit that I never would have thought to make, plus the specific MySQL Server migration rules. Everything went smoothly, but without the documentation, it wouldn't have. So kudos to the team.

@jdaviescoates said in Cloudron update to 7.5.1 - Success!:

@mhgcic said in Cloudron update to 7.5.1 - Success!:

I could increase the RAM to see if that helps.

Regardless if it is what's causing the issues you're currently facing, I'd definitely get more RAM if I were you.

Each instance of Mastodon needs at least 1.5GB and each instance of Discourse at least 2GB. Already that is at least 10.5GB RAM you need before you've included all your other apps plus Cloudron and Ubuntu themselves.

And these are bare minimums. If you have users actually actively using these apps they'll need more.

We know this and monitor daily, and we have software that lets us know that RAM needs to be increased whether it is on a server level or on an app level.

We upgrade as and when needed, We also use throttling so if extra RAM or CPU is needed it is given until we decide on its upgrade needs.

After testing it had nothing to do with CPU or RAM it seems to be networking or a service possibly.

I got everything working now by skipping some updates, finding a problematic one and debugging it a bit. I'm leaving a message I was going to send mid debugging before I managed to get it working just in case anyone else comes across the same issue.

I got it working by skipping versions until I got to one that wouldn't apply. It was v4.41.0. It would run but the database migration would never connect to MySQL. This happened even after I got to the version just before and tried to apply it a few times.

While I was debugging I found that the MySQL connection wouldn't work from the Terminal. Then I put the app into recovery to debug further. It MySQL worked in the Terminal there, so I turned off recovery mode and it booted just fine! Not sure what the root issue was though. Unusual that I was able to reproduce it but then it kind of resolved itself. Maybe switching to or from recovery resets some value causing an issue. I'm not sure.

Original message:

So, this is now pretty specific to Ghost. I've made it up to v4.40.2 just fine, but when I apply the next version v4.41.0, Ghost fails to start.

The log shows

Jul 11 14:39:18 ==> Start ghost Jul 11 14:39:18 ==> Clear potential migration lock Jul 11 14:39:18 mysql: [Warning] Using a password on the command line interface can be insecure. Jul 11 14:39:20 => Healtheck error: Error: connect ECONNREFUSED 172.18.17.238:2368 Jul 11 14:39:30 => Healtheck error: Error: connect ECONNREFUSED 172.18.17.238:2368 Jul 11 14:39:40 => Healtheck error: Error: connect ECONNREFUSED 172.18.17.238:2368 Jul 11 14:39:50 => Healtheck error: Error: connect ECONNREFUSED 172.18.17.238:2368 Jul 11 14:40:00 => Healtheck error: Error: connect ECONNREFUSED 172.18.17.238:2368 Jul 11 14:40:10 => Healtheck error: Error: connect ECONNREFUSED 172.18.17.238:2368 Jul 11 14:40:20 => Healtheck error: Error: connect ECONNREFUSED 172.18.17.238:2368 Jul 11 14:40:30 => Healtheck error: Error: connect ECONNREFUSED 172.18.17.238:2368 Jul 11 14:40:40 => Healtheck error: Error: connect ECONNREFUSED 172.18.17.238:2368 Jul 11 14:40:50 => Healtheck error: Error: connect ECONNREFUSED 172.18.17.238:2368 Jul 11 14:41:00 => Healtheck error: Error: connect ECONNREFUSED 172.18.17.238:2368 Jul 11 14:41:10 => Healtheck error: Error: connect ECONNREFUSED 172.18.17.238:2368 Jul 11 14:41:20 => Healtheck error: Error: connect ECONNREFUSED 172.18.17.238:2368 Jul 11 14:41:30 => Healtheck error: Error: connect ECONNREFUSED 172.18.17.238:2368 Jul 11 14:41:32 json: updated "/app/data/config.production.json" in-place Jul 11 14:41:32 json: updated "/app/data/config.production.json" in-place Jul 11 14:41:32 json: updated "/app/data/config.production.json" in-place Jul 11 14:41:32 ===> Copy frotend/public folder for asset generation Jul 11 14:41:32 ==> Loading /app/data/env for potential overrides Jul 11 14:41:32 ==> Ensure permissions Jul 11 14:41:32 ==> Migrating database Jul 11 14:41:40 => Healtheck error: Error: connect ECONNREFUSED 172.18.17.238:2368 Jul 11 14:41:44 [2023-07-11 21:41:44] ERROR Invalid database host. Jul 11 14:41:44 Jul 11 14:41:44 Invalid database host. Jul 11 14:41:44 Jul 11 14:41:44 "Please double check your database config." Jul 11 14:41:44 Jul 11 14:41:44 Error ID: Jul 11 14:41:44 500 Jul 11 14:41:44 Jul 11 14:41:44 Error Code: Jul 11 14:41:44 DATABASE_CREATION_FAILED Jul 11 14:41:44 Jul 11 14:41:44 ---------------------------------------- Jul 11 14:41:44 Jul 11 14:41:44 Error: connect ETIMEDOUT Jul 11 14:41:44 at /home/cloudron/ghost/versions/5.41.0/node_modules/knex-migrator/lib/database.js:134:19 Jul 11 14:41:44 at /home/cloudron/ghost/versions/5.41.0/node_modules/knex-migrator/lib/database.js:50:23 Jul 11 14:41:44 at Connection._handleTimeoutError (/home/cloudron/ghost/versions/5.41.0/node_modules/knex-migrator/node_modules/mysql2/lib/connection.js:202:17) Jul 11 14:41:44 at listOnTimeout (node:internal/timers:564:17) Jul 11 14:41:44 at process.processTimers (node:internal/timers:507:7)

The diff for this version bump is here: https://git.cloudron.io/cloudron/ghost-app/-/commit/93e180df6ad9216f8f04480b9b60212816f86c28

I've tried restoring my backup to v4.40.2 and re-applying multiple times but it continues to fail. It also fails if I use the CLI to skip this version and jump to the latest.

@robi instead of clickable, the logs are unified now into a single stream (similar to app logs).

tl;dr - If you have the above problem apt install python3-magic . Then, run apt update . On another server, unattended-upgrades package was missing as well (!) Not sure how because Cloudron installs it at install time. So, install it and run unattended-upgrade -d.

@nebulon Gotcha -- so it would have cleared up eventually, anyway. Well, thanks again. I really appreciate your support!

Hi @Thedurancode,

the way apps are designed on Cloudron it is not possible to change any of the actual application code (and therefore you get the file permission errors). Instead you will either need to wait until Nextcloud 26 is generally available (you can check this post to check for the latest release) or you would need to fork the app code and perform the update there. The latter is easy to do if you are familar with Cloudron app development, but not really recommended for beginners (ihmo).