@robi this worked, thank you. I hadn't realized there was a way to check services like that (I had another issue previously telling me to restart nginx, which I never could find out how, but this worked for that too). thanks for the help!
Thanks for reporting. This was bug in the container. I have reduced the verbosity to 0 in the mongod configuration for the next release. For the moment, you can simple delete or truncate the log files.
@nebulon said in Wekan backup errors blocking my Cloudron backups from completing.:
This indicates, that the mongodb instance/service could not finish creating the database dump for wekan.
It's odd because if I run a backup from the app it completes in a few seconds. There is very little data to backup.
@nebulon said in Wekan backup errors blocking my Cloudron backups from completing.:
Maybe it ran out of memory
Unlikely given it's got over 4GB and I don't think I've ever seen it hit 10% usage.
@nebulon said in Wekan backup errors blocking my Cloudron backups from completing.:
Do you see any crash or more info in the actual mongodb service logs?
I think I've looked and not seen anything obvious but I'll look again...
Did you look at the logs I shared previously?
said in Wekan backup errors blocking my Cloudron backups from completing.:
Here are some logs:
https://paste.uniteddiversity.coop/?7aed63d3ef7af3ba#BiicSooyTEjs2oEY1xQoGtizyB2Lwk7C6UWgCoBZJKjP
Perhaps it could be something to do with this:
vm.max_map_count is too low
currentValue: 65530, recommendedMinimum: 1677720
@RedzzDragon it looks like mongodb is not running . If you click on the logs button, maybe it gives a hint as to why it's not running . There is a very small chance that you are using a server/CPU that does not support mongodb . Modern mongodb requires CPU to have AVX support. If this is the case, the logs will tell you as much.
(And to host WP, you don't need mongodb, it's fine if it's not running)
Thanks for sharing this. From the logs (sent to our support) this was triggered by an update to 8.0.3 where upgrading the mongodb instance didn't succeeds correctly. Unfortunately there is nothing much in the mongodb logs besides a plain "core dump" crash.
But as @hayoken2000 outlines, one can always purge mongodb data and let it start fresh, then restore those apps.
Good point. I checked the services and some of them are yellow (without error, but stalled in loading). I've restarted one app that uses mongodb and now the backup works. But it's very close to the memory limit. If this happens again, I'll increase the memory assigned.
Thanks for pointing it out.
@nebulon I was having a similar issue with Mongodb since a few days, I backuped the mongodb folder, created a new one, restarted the mongodb service, restarted the apps and the problem is solved
I am trying to only do this from the Cloudron hosted versions of Metabase/Grafana.
I followed your instructions and this worked perfectly, took the username, password, port, host, and database name from the environment variables within the Wekan web console, entered them in Metabase, and was able to connect and see the data.
Thank you!
@JohnGuan If you want to backup NodeBB's mongodb, then go to the app's backup -> create backup. In the backup, there will be a mongodbdump file.
As for importing, please see https://docs.cloudron.io/guides/import-mongodb/
@robw @alex-adestech An update on this.
Crux of the issue is that the indices name generated are too long. @alex-adestech pointed out to me that this issue only sorted out in MongoDB 4.4 and not even MongoDB 4.2. Searching through the rocket.chat issue tracker I saw only person hit this and nobody replied. Search further, I found that Rocket.Chat doesn't even support MongoDB 4.2. The releases page mentions the versions they test with - https://github.com/RocketChat/Rocket.Chat/releases. This got me wondering why we hit this issue. Well, the answer it turns out is that Cloudron generates 32 byte mongodb database names for apps. This in turn ends up affecting the length of the index.
I have made a fix now for Cloudron 5.6 that generates shorter names. (We have had to do something similar for apps using MySQL as well in the past).
