Cloudron Forum

Thanks, that did it!

I increased total swap from 4 GiB to 8 GiB, leaving the backup task’s memory limit at 3 GiB and all other backup settings unchanged.

The next attempt completed the backup successfully, then updated Mastodon from package 1.19.1 to 1.19.2.

Thanks for pointing me in the right direction!

Thanks for the quick reply, and for clarifying the Spaces multipart-copy support.

I’ve now checked the backup task’s own log alongside the kernel and systemd records. For the latest attempt, PID 389975 appears to belong to the backup task rather than MySQL:

oom_memcg=/system.slice/box-task-24245.service
task_memcg=/system.slice/box-task-24245.service
task=MainThread,pid=389975

Systemd reports:

Result=oom-kill
ExecMainStatus=70
MemoryMax=3221225472

The corresponding task log identifies task 24245, shows it uploading files until 07:18:44 UTC, and then records:

2026-09-20T07:18:50.714Z Exiting with code 70

There were two different failures: the earlier attempt hit global OOM with the backup limit set to 6 GiB; the latest hit CONSTRAINT_MEMCG with the backup limit set to 3 GiB.

Swap was indeed exhausted, so I’m open to increasing it. What swap size and backup-task memory limit would you recommend testing together? Is there a cgroup swap limit I should check first?

Given the process mapping above, would you still recommend increasing MySQL’s limit? This Mastodon app uses PostgreSQL.

I can provide the redacted backup-task log as well.

Problem description

My Mastodon pre-update backup repeatedly fails, blocking the update from package 1.19.1 to 1.19.2. Mastodon itself remains running and healthy. I’m posting in the Cloudron/server category because the failing process is Cloudron’s backup task.

The server has 16 GiB RAM and 4 GiB swap. My backup destination is DigitalOcean Spaces using rsync, with upload concurrency 10 and upload part size 10 MiB.

I moved an unused cache directory outside the app’s backup scope, preserving it for rollback. This substantially reduced the file count, but backups still fail:

• Task 24234: with a 6 GiB backup memory limit, the host ran out of memory. The kernel killed the backup worker at approximately 3.37 GiB anonymous RSS, reporting global_oom.
• Task 24245: after rebooting and lowering the backup memory limit to 3 GiB, the worker hit its own cgroup limit (CONSTRAINT_MEMCG). It stopped after uploading 9,466/28,032 files. Cloudron reported “Task stopped” / exit code 70.

My latest retained successful Mastodon backup is from September 3. The update has not completed, and the app remains in installationState=error despite being healthy.

cloudron-support --troubleshoot

Some details are redacted below; diagnostic results are otherwise unchanged.

═══ Host ═══
Vendor: DigitalOcean Product: Droplet
Linux: 5.15.0-191-generic
Ubuntu: jammy 22.04
Cloudron: 10.0.5
Execution environment: kvm
Processor: DO-Premium-AMD x 4
RAM: 16373036KB
Disk: /dev/vda1        60G

═══ System ═══
[OK] Root disk usage is OK (70%)
[OK] Memory usage is OK (74%)
[WARN] Swap is 99% used — the box may be undersized
[OK] Disk I/O on /home/yellowtent (vda, HDD): 571 MB/s write, iowait 6%
[OK] Clock is NTP-synchronized
[OK] node version is correct
[OK] IPv6 is enabled in kernel. Public IPv6 address detected
[OK] docker is running
[OK] docker version is correct

═══ Networking ═══
[OK] no incompatible persistent-firewall packages installed
[OK] DNS is resolving via systemd-resolved
[OK] unbound is running
[OK] IPv4 HTTPS to api.cloudron.io/api/v1/helper/public_ip
[OK] IPv6 HTTPS to api.cloudron.io/api/v1/helper/public_ip
[OK] IPv4 HTTPS to auth.docker.io/token
[OK] IPv6 HTTPS to auth.docker.io/token
[OK] IPv4 HTTPS to acme-v02.api.letsencrypt.org
[OK] IPv6 HTTPS to acme-v02.api.letsencrypt.org
[OK] netplan is good

═══ Cloudron Platform ═══
[OK] MySQL is running
[OK] nginx is running
[OK] Dashboard cert is valid [expiry details redacted]
[OK] dashboard is reachable via loopback
[OK] No pending database migrations
[OK] Service 'mysql' is running and healthy
[OK] Service 'postgresql' is running and healthy
[OK] Service 'mongodb' is lazy-stopped (no installed Cloudron app uses the 'mongodb' addon)
[OK] Service 'mail' is running and healthy
[OK] Service 'graphite' is running and healthy
[OK] Service 'sftp' is running and healthy
[OK] box v10.0.5 is running
[OK] Dashboard is reachable via IPv4 [URL redacted]
[OK] Dashboard is reachable via IPv6 [URL redacted]
[OK] Domain [redacted] is valid [expiry details redacted]

======== Summary ========
PASS: 33
WARN: 1
FAIL: 0
SKIP: 0

Warnings:
  - Swap is 99% used — the box may be undersized

For troubleshooting tips, see https://docs.cloudron.io/troubleshooting
To share a full diagnostic dump on the forum, run: cloudron-support --send-diagnostics

Relevant errors from box.log

Selected lines from /home/yellowtent/platformdata/logs/box.log:

2026-09-20T07:18:51.297Z tasks: startTask: 24245 done. error: { message: 'Task 24245 stopped', code: 'stopped' }
2026-09-20T07:18:51.311Z apps: Apptask crashed/stopped: Task 24245 stopped

The same log records this task-runner output:

Finished with result: oom-kill
Main processes terminated with: code=exited/status=70
Service runtime: 8min 37.392s
CPU time consumed: 3min 31.136s

Relevant kernel log excerpts, with the hostname omitted:

2026-09-20T07:18:50+0000 kernel: oom-kill:constraint=CONSTRAINT_MEMCG,nodemask=(null),cpuset=box-task-24245.service,mems_allowed=0,oom_memcg=/system.slice/box-task-24245.service,task_memcg=/system.slice/box-task-24245.service,task=MainThread,pid=389975,uid=0
2026-09-20T07:18:50+0000 kernel: Memory cgroup out of memory: Killed process 389975 (MainThread) total-vm:13140380kB, anon-rss:2949476kB, file-rss:27000kB, shmem-rss:0kB, UID:0 pgtables:16832kB oom_score_adj:0

Questions

1. Is this a known issue with the rsync/S3 backup path in Cloudron 10.0.5? What configuration would you recommend, given that a larger task limit previously exhausted the host?
2. I’m considering a separate Mastodon-only tgz backup site, using the same Space under a unique prefix while preserving existing rsync backups. What is the supported way to return the healthy app from installationState=error to a state that permits a standalone manual backup, without restoring data or skipping the update safety backup?
3. Is large-tarball backup rotation on Spaces supported in 10.0.5? Cloudron’s documentation warns about copying objects over 5 GB, but the installed code uses multipart UploadPartCopy, which DigitalOcean currently documents as supported.

I’d like to verify a fresh backup before changing the update-backup routing or attempting another update. I can provide additional logs to support if needed.

Thanks!

Seconding the call for support. I'd love to get this up and running eventually.

@girish Perfect, thank you! That did the trick.

I've noticed that for the past few weeks, some apps don't update successfully, and then display "error" as their status. While the apps are still running fine, despite the error status, it seems the update process failed with error messages like this one:

An error occurred during the update operation: Docker Error: Unable to pull image cloudron/io.n8n.cloudronapp:202411271257520000. Please check the network or if the image needs authentication. statusCode: 500

It's happening to n8n, ghost, and a few others.

Running the update process again manually usually solves it, until the next time an update is available.

Any ideas?

I've been having the same issue with S3, switched to DO Spaces now because it's easier to monitor. I had terabytes of data in my S3 bucket and only noticed it once I got my bill. With DO Spaces it's now the same issue, there's still backups from three days in there despite a 2 day retention policy.

@jdaviescoates Thank you! Apparently it was one of my plugins, but they needed to be deactivated manually, simply renaming the folder didn't work. I guess I'm gonna do that with my other installs now and see which one it is there that breaks the site.

I tried updating two of my Wordpress installs to the latest package (v3.0.0), and it results in a critical, not very verbose, error message.

"There has been a critical error on this website.

Learn more about troubleshooting WordPress."

I tried renaming the entire plugins folder while in recovery mode, in order to find out whether it's a specific plugin, but the result is the same.

Any ideas what might be going on here?

I second this. Would be great to use this as a Goodreads alternative.

@girish said in IPv6 for Mastodon - how?:

@stormgrass This one - https://docs.digitalocean.com/products/networking/ipv6/how-to/enable/#on-existing-droplets . Did you do this?

Ah, no, that point I missed. Am trying to fix it now, but the yaml indicated in the doc doesn't exist. So, I've created it and get hit with a syntax error, even though it's a copy of the contents specified.

Anyway, I'll keep investigating, but I think you can mark this as resolved now. Thank you!

@girish I actually tried using "Public IP" first, but I always get this error message when I do that:

Unable to detect IPv6. API server (ipv6.api.cloudron.io) unreachable

One thing is, can you check if you can curl -6 https://my.domain.com works? If that doesn't work, there is some other issue at the server/network level.

