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. |
Will there be another hotfix release, like |
|
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 actually still ran into this issue with the most recent 2024-08 and 2024-08a version resulting in the same error pattern ( |
|
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? |
and others
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: