-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Blank /debug page after upgrade to latest version #5928
Comments
I am having this issue too |
I have the same problem. If I go straight to /admin, I get a red message saying "array" but I haven't changed/saved anything (Only for the first load). But all the pages work, except /debug. /SoGo/ works all the time. A lot of things are loaded for a very long time. I dont have ARM but the newest version of Docker (Docker version 27.0.2, build 912c1dd) |
Also seeing this. (ARM 64 docker.) |
Getting some inspiration from #5924 I have a search domain specified in /etc/resolv.conf - commenting it out and restarting the docker containers fixes the issue, the /debug page now loads normally. If you're experiencing this issue then please try this as a temp fix, hopefully a more permanent solution can be found. |
I had the same issue, but commenting out the search domain solved the problem. Thx @delendum |
In my resolv.conf I have : domain somedomain.com Removing both domain and search lines resolved the problem for me. Removing only search was doing nothing. I don't know how, but when I reboot, the two lines are back. So I used : chattr +i /etc/resolv.conf It's now working, but those lines were there before with no issue. The last update broke something for sure. |
Having this same issue as well. I'm on a VM so should I just roll back the update and wait until this is fixed? |
I have the same problem with the Debian 12. Deleting the search entry in resolv.conf works as a workaround. |
I tried it here and it didn't work. I'm using ARM on Oracle Cloud |
I had the same issue after update from 2024-04 to 2024-06a, reverted back to 2024-04 until a fix is available. Debian Buster with Kernel: 4.19.0-26-amd64 |
Is there a step-by-step guide explaining how to revert the update? |
Hi Pedro, my Mailcow is running on a VM in Proxmox, that's why I did a restore to 2024-04. |
If nothing helps, edit the
to
and do a |
I had to revert the php-fpm version and then it started working again. |
Is there a chance of a quick permanent fix? The fix for #5924 seemed to be quite manageable. Are the problems related? |
Can someone try the newly uploaded phpfpm:1.89 container? Because it seems it is all related to the bind-utils package from alpine which has been installed in this image version. To try out: simply change the image tag (as described from @mrclschstr) to 1.89 instead of 1.87/1.88 depending on what you currently using... |
I gave it a try, with the new phpfpm:1.89 I receive the following errors: user@machine:/opt/mailcow-dockerized# docker compose logs --tail=200 php-fpm-mailcow |
Ok still not resolved then... |
Did you have anything written in your resolv.conf e.g. search oprion? |
Yes, I reverted my resolv.conf to a version with search option to test the fix. |
Same issue here, rollback to 07838ccb132259267738a93b5d14cbe82f433166 helped |
Yeah that rolledback version is the version before Alpine 3.19 and upwards. But that did not help on the long run. |
This works for now |
Can someone try out the image mailcow/phpfpm:1.89. This one features a rebuild php container. Simply do what @vineethmn said but only with the different tag i mentioned. |
Hello, I had rolled back the mailcow/phpfpm:1.88 version to the mailcow/phpfpm:1.87 version. This resolved the issue of a blank page when accessing the /debug URL Testing now by changing the tag to version (mailcow/phpfpm:1.89) as suggested by @DerLinkman, there are no problems. No failures so far using version 1.89. |
1.89 does indeed fix the problem as @totalinfra also confirmed. |
I can also confirm that the new build fixes the issue for me. |
Thank you! Sounds good. |
Sounds like it is solving it, so yeah probably, thats why i asked to test :) |
This comment was marked as outdated.
This comment was marked as outdated.
Today... |
It seems that the curl error/bug is also contained in the acme container: So far only new installations seem to be affected, but I could imagine that the certificate renewal is also no longer working correctly. At the moment I have no proof of my claim... |
Could be as i said i cannot recreate it anywhere but i believe there is something related to it. Then we have to reroll all Alpine Packages which runs curl. I cannot do anything else as this is clearly a Alpine Package problem... |
Reopening this issue as I want to help the Alpine Devs to track down the root cause. I still can't reproduce this issue. However I'm using Debian 12 always with the default Network provider "Interfaces" as the base os. I read that some of you are using netplan... maybe I can recreate the issue when I try a Ubuntu with netplan though... |
I recieve the Running on default Ubuntu 24.04 Image from Hetzner Cloud Server Docker Version: 27.2.0 |
Ran into this myself today, ipv6 was disabled worked until update, then failed. reverted php-fpm and working again. (Arch, docker 27.2) |
That cannot be... at least not with the c-ares bug then. as these versions did not have c-ares bundles. Can someone check which php-fpm os release file is located inside the container?.... |
Or more easier... can someone let me visit his machine to finally see this error with my own eyes? I was no where able to reproduce it... if not then it won't be fixed in the near future, i'm sorry but without reproduction i cannot fix the issues. If someone allows me to visit his machine please pm me on Telegram: https://t.me/DerLinkman |
The output from
|
I was able to fix the problem. The error occurred for me because I manually created the following network:
and then added it via
This created the network After removing the manually created network, deleting the network from the |
@iamspido's case was not a bug regarding mailcow, instead a "issue" of the system like he described. We run mailcow tests etc. always depending on the official documentation installation guide/standard in his case the origin of his issue was a standard difference... Does someone have a different mailcow setup as described in our docs? |
I think, the bug is still not fixed: #4571 (comment) I have absolutly no idea... :( I have a default up-to-date Ubuntu in Hetzner Cloud and have a default install in "/opt/mailcow-dockerized". What can I do to get my Mailcow's /debug entry page back? |
We'll publish 2024-11a today which is patching the php container. Maybe it is resolving this. |
Still getting the error with the latest version - 2024-11a -. I had to reset php-fpm-mailcow to version 1.87 to resolve the error. |
2024-11a is not published yet... so. |
Same behavior in 2024-11a, php-fpm still cant find mysql.. |
Then unfortunately won't fix until analyse this any further. I (as i said 100000000 times) cannot reproduce this and so i won't anymore. I'm sorry :( |
Hello, I can easily replicate this in a test VM. Any help is appreciated. This is clearly an issue with the image version. |
Contribution guidelines
I've found a bug and checked that ...
Description
Logs:
Steps to reproduce:
Which branch are you using?
master
Which architecture are you using?
x86
Operating System:
Debian 12
Server/VM specifications:
VM: 32GB RAM, 4 Cores
Is Apparmor, SELinux or similar active?
Yes
Virtualization technology:
Virtualbox
Docker version:
27.0.2, build 912c1dd
docker-compose version or docker compose version:
v2.28.1
mailcow version:
2024-06a
Reverse proxy:
HAProxy
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:
The text was updated successfully, but these errors were encountered: