This might be worth reporting upstream for a start. Apps on cloudron are not rebooted but restarted, there is no way an app itself restarts itself unless the main container process gets killed (which is probably possible). Cloudron has APIs for this though https://docs.cloudron.io/api.html#tag/Apps/paths/~1apps~1{appid}~1restart/post

Most of the time the scheduled backups now succeed, but not always. I'll keep an eye on the backups and make manual backups if the scheduled failed. Let's see if the changes of scaleway improve the situation. Thanks again for the suggestions and help.

Part of the issue was that redis was getting stuck. Restarting box code fixed it - systemctl restart box. Another part of the issue is https://forum.cloudron.io/topic/9795/3-2-0-update-not-showing-up/9 . I am pushing a fix.

Understood. I am in UK but use Hetzner in DE, and don't have any performance issues.

This had to do with french translation being buggy in 7.5.0

Thanks for the explanation. That did help me. I did a small mistake: I checked the filters and I have not seen that I can scrolldown in the list... so I just saw the app.* ones but not all the others. This is fine then!

@philkunz true... too late to change the name now

@cooljack Can you give more information about your VM? Is this a public cloud provider or something else? If you can give us access to vm, we can look it this as well. Have to say never seen initialization of MySQL fail...

Compass guide is here - https://docs.cloudron.io/guides/connect-mongodb/#mongodb-compass

Johannes from cloudron support just fixed my cloudron! 🥳 [image: 1691509163942-931a8a94-67c4-4299-bf50-3d384803ea0b-image-resized.png]

@warg said in The turn service ran out of memory: Could this be related to malicious clients, e. g. erros created by bots that try turn-specific exploits? It does seem to be like that. Is anyone else seeing such messages in the turn service logs?

There were a few bugs with the token display when we moved the dashboard over to OpenID. This is fixed now with https://git.cloudron.io/cloudron/box/-/commit/e9f3f135640f8ee60041a8797b32b62e032201af

Maybe you have dangling images around, which are not deleted, can you see if docker image prune -a removes some?

For others reading this: After looking at the WordPress instance, it appeared to have been hacked and someone placed suspicious includes in wp-config.php those made the app simply hang. Removing that brought it back, however in such situations, it is strongly advised to start fresh as we don't know what else may have been modified.

@imc67 yes, indeed, but the presence of the original DST Root CA is causing issues for Uptime Kuma. There is discussion in their Issues list, but no solution (some hack proposed but not interested in that). I've read elsewhere that the old DST Root CA can be deleted ... but no idea how. That might help Uptime Kuma not to report it. I might try that on non-Cloudron apps but wouldn't want to try that on a Cloudron app. Oh well, just some noise in Telegram that I can ignore.

Already fixed bugs are the best bugs

Thanks! I did not expect such a quick fix after your first response, but the change looks sensible.

@nebulon Thanks. Ohh, I was so close last night. Your post gave me the courage to plunge back in. The username I gave to the user who owns the policy was a really wierd choice several years ago. So when I went to the aws users page, I didn't think of exploring there. Also the ID and secret were in a file on my local machine, filed well with a good file name. Last night I just wasn't careful in looking for it. So I'm all good now.

I figured out the issue - posting here for anyone who encounters the same... I had not whitelisted my new server's IP address with my registrar (Namecheap). Once I did this, installs and uninstalls are now working. The error was actually an external error passed from Namecheap, not an internal Cloudron error message

That's the last thing I would have expected... thank you for finding this out!