Open rpasing opened 5 months ago
FedorAdo
commented
5 months ago Same story, it started a week ago, out of nowhere. In a day ofelia reaches 3 GB. I end up restarting. Solr, clam, ipv6 are disabled in the config. I didn’t make any other changes to the configs or the web muzzle settings. 1 domen 13 mailboxes.
testos77
commented
5 months ago Can confirm the bug. System is running in Arch Linux. Since mailcow docker installation hasn't changed before the bug ocurred, maybe a package dependency outside of the container environment causes this faulty behavior?
mkuron
commented
5 months ago This is a known problem (https://github.com/mcuadros/ofelia/issues/157, #4272] that ofelia never fixed. It was suggested a while ago to replace ofelia with its fork chadburn (#4362), but that fork isn‘t receiving much maintenance anymore either.
sadorowo
commented
5 months ago can confirm this issue, however, it's a big one for me, because I have only 2 GBs of RAM. I can only shutdown ofelia container or increase swap, which isn't ideal solution.
edit: now i managed to avoid this issue by increasing vm.swappiness in sysctl config
craeckor
commented
5 months ago @sadorowo May I ask how you managed to run Mailcow with 2GB RAM? Even on my system with Alpine 3.17 with the absolute minimum, it still eats almost 4GB of RAM. Do you have like 2GB of swap or something?
sadorowo
commented
5 months ago @sadorowo May I ask how you managed to run Mailcow with 2GB RAM? Even on my system with Alpine 3.17 with the absolute minimum, it still eats almost 4GB of RAM. Do you have like 2GB of swap or something?
oh yeah i recently added swap too, because other services that I'm running needed more
testos77
commented
5 months ago After one week my 16 GB are eaten up by this known problem (https://github.com/mcuadros/ofelia/issues/157, https://github.com/mailcow/mailcow-dockerized/issues/4272]
I really hope this bug is taken seriously and will be fixed soon.
Pingger
commented
4 months ago Same issue here.
ofelia a "crontab for docker" is one of the worst docker tools I have ever seen. A crontab should at most use a few MiB of memory and not multiple GiB.
As this apparently a known issue for years with, I petition the mailcow team to switch to something else. Literally anything else, because it can't possibly get worse.
My Systems: Ubuntu 22.04 LTS Alpine 3.17
The screenshot from the alpine instance after 20h of uptime. In ubuntu the memory consumption rises even faster...
My current workaround is a script, that I run hourly, that restarts the ofelia container if ofelia uses more than 500MB:
#!/usr/bin/fish
cd /opt/mailcow-dockerized/
# Get usage using ps
set usage (ps -o comm,rss | grep ofelia | grep -oPe "[0-9]+(k|m|g)")
# convert lowercase unit to upper-case
set usage (string upper $usage)
# convert human-readable value to bytes
set usage (numfmt --from=iec $usage)
echo $usage
if test $usage -gt 500000000;
docker-compose restart ofelia-mailcow;
else
echo "usage ok"
end
(updated script with input from https://github.com/mailcow/mailcow-dockerized/issues/5807#issuecomment-2068372025)
xenorio
commented
4 months ago Just to further showcase the severity of this: I was led here by ofelia munching on 27G of memory, maxing out all available memory space it could. Server has 64G total.
Somewhat ironically, I guess I'll set up a cron job to regularly restart the ofelia container
hydrandt
commented
4 months ago I'm temporarily resolving it with while true; do sleep 1000; docker compose restart ofelia-mailcow; done (in tmux:)
milkmaker
commented
2 months ago This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.
hydrandt
commented
2 months ago Unless this has been resolved, I believe this ticket should stay open.
longz3r
commented
1 month ago We need a way to disable it
rushowr
commented
1 month ago I'm experiencing this issue as well
rushowr
commented
1 month ago Quick note, after implementing the ofelia container restart, my system was still locking up. Creating a similar restart crontab job for the watchdog container did the trick
Contribution guidelines
I've found a bug and checked that ...
Description
Recently, ofelia seems to be eating more and more memory on my machine over time, eventually leading to an out-of-memory situation on my machine. It looks like a memory leak with ~20-30MByte/10minutes (2-3MByte/minute), which is of course not a lot, but with a long runtime I run into trouble on my 16G memory machine.
I am running mailcow on this machine in the same setup since a couple of years already. This issue though seems to be new - I cannot exactly tell since when, but not longer than a couple of weeks for sure. I see there are no changes done on mailcow since Feb 15th, so I would suspect this is an issue within ofelia or docker itself, but I don't know where to start digging, and hope to find other affected users here.
Take a look at the VSZ and RSS columns in the below output, which has been taken from within the ofelia-mailcow container. Basically, we can see that the memory footprint of the ofelia process is increasing over time.
I also checked other logs (e.g. docker-compose log of the ofelia container), but I didn't find anything suspicious (i.e. errors or something like that).
Logs:
Steps to reproduce:
Which branch are you using?
master
Which architecture are you using?
x86
Operating System:
Arch Linux
Server/VM specifications:
16G memory, 4 cores
Is Apparmor, SELinux or similar active?
no
Virtualization technology:
KVM (Hetzner Cloud Server)
Docker version:
26.0.0 (also happened with 25.0.4, upgraded 2 days ago)
docker-compose version or docker compose version:
latest
mailcow version:
2024-02
Reverse proxy:
Nginx
Logs of git diff:
Logs of iptables -L -vn:
Logs of ip6tables -L -vn:
Logs of iptables -L -vn -t nat:
Logs of ip6tables -L -vn -t nat:
DNS check: