Open ReqX opened 3 days ago
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
try to navigate to /admin
and see if there is an Error Alert in the bottom right corner.
If you don't see an Error Alert try setting DEV_MODE=y
in mailcow.conf
and do a docker compose up -d
. Does navigating to /debug
now shows a php error? (Disable the DEV_MODE after that)
After navigating to /debug and back to /admin, I get the "Array" popup pictured:
Enabling DEV_MODE=y and browsing to /debug gives me:
Fatal error: Uncaught TypeError: Cannot access offset of type string on string in /web/debug.php:32 Stack trace: #0 {main} thrown in /web/debug.php on line 32
NGINX logs from the most recent run, with dev mode:
2024/11/10 23:39:09 [notice] 30#30: gracefully shutting down
2024/11/10 23:39:09 [notice] 34#34: gracefully shutting down
2024/11/10 23:39:09 [notice] 33#33: gracefully shutting down
2024/11/10 23:39:09 [notice] 35#35: gracefully shutting down
2024/11/10 23:39:09 [notice] 28#28: exiting
2024/11/10 23:39:09 [notice] 29#29: gracefully shutting down
2024/11/10 23:39:09 [notice] 31#31: exiting
2024/11/10 23:39:09 [notice] 32#32: gracefully shutting down
2024/11/10 23:39:09 [notice] 30#30: exiting
2024/11/10 23:39:09 [notice] 34#34: exiting
2024/11/10 23:39:09 [notice] 35#35: exiting
2024/11/10 23:39:09 [notice] 29#29: exiting
2024/11/10 23:39:09 [notice] 33#33: exiting
2024/11/10 23:39:09 [notice] 32#32: exiting
2024/11/10 23:39:09 [notice] 26#26: exiting
2024/11/10 23:39:09 [notice] 36#36: exiting
2024/11/10 23:39:09 [notice] 28#28: exit
2024/11/10 23:39:09 [notice] 27#27: exit
2024/11/10 23:39:09 [notice] 35#35: exit
2024/11/10 23:39:09 [notice] 21#21: exit
2024/11/10 23:39:09 [notice] 31#31: exit
2024/11/10 23:39:09 [notice] 25#25: exit
2024/11/10 23:39:09 [notice] 29#29: exit
2024/11/10 23:39:09 [notice] 30#30: exit
2024/11/10 23:39:09 [notice] 33#33: exit
2024/11/10 23:39:09 [notice] 34#34: exit
2024/11/10 23:39:09 [notice] 32#32: exit
2024/11/10 23:39:09 [notice] 20#20: exit
2024/11/10 23:39:09 [notice] 26#26: exit
2024/11/10 23:39:09 [notice] 1#1: signal 17 (SIGCHLD) received from 25
2024/11/10 23:39:09 [notice] 1#1: worker process 25 exited with code 0
2024/11/10 23:39:09 [notice] 1#1: worker process 27 exited with code 0
2024/11/10 23:39:09 [notice] 1#1: worker process 26 exited with code 0
2024/11/10 23:39:09 [notice] 1#1: worker process 30 exited with code 0
2024/11/10 23:39:09 [notice] 1#1: signal 29 (SIGIO) received
2024/11/10 23:39:09 [notice] 1#1: signal 17 (SIGCHLD) received from 27
2024/11/10 23:39:09 [notice] 1#1: signal 17 (SIGCHLD) received from 35
2024/11/10 23:39:09 [notice] 1#1: worker process 35 exited with code 0
2024/11/10 23:39:09 [notice] 1#1: worker process 32 exited with code 0
2024/11/10 23:39:09 [notice] 1#1: signal 29 (SIGIO) received
2024/11/10 23:39:09 [notice] 1#1: signal 17 (SIGCHLD) received from 32
2024/11/10 23:39:09 [notice] 1#1: signal 17 (SIGCHLD) received from 29
2024/11/10 23:39:09 [notice] 1#1: worker process 29 exited with code 0
2024/11/10 23:39:09 [notice] 1#1: signal 29 (SIGIO) received
2024/11/10 23:39:09 [notice] 1#1: signal 17 (SIGCHLD) received from 34
2024/11/10 23:39:09 [notice] 1#1: worker process 34 exited with code 0
2024/11/10 23:39:09 [notice] 1#1: cache manager process 36 exited with code 0
2024/11/10 23:39:09 [notice] 1#1: worker process 31 exited with code 0
2024/11/10 23:39:09 [notice] 1#1: worker process 20 exited with code 0
2024/11/10 23:39:09 [notice] 1#1: worker process 21 exited with code 0
2024/11/10 23:39:09 [notice] 1#1: worker process 33 exited with code 0
2024/11/10 23:39:09 [notice] 1#1: signal 29 (SIGIO) received
2024/11/10 23:39:09 [notice] 1#1: signal 17 (SIGCHLD) received from 36
2024/11/10 23:39:09 [notice] 1#1: signal 17 (SIGCHLD) received from 28
2024/11/10 23:39:09 [notice] 1#1: worker process 28 exited with code 0
2024/11/10 23:39:09 [notice] 1#1: signal 29 (SIGIO) received
2024/11/10 23:39:21 [notice] 1#1: using the "epoll" event method
2024/11/10 23:39:21 [notice] 1#1: nginx/1.27.2
2024/11/10 23:39:21 [notice] 1#1: built by gcc 13.2.1 20240309 (Alpine 13.2.1_git20240309)
2024/11/10 23:39:21 [notice] 1#1: OS: Linux 6.1.0-25-arm64
2024/11/10 23:39:21 [notice] 1#1: getrlimit(RLIMIT_NOFILE): 1048576:1048576
2024/11/10 23:39:21 [notice] 1#1: start worker processes
2024/11/10 23:39:21 [notice] 1#1: start worker process 20
2024/11/10 23:39:21 [notice] 1#1: start worker process 21
2024/11/10 23:39:21 [notice] 1#1: start worker process 22
2024/11/10 23:39:21 [notice] 1#1: start worker process 23
2024/11/10 23:39:21 [notice] 1#1: start worker process 24
2024/11/10 23:39:21 [notice] 1#1: start worker process 25
2024/11/10 23:39:21 [notice] 1#1: start worker process 26
2024/11/10 23:39:21 [notice] 1#1: start worker process 27
2024/11/10 23:39:21 [notice] 1#1: start worker process 28
2024/11/10 23:39:21 [notice] 1#1: start worker process 29
2024/11/10 23:39:21 [notice] 1#1: start worker process 30
2024/11/10 23:39:21 [notice] 1#1: start worker process 31
2024/11/10 23:39:21 [notice] 1#1: start worker process 32
2024/11/10 23:39:21 [notice] 1#1: start worker process 33
2024/11/10 23:39:21 [notice] 1#1: start worker process 34
2024/11/10 23:39:21 [notice] 1#1: start worker process 35
2024/11/10 23:39:21 [notice] 1#1: start cache manager process 36
2024/11/10 23:39:21 [notice] 1#1: start cache loader process 37
2024/11/10 23:39:22 [error] 21#21: *1 connect() failed (111: Connection refused) while connecting to upstream, client: 172.22.111.11, server: _, request: "HEAD /settings.php HTTP/1.1", upstream: "fastcgi://172.22.111.7:9001", host: "nginx"
2024/11/10 23:39:22 [error] 21#21: *1 connect() failed (111: Connection refused) while connecting to upstream, client: 172.22.111.11, server: _, request: "HEAD /settings.php HTTP/1.1", upstream: "fastcgi://[fd4d:6169:6c63:6f77::a]:9001", host: "nginx"
172.22.111.11 - - [10/Nov/2024:23:39:22 -0800] "HEAD /settings.php HTTP/1.1" 502 0 "-" "rspamd-3.10.2"
172.22.111.7 - - [10/Nov/2024:23:39:35 -0800] "GET /settings.php HTTP/1.1" 200 2170 "-" "-"
135.181.111.11 - - [10/Nov/2024:23:39:35 -0800] "GET /admin HTTP/1.1" 499 0 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/18.1 Safari/605.1.15"
135.181.111.11 - - [10/Nov/2024:23:39:35 -0800] "GET /debug HTTP/1.1" 200 176 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/18.1 Safari/605.1.15"
172.22.111.11 - - [10/Nov/2024:23:39:45 -0800] "HEAD /forwardinghosts.php HTTP/1.1" 200 0 "-" "rspamd-3.10.2"
172.22.111.11 - - [10/Nov/2024:23:39:45 -0800] "GET /forwardinghosts.php HTTP/1.1" 200 27 "-" "rspamd-3.10.2"
fd4d:6169:6c63:6f77::f - - [10/Nov/2024:23:39:46 -0800] "GET /forwardinghosts.php?host=23.94.160.137 HTTP/1.1" 200 19 "-" "curl/7.88.1"
fd4d:6169:6c63:6f77::f - - [10/Nov/2024:23:39:48 -0800] "GET /forwardinghosts.php?host=80.94.95.239 HTTP/1.1" 200 19 "-" "curl/7.88.1"
172.22.111.12 - - [10/Nov/2024:23:40:17 -0800] "GET / HTTP/1.1" 200 15 "-" "check_http/v (nagios-plugins 2.4.5)"
127.0.0.1 - nadia@na0.ca [10/Nov/2024:23:40:17 -0800] "GET /sogo-auth HTTP/1.0" 200 0 "-" "Apple-iPhone14C4/2202.83"
2024/11/10 23:40:21 [notice] 37#37: http file cache: /tmp 0.000M, bsize: 4096
2024/11/10 23:40:21 [notice] 1#1: signal 17 (SIGCHLD) received from 37
2024/11/10 23:40:21 [notice] 1#1: cache loader process 37 exited with code 0
2024/11/10 23:40:21 [notice] 1#1: signal 29 (SIGIO) received
127.0.0.1 - redacted@redacted [10/Nov/2024:23:40:21 -0800] "GET /sogo-auth HTTP/1.0" 200 0 "-" "Apple-iPhone16C1/2202.83"
127.0.0.1 - redacted@redacted [10/Nov/2024:23:40:25 -0800] "GET /sogo-auth HTTP/1.0" 200 0 "-" "Apple-iPhone16C1/2202.83"
172.22.111.11 - - [10/Nov/2024:23:40:26 -0800] "HEAD /forwardinghosts.php HTTP/1.1" 200 0 "-" "rspamd-3.10.2"
172.22.111.11 - - [10/Nov/2024:23:40:26 -0800] "GET /forwardinghosts.php HTTP/1.1" 200 27 "-" "rspamd-3.10.2"
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
docker compose exec -it php-fpm-mailcow apk update
docker compose exec -it php-fpm-mailcow apk upgrade
please try the following commands. it seems that the broken c-ares package is still in the alpine:3.20 docker image
docker compose exec -it php-fpm-mailcow apk update
docker compose exec -it php-fpm-mailcow apk upgrade
No change for me. Performed updates okay, restarted stack, same error in debug mode.
Output from the upgrade was:
root@hs1:/srv/mailcow-dockerized# docker compose exec -it php-fpm-mailcow apk upgrade
Upgrading critical system libraries and apk-tools:
(1/1) Upgrading apk-tools (2.14.4-r0 -> 2.14.4-r1)
Executing busybox-1.36.1-r29.trigger
Continuing the upgrade transaction with new apk-tools:
(1/21) Upgrading libcrypto3 (3.3.2-r0 -> 3.3.2-r1)
(2/21) Upgrading libssl3 (3.3.2-r0 -> 3.3.2-r1)
(3/21) Upgrading c-ares (1.28.1-r0 -> 1.33.1-r0)
(4/21) Upgrading libcurl (8.9.1-r2 -> 8.11.0-r1)
(5/21) Upgrading curl (8.9.1-r2 -> 8.11.0-r1)
(6/21) Upgrading libexpat (2.6.3-r0 -> 2.6.4-r0)
(7/21) Upgrading librsvg (2.58.0-r0 -> 2.58.5-r0)
Executing librsvg-2.58.5-r0.post-upgrade
(8/21) Upgrading mariadb-common (10.11.8-r0 -> 10.11.10-r0)
Executing mariadb-common-10.11.10-r0.post-upgrade
(9/21) Upgrading mariadb-client (10.11.8-r0 -> 10.11.10-r0)
(10/21) Upgrading mysql-client (10.11.8-r0 -> 10.11.10-r0)
(11/21) Upgrading openssl (3.3.2-r0 -> 3.3.2-r1)
(12/21) Upgrading samba-util-libs (4.19.6-r0 -> 4.19.9-r0)
(13/21) Upgrading libwbclient (4.19.6-r0 -> 4.19.9-r0)
(14/21) Upgrading ldb (2.8.0-r1 -> 2.8.2-r0)
(15/21) Upgrading samba-libs (4.19.6-r0 -> 4.19.9-r0)
(16/21) Upgrading samba-common (4.19.6-r0 -> 4.19.9-r0)
(17/21) Upgrading libarchive (3.7.6-r0 -> 3.7.7-r0)
(18/21) Upgrading libauth-samba (4.19.6-r0 -> 4.19.9-r0)
(19/21) Upgrading samba-client-libs (4.19.6-r0 -> 4.19.9-r0)
(20/21) Upgrading libsmbclient (4.19.6-r0 -> 4.19.9-r0)
(21/21) Upgrading samba-client (4.19.6-r0 -> 4.19.9-r0)
Executing busybox-1.36.1-r29.trigger
Executing ca-certificates-20240705-r0.trigger
Executing gdk-pixbuf-2.42.12-r0.trigger
OK: 253 MiB in 174 packages
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. Re-running your apk upgrades says up-to-date, even after restart.
@mitchplze Which timezone did you setup inside mailcow.conf?
@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? Replace the fixed code here https://github.com/mailcow/mailcow-dockerized/blob/0a58aa293a69d15f4f0c5385cc57d2a55ca7295b/data/web/debug.php#L25-L54
// containers
$containers = (array) docker('info');
if ($clamd_status === false) unset($containers['clamd-mailcow']);
if ($solr_status === false) unset($containers['solr-mailcow']);
ksort($containers);
foreach ($containers as $container => $container_info) {
date_default_timezone_set('UTC');
if (isset($container_info['State']) && is_array($container_info['State']) && isset($container_info['State']['StartedAt'])){
$StartedAt = date_parse($container_info['State']['StartedAt']);
} else {
$StartedAt = null;
}
if (isset($StartedAt) && $StartedAt['hour'] !== false) {
$date = new \DateTime();
$date->setTimestamp(mktime(
$StartedAt['hour'],
$StartedAt['minute'],
$StartedAt['second'],
$StartedAt['month'],
$StartedAt['day'],
$StartedAt['year']));
try {
$user_tz = new DateTimeZone(getenv('TZ'));
$date->setTimezone($user_tz);
$started = $date->format('r');
} catch(Exception $e) {
$started = '?';
}
}
else {
$started = '?';
}
$containers[$container]['State']['StartedAtHR'] = $started;
}
There is probably a container now showing ?
as the starting time on the debug page
@FreddleSpl0it: not @mitchplze, but I got the same problem on an x64 machine.
docker compose exec -it php-fpm-mailcow apk update
docker compose exec -it php-fpm-mailcow apk upgrade
didn't help, and the changes in debug.php unfortunately seem to not fix the problem, either.
I'm in the same boat. If you wait (or forget) your tab for a while, I got greeted with a very strange page.
@mitchplze since I can't reproduce the issue, could you try out this fix? Replace the fixed code here
There is probably a container now showing
?
as the starting time on the debug page
@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: Fatal error: Uncaught TypeError: Cannot access offset of type string on string in /web/debug.php:88 Stack trace: #0 {main} thrown in /web/debug.php on line 88
Restarted stack completely, no change
Btw not sure if needed, but my host:
root@hs1:/srv/mailcow-dockerized# uname -a
Linux hs1 6.1.0-25-arm64 #1 SMP Debian 6.1.106-3 (2024-08-26) aarch64 GNU/Linux
I have the same issue so it seems not to be ARM realted. /debug after login is a blank page; typing /admin shows the admin page; but clicking around on the admin page results in: An unknown error occured: TypeError Object( [message:protected] => Cannot access offset of type string on string [string:Error:private] => [code:protected] => 0 [file:protected] => /web/debug.php [line:protected] => 32 [trace:Error:private] => Array ( ) [previous:Error:private] => ) My system is as following: ubuntu@mailcow:/opt/mailcow-dockerized$ uname -a Linux mailcow 6.8.0-1015-oracle #15~22.04.1-Ubuntu SMP Wed Oct 9 15:47:17 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
Update:
I suggest to remove ARM64 from the issue subject to better address this issue.
@mitchplze i need to see the $containers
value to debug this. Could you add the following on line 61
before the foreach
loop and send me the file?
file_put_contents("/web/templates/cache/containers_res.json", json_encode($containers, JSON_PRETTY_PRINT));
Please be aware that the solution seems to be also discussed here: https://github.com/mailcow/mailcow-dockerized/issues/5927 This hint helped me, all working fine now: Editing /opt/mailcow-dockerized/docker-compose.yml and changing line: php-fpm-mailcow: image: mailcow/phpfpm:1.91 to php-fpm-mailcow: image: mailcow/phpfpm:1.90
then saving the file and running ./update.sh again fixed the issue for me. Thanks @ajnadox for providing
Please be aware that the solution seems to be also discussed here: #5927 This hint helped me, all working fine now: Editing /opt/mailcow-dockerized/docker-compose.yml and changing line: php-fpm-mailcow: image: mailcow/phpfpm:1.91 to php-fpm-mailcow: image: mailcow/phpfpm:1.90
then saving the file and running ./update.sh again fixed the issue for me. Thanks @ajnadox for providing
That is not a solution, only a temporary workaround.
Please be aware that the solution seems to be also discussed here: #5927 This hint helped me, all working fine now: Editing /opt/mailcow-dockerized/docker-compose.yml and changing line: php-fpm-mailcow: image: mailcow/phpfpm:1.91 to php-fpm-mailcow: image: mailcow/phpfpm:1.90 then saving the file and running ./update.sh again fixed the issue for me. Thanks @ajnadox for providing
That is not a solution, only a temporary workaround.
Agree on this
I'm still not sure what the problem is, but I've added a workaround and hope it helps to display the /debug
page
https://github.com/mailcow/mailcow-dockerized/pull/6160/files#diff-1ce35b9f8d77569adc5c31790cf2f8dd8bc9646a23a03174d23b2984c954325d.
@mitchplze i need to see the
$containers
value to debug this. Could you add the following on line61
before theforeach
loop and send me the file?file_put_contents("/web/templates/cache/containers_res.json", json_encode($containers, JSON_PRETTY_PRINT));
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'm still not sure what the problem is, but I've added a workaround and hope it helps to display the
/debug
page https://github.com/mailcow/mailcow-dockerized/pull/6160/files#diff-1ce35b9f8d77569adc5c31790cf2f8dd8bc9646a23a03174d23b2984c954325d.
I just upgraded to 2024-11a
, and my Mailcow is now working with a blank override file (not overriding to mailcow/phpfpm:1.90
)!
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, Sorry for late reply from my side, was on a business trip. Thx everyone for stepping in and of course for the fast fix.
Can also confirm that upgrading and reverting manual downgrade fixed it.
Are we fine to close?
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.
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. https://github.com/mailcow/mailcow-dockerized/issues/5927 is back.
See also comment of another user https://github.com/mailcow/mailcow-dockerized/issues/5927#issuecomment-2463458255
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: