Cloudron Forum

Sorry for the mysql user confusion. I had not realized that Ubuntu does come with a pollinate user through the pollinate package by default!

So then the question comes back to finding out which app seems to utilize the mysql service that heavily. Maybe you can also stop one app after the other to find out which one is the one causing that.

Usually apps are setup to log to stdout/stderr where possible, then the logging and cleanup is managed by the platform. It is possible that for some apps we have missed some configs or have to add log rotation manually within the app then. In which apps besides snipe-it do you see this behavior?

Do you have any error logs from the app on the server side, which might hint at the root cause? Also have you searched with the upstream project what the error could indicate?

@KhalilZammeli looking at your screenshot, the user of that very busy mysql instance seems to be some pollina+ which I have no clue what that would be. At least this is not coming from any Cloudron bits. Have you installed anything on the side on this server, which may be causing that?

Oh sorry I was mislead by the comment of @jdaviescoates . So looking at the logs it seems the upload to S3 fails with some EPIPE. This indicates that the remote S3 storage terminates the upload connection prematurely or maybe also your system ran out of memory and that killed the pipeline. We have had various issue with backblaze in the past. Can you maybe tweak the backup task memory limit as well as the part-size to see if that makes a difference?

Maybe you can get some better immediate overview when running htop or top via SSH to see if systemload is maybe high, in which case the system may just be underpowered for the apps you are running. Also sometimes disk I/O is an important factor.

Not sure how this is related to Nextcloud, as all apps run within their own sandbox and are not related do nodejs versions on the host. Maybe to come back to the nodejs problem, did you run those node commands within an app container or the host system?

maybe you can do a small screencast showing what exactly doesn't work. This is a Cloudron forum, not a general osTicket one, so we aren't experts on the apps itself, if it comes to using apps.

Glad it worked out in the end though!

If the system runs out of disk space, a lot of side-effects can happen, so this could very well be the root cause then.

I fixed up the docs at https://docs.cloudron.io/apps/etherpad/ this works reliably for me. Quite possibly the different login views were the issue?

Last time I checked they required a very specific mongodb version, but also the selfhosting was deprecated. Maybe that changed though. Looks like it is now called "UniFi Network Server" https://www.ui.com/download

This is really something for LetsEncrypt to deal with, maybe you can unsubscribe with them for those.

As a matter of fact they seem to retire those https://letsencrypt.org/2025/01/22/ending-expiration-emails/

Given that you mention that some emails went out, I don't think it is an authentication error, but listmonk for some reason stops after some successful mails. If something around auth or platform settings would be wrong, why would it send out parts of the mails and then stops? Maybe the app internally batches or crashes midway (after the 501s email in this case)?

Could it be some caching issue and do you see any errors on the server side if you check the app logs while trying to access those documents?

Given that you see 500 status errors from your registry, can you check the logs there? 500 if used correctly refer to remote server errors. Auth failure would be in the 400 range (403, 402, ..)

Just tried again and looks like you have to relogin after app restart after adding that user in the settings.json and provide the admin flag.

Most likely you hit the same as https://forum.cloudron.io/topic/13047/since-update-to-v8-2-1-backups-fail-with-too-many-empty-directories/16?_=1737623616788

Those are coming from letsencrypt itself, as a reminder to renew if still used. LetsEncrypt does not know if those domains are still in use. You can safely ignore such mails.

If you were shown the initial setup screen again, looks like the db migration really went wrong during the update. Ideally if possible a fresh restore from backups would be best to get to a known state. Is that possible?