Cloudron Forum

Our Cloudron has a huge 16 GB /tmp folder.

I see there are about 76 folders like this:

drwxr-xr-x 9 yellowtent yellowtent 4096 Aug 29 2023 box-929500886/
drwxr-xr-x 9 yellowtent yellowtent 4096 Aug 29 2023 box-940153435/
drwxr-xr-x 9 yellowtent yellowtent 4096 Aug 29 2023 box-954421980/

And 73 more. All of them have that "Aug 29 2023" date.

When I run service cloudron-updater status it seems one of them is still used:

● cloudron-updater.service - /tmp/box-243670221/scripts/installer.sh
Loaded: loaded (/run/systemd/transient/cloudron-updater.service; transient)
Transient: yes
Active: failed (Result: exit-code) since Mon 2024-05-13 03:34:36 UTC; 7h ago
Process: 11966 ExecStart=/tmp/box-243670221/scripts/installer.sh (code=exited, status=2)
Main PID: 11966 (code=exited, status=2)

May 13 03:34:36 FV-Cloudron systemd[1]: Started /tmp/box-243670221/scripts/installer.sh.
May 13 03:34:36 FV-Cloudron systemd[1]: cloudron-updater.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
May 13 03:34:36 FV-Cloudron systemd[1]: cloudron-updater.service: Failed with result 'exit-code'.

Can these /tmp/box-* folders be removed?

Thanks,
Martin

Hello girish,

I tried that command and got:

May 13 12:52:45 FV-Cloudron systemd[1]: Started /tmp/box-1040295979/scripts/installer.sh.
May 13 12:52:45 FV-Cloudron systemd[1]: cloudron-updater.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
May 13 12:52:45 FV-Cloudron systemd[1]: cloudron-updater.service: Failed with result 'exit-code'.

I run it manually and I see it needs Ubuntu 20.04 or above. Too bad it did not show that error on Cloudron web interface, it would save us a lot of trouble.

Thanks,
Martin

Hello Cloudron support,

I found that our Grav app is 5 GB. I had a look with the console and it's all in /app/data/backup - it contains 167 backup files, each one is 32 MB.

I'm not sure what's creating these backups, we do not use any cronjob for that app.

Could you please make sure that folder is cleaned up properly?

Thanks,
Martin

Hello,

we are running in an issue where our Rocket.Chat instance is unable to properly send messages after about 20 hours of uptime. Whenever I try to send a message to somebody the message appears gray, indicating that it was not yet sent. The user does actually get the message though, but it impossible to chat like that.

I wanted to check some log files, but I only found that Rocket.Chat logs errors to stdout here: https://github.com/RocketChat/Docker.Official.Image/issues/16 So I tried to run the command, but it have me the error:

# docker logs e5648bb067fe
Error response from daemon: configured logging driver does not support reading

I tried to attach to the docket stdout, but nothing would ever appear:

 docker attach e5648bb067fe

I tried to inspect the files on docker too by logging in:

docker exec -it -u root e5648bb067fe /bin/bash

I tried to check the Mongo containers as well:

# docker exec -it -u root 48f5e963462c /bin/bash

Once there I was able to connect to the database:

root@mongodb:/# mongo

But then even basic command like list of tables failed:

rs0:PRIMARY> use rocketchat
switched to db rocketchat
rs0:PRIMARY> show tables;
Warning: unable to run listCollections, attempting to approximate collection names by parsing connectionStatus

Could you please provide any insight?

Thanks,
Martin

@girish I tried with this in Cloudron Crontab:

0 * * * * mongosh -u "${CLOUDRON_MONGODB_USERNAME}" -p "${CLOUDRON_MONGODB_PASSWORD}" ${CLOUDRON_MONGODB_HOST}:${CLOUDRON_MONGODB_PORT}/${CLOUDRON_MONGODB_DATABASE} --eval "const collection = db.getCollection('rocketchat_apps_logs'); const toDelete = collection.find().sort({ _createdAt: -1 }).skip(1000); toDelete.forEach(doc => collection.deleteOne({ _id: doc._id }));"

It seems to work.

Update: Fixed the schedule to happen once per hour.

Hello @girish

I did use similar backups and then the rocketchat_apps_logs.bson file got much smaller.

However it only took 3 days and it was too big once again.

So I was wondering if that file has anything to do with Cloudron backups rocketchat_apps_logs.bson as it seems to be created then. But as I said I disabled Cloudron backups for Rocket.chat and these files in /var/lib/docker/volumes/569e4faada8ec760513bad87aa4c494f4792ebf6e5ef0dbd3f9f539d8a0b0ab6/_data/e95dbcf8-8480-47a3-834f-ea3dfbede698 still got created tonight.

Thanks,
Martin

Hello @girish

We run into the same issue with rocketchat_apps_logs.bson being too large.

It's stored in the /var/lib/docker/volumes/569e4faada8ec760513bad87aa4c494f4792ebf6e5ef0dbd3f9f539d8a0b0ab6/_data/e95dbcf8-8480-47a3-834f-ea3dfbede698 folder.

I though that if we disable Cloudron backups for Rocket.chat these files will stop being created but it seems it did not help.

The problem is that the rocketchat_apps_logs table suddenly gets thousands of rows every day and the rocketchat_apps_logs.bson backup file that is created for it is much bigger than the database size of the table. I got about 10 GB file for 2 GB of Mongodb table size

I tried to change the "Apps' Source Package Storage type" in Rochat.chat as you suggested.

Thanks,
Martin