That actually produces an error message as well:

curl: (7) Failed to connect to my.stormgrass.com port 443: Network is unreachable

You can also check curl --connect-timeout 10 -v6 https://social.cloudron.io/@cloudron which our mastodon instance with IPv6.

This too:

Trying 2001:19f0:5001:64e:5400:2ff:fee8:d17b:443...
* connect to 2001:19f0:5001:64e:5400:2ff:fee8:d17b port 443 failed: Network is unreachable
* Failed to connect to social.cloudron.io port 443: Network is unreachable
* Closing connection 0
curl: (7) Failed to connect to social.cloudron.io port 443: Network is unreachable

So, does that mean I have both a misconfigured Cloudron droplet AND my machine doesn't have proper IPv6 connectivity (as @mehdi suggested)?

Not even sure any more where all the potential fault-lines are haha

(Also: @mehdi: yeah, trying to obfuscate something that's easily found out via the exact same command I pasted wasn't exactly my proudest moment haha)

The issue

I'm trying to make my Mastodon instance reachable via IPv6 (and, but that might be a Mastodon and not Cloudron-related issue, allow it to add accounts on IPv6-only servers).

What did I do?

I've created an IPv6 address for my Cloudron droplet on Digital Ocean, added that address as a static IP to Cloudron via the Networking section, and then ran a full DNS sync, letting Cloudron write the AAAA records to my Digital Ocean DNS records.

I then tried connecting to my instance via curl, like so:

curl --connect-timeout 10 -v6 https://hemmer.land/@GeschichteFM

But receive this error message (address is obfuscated):

connect to X::X::X::X::X port 443 failed: Network is unreachable
* Failed to connect to hemmer.land port 443: Network is unreachable
* Closing connection 0
curl: (7) Failed to connect to hemmer.land port 443: Network is unreachable

I've also tried adding an IPv6 to Cloudron by using the Network Interface option, which generated another address than the one I got from Digital Ocean via their interface. I then tested via curl again, which generated a different error message:

Immediate connect fail for X::X::X::X::X Invalid argument
* Closing connection 0

The questions

• Seeing how both produce different results in my DNS records: is adding the DO-issued address into Cloudron as a static IP the correct course of action, or should I be using the Network Interface instead?
• Once the correct address is in my DNS records, do I need to do anything else, like change any settings in the Mastodon .env settings?

Thanks in advance,
Richard

@girish Thank you, that did the trick! Not entirely sure how and why my install looked the way it did. I think I installed it first thing once it showed up in the app store, but back then it was still marked as unstable. Anyway, it's all good now, thank you!

@girish I checked .env.production, but it doesn't have the Service Dependencies as posted by you. I do, however, get the kind of result you posted when querying env for REDIS.

My Cloudron is version 7.1.4, my Mastodon package is version 2.8.4, though (weirdly, the last update was "years ago").

EDIT: I DO have the service dependencies lines in .env.production, but not grouped in that order, under that heading, and the REDIS_PASSWORD variable has no value.

EDIT2: Just noticed that apparently my package is really outdated, as the current one when installing it from scratch is 3.4.6. Which is weird, because I've always had it set to automatically update, and when manually trying to update, there doesn't seem to be a newer package. Is there a way to update my current install to the latest version without completely wiping it?

@girish Thank you! It was, the solution in your linked thread fixed it.

Hello,
it seems my Mastodon installation is having trouble with its Redis connection.
Opening up the site I'm greeted by an error message ( "We're sorry, but something went wrong on our end.")
I checked the log, which immediately fills with this error message:

ERR! Error: Redis connection to localhost:6379 failed - connect ECONNREFUSED 127.0.0.1:6379

I restarted the whole app, which didn't do anything.
I also restarted the Mastodon Redis from the Cloudron backend, same result.

The apphealthmonitor says 17 alive / 3 dead (the two additional dead services seem to be my two LAMP boxes, which for some reason won't restart properly - could be related?)

Any idea what might be going on?

Thanks in advance,
Richard

@girish Thanks so much!

Hello!

I'm trying to get the Feedreader desktop app for Linux to work with Tiny Tiny RSS. The thing is, Feedreader needs an additional plugin to augment the API, and needs it to be registered as a system plugin. System plugins need to be activated via the config.php, though and as the config.php is in /app/code/ I can't edit it.
I tried turning the plugin into a non-system plugin, and then activating it, but the Feedreader app doesn't seem to recognize the plugin as activated in that case.

What are my options here?

Thanks in advance,
Richard

@girish Thanks a lot for your reply. I wasn't aware that the LAMP/Surfer apps don't count towards the total app count. That's great news!