Closed chriscroome closed 5 months ago
awsumco
commented
8 months ago My 2 cents here, a suggestion would be to add an environment variable such as ACME_INTERVAL which would be used in acme.sh. In the sleep 1d line at the end of the function.
IE sleep $ACME_INTERVAL
in the docker-compose.yml file under mallow-amce service something like:
${ACME_INTERVAL:-1d}
milkmaker
commented
6 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.
chriscroome
commented
5 months ago Please re-open this issue as it has not been addressed or solved.
Contribution guidelines
I've found a bug and checked that ...
Description
One of our Mailcow servers is fairly large, 64GB RAM, 12 CPU cores, 1.5TB disk, 327 domains and 1,674 mailboxes.
Almost every day the Postfix, Dovecot and Ngnix containers are restarted twice in quick succession and as a result IMAP and SMTP services are unavailable for around 5 minutes, during this time clients cannot send or receive email, when the containers are back up and running we get a
Subject: Watchdog ALERT: certcheckemail — I'm convinced that this downtime is related to certificate renewals.The issue is not so much the annoying downtime, (it is however very annoying) but rather that all attempts to get the renewals to take place in the middle of the night UK time have failed (I tried force renewing all certs at 3am for example) — they always seem to take place during office hours and as a result we very often get complaints from users that their email is not working during the outage.
We currently have a cron job to renew certs monthly:
The
mailcow_cert.shscript:This issue has been ongoing for over a year, we have a support license for this server and I did raise a Servercow ticket for this but that didn't result in a solution.
If there is currently no way to control the time of day that certificate renewals are done can this be considered as a feature request?
Logs:
Example Watchdog email:
Example
docker psresults illustrating the uptime of the containers:We have logs going to
/var/log/syslogand I'd be happy togrep/zgrepthem if anyome has suggestion for patterns — they are too big to post here!Steps to reproduce:
Nothing need to be done to reproduce this, it happens on it's own almost every day.
Which branch are you using?
master
Operating System:
Debian Bullseye 11.8
Server/VM specifications:
64GB RAM, 12 CPU cores, 1.5TB disk
Is Apparmor, SELinux or similar active?
No
Virtualization technology:
Xen
Docker version:
24.0.7
docker-compose version or docker compose version:
v2.21.0
mailcow version:
2023-12a
Reverse proxy:
None
Logs of git diff:
Omitted as it triggered the "There was an error creating your issue: body is too long, body is too long (maximum is 65536 characters)." warning from GitHub that prevented this form being submitted.
Logs of iptables -L -vn:
Omitted as it triggered the "There was an error creating your issue: body is too long, body is too long (maximum is 65536 characters)." warning from GitHub that prevented this form being submitted.
Logs of ip6tables -L -vn:
Omitted as it triggered the "There was an error creating your issue: body is too long, body is too long (maximum is 65536 characters)." warning from GitHub that prevented this form being submitted.
Logs of iptables -L -vn -t nat:
Omitted as it triggered the "There was an error creating your issue: body is too long, body is too long (maximum is 65536 characters)." warning from GitHub that prevented this form being submitted.
Logs of ip6tables -L -vn -t nat:
Omitted as it triggered the "There was an error creating your issue: body is too long, body is too long (maximum is 65536 characters)." warning from GitHub that prevented this form being submitted.
DNS check: