Mailcow-dockerized: iptables on 100%

Created on 24 Oct 2019 · 7Comments · Source: mailcow/mailcow-dockerized

A proccess named iptables-nft -L uses 24/7 one cpu core on 100%.

When I stop mailcow, the cpu idles again with ~0,5 % on all cores.

My configuration is fairly stock and I only changed following lines in mailcow.conf because my server has multiple ip-addresses and for example the http port sould not interfere with a another webserver.

I have updated to the newest version, however this problem also occurred in the previous version.
There is a critical log-entry in the netfilter log which sais: (I am not quite sure, if this is related to my problem)
[CRIT] Added POSTROUTING rule for source network 172.22.1.0/255.255.255.0 to SNAT target 5.xxx.132.8

HTTP_PORT=80
HTTP_BIND=5.xxx.132.8

HTTPS_PORT=443
HTTPS_BIND=5.xxx.132.8

SMTP_PORT=5.xxx.132.8:25
SMTPS_PORT=5.xxx.132.8:465
SUBMISSION_PORT=5.xxx.132.8:587
IMAP_PORT=5.xxx.132.8:143
IMAPS_PORT=5.xxx.132.8:993
POP_PORT=5.xxx.132.8:110
POPS_PORT=5.xxx.132.8:995

SNAT_TO_SOURCE=5.xxx.132.8

dunno

Source

jank04

All 7 comments

The issue template would have helped a lot.

andryyy on 24 Oct 2019

name: Bug report
about: Cpu is on heavy load due to iptables

Prior to placing the issue, please check following: (fill out each checkbox with a X once done)

[X] I understand that not following below instructions might result in immediate closing and deletion of my issue.
[X] I have understood that answers are voluntary and community-driven, and not commercial support.
[X] I have verified that my issue has not been already answered in the past. I also checked previous issues.

Description of the bug: What kind of issue have you exactly come across?

A proccess named iptables-nft -L uses 24 hours a day one cpu core on 100%.
When I stop mailcow, the cpu idles again with ~0,5 % on all cores.
My configuration is fairly stock and I only changed given lines in mailcow.conf because my server has multiple ip-addresses because the http port sould not interfere with a another webserver.
I have updated to the newest version, however this problem also occurred in the previous version.
There is a critical log-entry in the netfilter log (I am not quite sure, if this is related to my problem).

Reproduction of said bug: How exactly do you reproduce the bug?

Simply reboot the server or docker-compose down && docker-compose up -d
execute htop and see the result

__I have tried or I do...__ (fill out each checkbox with a X if applicable)

[ ] In case of WebUI issue, I have tried clearing the browser cache and the issue persists.
[ ] I do run mailcow on a Synology, QNAP or any other sort of NAS.

System information

Further information (where applicable):

| Question | Answer |
| --- | --- |
| My operating system | Debian GNU/Linux 9 (stretch) |
| Is Apparmor, SELinux or similar active? | No |
| Virtualization technlogy (KVM, VMware, Xen, etc) | Virtuozzo |
| Server/VM specifications (Memory, CPU Cores) | 2 GiB RAM, 4 GiB Swap, 2vCores |
| Docker Version (docker version) | 19.03.4 |
| Docker-Compose Version (docker-compose version) | 1.24.1 |
| Reverse proxy (custom solution) | No |

Further notes:

Output of htop

https://www.bilder-upload.eu/upload/393615-1572038521.png
Changes in mailcow.conf

HTTP_PORT=80
HTTP_BIND=5.xxx.132.8

HTTPS_PORT=443
HTTPS_BIND=5.xxx.132.8

SMTP_PORT=5.xxx.132.8:25
SMTPS_PORT=5.xxx.132.8:465
SUBMISSION_PORT=5.xxx.132.8:587
IMAP_PORT=5.xxx.132.8:143
IMAPS_PORT=5.xxx.132.8:993
POP_PORT=5.xxx.132.8:110
POPS_PORT=5.xxx.132.8:995

SNAT_TO_SOURCE=5.xxx.132.8
Changes in docker-compose.yml to get mailcow to start

oom_kill_disable: false
Crtical log-entry in the netfilter log

Added POSTROUTING rule for source network 172.22.1.0/255.255.255.0 to SNAT target 5.xxx.132.8
Output of git diff origin/master, any other changes to the code? If so, please post them.
diff --git a/docker-compose.yml b/docker-compose.yml
index 7801cd3d..2f94a2d9 100644
--- a/docker-compose.yml
+++ b/docker-compose.yml
@@ -403,7 +403,7 @@ services:
image: mailcow/dockerapi:1.35
restart: always
build: ./data/Dockerfiles/dockerapi
- oom_kill_disable: true
- oom_kill_disable: false
  dns:
  - ${IPV4_NETWORK:-172.22.1}.254
    
    environment:
All third-party firewalls and custom iptables rules are unsupported. Please check the Docker docs about how to use Docker with your own ruleset. Nevertheless, iptabels output can help _us_ to help _you_: iptables -L -vn, ip6tables -L -vn, iptables -L -vn -t nat and ip6tables -L -vn -t nat

Output of iptables -L -vn

https://www.bilder-upload.eu/upload/3902f7-1572039022.png

Output of iptables -L -vn -t nat

https://www.bilder-upload.eu/upload/76a6a4-1572039218.png

Check docker exec -it $(docker ps -qf name=acme-mailcow) dig +short stackoverflow.com @172.22.1.254 (set the IP accordingly, if you changed the internal mailcow network) and docker exec -it $(docker ps -qf name=acme-mailcow) dig +short stackoverflow.com @1.1.1.1 - output? Timeout?

Both output:

151.101.1.69
151.101.65.69
151.101.193.69
151.101.129.69

General logs:
- Please take a look at the official documentation.

jank04 on 25 Oct 2019

Virtuozzo is the problem here. :(

andryyy on 26 Oct 2019

Interesting, can you explain why?

I thought maybe because of legacy iptables, cause I'm not using debian10, the command iptables-nft -L is looping because the command is not found on the host.

When I issue in console iptables-nft -L the output is the following:

-bash: iptables-nft: command not found

jank04 on 26 Oct 2019

👍1

I do have the same problem as jank04. When trying the command iptables-nft -L , it results to: "

-bash: iptables-nft: command not found

While this command is using 100% of CPU usage.

Meffesino on 3 Dec 2019

Don't use Virtuozzo.

andryyy on 4 Dec 2019

👎2

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.