-
-
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
ARM64 php-fpm upgrade to alpine 3.20 recreates known "empty" /debug startpage issue #6149
Comments
I am also experiencing this bug after the upgrade on an arm64 system. Mail seems to be working luckily. |
Same issue for me on a Debian 12 host with 2024-11, had to roll back. |
I'm also having this issue on Ubuntu 22.04 LTS host. |
I could not replicate the issue on my ARM64 machine. Can you also post the nginx logs? |
After navigating to /debug and back to /admin, I get the "Array" popup pictured: Enabling DEV_MODE=y and browsing to /debug gives me:
NGINX logs from the most recent run, with dev mode:
Hope this helps. |
please try the following commands. it seems that the broken c-ares package is still in the alpine:3.20 docker image |
No change for me. Performed updates okay, restarted stack, same error in debug mode. Output from the upgrade was:
|
don't restart the stack after the apk update. just update and try if the issue is resolved |
Forgot to mention, I did try it before restarting, no joy. |
@mitchplze Which timezone did you setup inside mailcow.conf? |
America/Vancouver |
@mitchplze since I can't reproduce the issue, could you try out this fix? mailcow-dockerized/data/web/debug.php Lines 25 to 54 in 0a58aa2
There is probably a container now showing |
@FreddleSpl0it: not @mitchplze, but I got the same problem on an x64 machine.
didn't help, and the changes in debug.php unfortunately seem to not fix the problem, either. |
@FreddleSpl0it: I applied your suggested changes to debug.php, commenting out the existing block altogether, and adding yours below. No change really. debug.php shows: Restarted stack completely, no change Btw not sure if needed, but my host:
|
I have the same issue so it seems not to be ARM realted. Update:
I suggest to remove ARM64 from the issue subject to better address this issue. |
@mitchplze i need to see the
|
Please be aware that the solution seems to be also discussed here: then saving the file and running ./update.sh again fixed the issue for me. |
That is not a solution, only a temporary workaround. |
Agree on this |
* compose: bump php-fpm container to correctly use patched c-ares * [Web] check $containers_info contains required fields --------- Co-authored-by: FreddleSpl0it <[email protected]>
* update.sh: precaution ask for deletion of dns_blocklists.cf if old format (#6154) * [Web] Updated lang.zh-cn.json (#6151) [Web] Updated lang.zh-cn.json Co-authored-by: Easton Man <[email protected]> * compose: bump sogo version to include 5.11.2 (#6156) * php: use correct php image + workaround of #6149 (#6159) * compose: bump php-fpm container to correctly use patched c-ares * [Web] check $containers_info contains required fields --------- Co-authored-by: FreddleSpl0it <[email protected]> --------- Co-authored-by: milkmaker <[email protected]> Co-authored-by: Easton Man <[email protected]> Co-authored-by: FreddleSpl0it <[email protected]>
I'm still not sure what the problem is, but I've added a workaround and hope it helps to display the |
Thank you. @FreddleSpl0it: Sorry but that doesn't appear to do what you need. I checked that folder and there is no output file as expected. I also checked after a full stack restart and no change. |
I just upgraded to Which I think means I'm now on 1.91.1 and works ok. |
Can confirm after the update the issue appears to be resolved. |
Yup, same here. Thanks for the quick delivery of the fix, appreciated! |
Dear all, Can also confirm that upgrading and reverting manual downgrade fixed it. Are we fine to close? |
I believe today's patch to 2024-11a only works-around the problem temporarily, to un-break the product. AFAIU, devs still need to figure out what's causing the issue. |
I changed back to 1.91 |
I would leave this issue open, as it's currently just a workaround. Could you guys verify that all containers are displayed on the |
@FreddleSpl0it: I think they are all showing up properly for me. Note: I have Solr disabled with |
* compose: bump php-fpm container to correctly use patched c-ares * [Web] check $containers_info contains required fields --------- Co-authored-by: FreddleSpl0it <[email protected]>
Contribution guidelines
I've found a bug and checked that ...
Description
After upgrade to alpine 3.20 php: upgrade to alpine 3.20 (base os) #6106 the bug resolved in e.g. #5927 is back.
See also comment of another user #5927 (comment)
Logs:
Steps to reproduce:
Which branch are you using?
master
Which architecture are you using?
ARM64 (aarch64)
Operating System:
Ubuntu 24.04.1 LTS
Server/VM specifications:
tested on 2 different installs e.g. 20GB RAM / 3vCores
Is Apparmor, SELinux or similar active?
no
Virtualization technology:
KVM
Docker version:
27.3.1
docker-compose version or docker compose version:
2.29.7
mailcow version:
2024-11
Reverse proxy:
Cloudflare
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: