The rocketchat_apps_logs.bson collection is huge, can we reduce or remove it?

[robw]

Um... The problem may have magically disappeared.

Yep, the disk filled up. The update failed. The app restarted. At which point, storage snapped back to its original state - 300Gb gone in the blink of an eye. I started the 2.54.2 package update again, skipping the backup just in case the snapshot process hung like earlier. It ran. Rocket.Chat is now on the latest version. The disk filling process does not appear to have re-commenced.

I've seen this before. Don't watch Highlander II, it was a horrible update that should never have been made. Just go directly to Highlander III.

[robw]

Oh, the problem is not gone.

I'm not sure when that happened, Rocket.Chat had stopped working again this morning when I logged in so that's when I checked. So I assume it's Rocket.Chat again. Since the app wasn't working the logs are full of errors, so I couldn't easily see anything useful there. Since the Rocket.Chat container's file system changed in the last update, I can't seem to see the .bson files any more so I can't confirm that was the problem and I'm not sure what else to check.

There were some other automatic app updates over the last two nights (though not Rocket.Chat because it's up to date), so I suppose it's possibly not Rocket.Chat this time, I'm just assuming.

I can't see that data anywhere on the Cloudron disk from the server console. A du -h --max-depth=1 at the root level on the server shows Cloudron is using in expected the amount of space taken up by the apps in the coloured parts of the bar above even though df says the disk is full. The 'everything else' data doesn't seem to exist. So I can't tell what the data is. It appears to be living in the overlay filesystem until a Cloudron reboot, at which time it disappears. (Sorry I didn't take a screenshot.) I know nothing of these virtual file systems, so apologies if I'm explaining that wrong, just reporting what I can see.

So after a reboot it's all good again. After 30 minutes or so, there's no evidence so far that the disk is filling up or anything is changing on the disk yet:

[girish]

It appears to be living in the overlay filesystem until a Cloudron reboot,

@robw Maybe the data is somewhere in the rocket.chat container. you have to open a web terminal and inspect the /run and /tmp of the app . Another location might be inside the mongodb container. For this, docker exec -ti mongodb /bin/bash and inspect there. As you found, volume data in docker can be hard to get to the bottom of.

[stoccafisso]

I have the same "filling up space" problem on two cloudrons I administer. They are not working, as space is totally filled up. Is there a fix? What can be done?

[girish]

Did you change the log destination to filesystem? Did you try the mongodb commands suggestered earlier?

[stoccafisso]

@girish I have cloudron version 8.2.3, but can't find any "apps" konfiguration under "Settings". Where do I find the settings to change the log destination?

[girish]

@stoccafisso the issue is not related to Cloudron. It seems rocket.chat is filling up the logs (specifically, it seems apps inside rocket.chat are putting lots of logs). See https://forum.cloudron.io/post/100242 for the setting, it's inside rocket.chat

[stoccafisso]

@girish thanks a lot for helping.

I have had some frustrating hours, had to reinstall the whole cloudron in a 16GB ram droplet in order to be able to reinstall latest backup of Rocket.Chat, that backup was over 7GB, while only 2GB before the logtrouble startet.

Anyway, have it installed and working, and in Rocket.Chat made the exact setting you advice above. But in the Rocket.Chat terminal /app/data I can see no "app_logs" file?

Also when I go into mongodb and issue the commands you suggest, I get the following error message:

root@1116b395-909e-4f51-bd9e-9ad9bed3846e:/app/data# mongosh -u "${CLOUDRON_MONGODB_USERNAME}" -p "${CLOUDRON_MONGODB_PASSWORD}" ${CLOUDRON_MONGODB_HOST}:${CLOUDRON_MONGODB_PORT}/${CLOUDRON_MONGODB_DATABASE} db.getCollection('rocketchat_apps_logs').countDocuments()
bash: syntax error near unexpected token `('

I would like to have a look in mongodb, and delete logentries there if there are any. So what to do with these two issues?

[stoccafisso]

Sorry, I forgot to create the directory and make cloudron the owner. Done

[robw]

@stoccafisso I can confirm that for me this is Rocket.Chat flakiness, not Cloudron. I fear your restoration process won't help if Rocket.Chat is just going to kick off its log filling process again.

@girish I haven't yet tried moving logs to the filesystem, because (very strangely) my Rocket.Chat settings page currently appears to be empty, just a search box:

That's a Rocket.Chat mystery I haven't figured out yet.

I did try the scheduled mongodb log clearing idea directly in the app container, but it didn't seem to help. Because I can't see what's actually happening in the database, I don't know if that's because the data is filling up faster than the query runs, or because of database locking because the database is so big (100s of Gb), or something to do with virtual container file system strangeness, or something else.

At this stage my server seems to have fallen into this pattern:

• Rocket.Chat fills the disk
• Rocket.Chat attempts an update (I have auto updates on)
• Update fails because the backup fails (no disk space to prepare the backup, even though my backups go offsite to Backblaze)
• Rocket.Chat restarts, at which point the "filled" disk space moves from within the Rocket.Chat container to the virtual file system (reported as "everything else" on the Cloudron System Info page)
• A reboot releases the disk space from the virtual file system
• Start over...

The disk filling doesn't seem to start immediately any more. I don't know what triggers it.

So that means with a reboot every day or so, the server is more or less operational for general usage, except for a while right at the end when the disk is full.

I'm hoping a Rocket.Chat update will arrive soon that makes this go away.