502 Bad Gateway nach Update auf 21.1-20220207

Andreas_Stein 2022-02-08 09:17:47 UTC #1

Hallo zusammen,
seit heute Morgen (Update heute Nacht auf 20220207) habe ich mit einer Installation das Problem mit dem “502 Bad Gateway”. Auf dem Host läuft Ubuntu 18.04LTS und Maria-DB, alle Updates installiert.
der Aufruf von docker ps -a liefert:

comic@christel:~$ sudo docker ps -a
CONTAINER ID   IMAGE                                     COMMAND                  CREATED             STATUS                         PORTS                      NAMES
509f6098e5a3   nginx:stable-alpine                       "/docker-entrypoint.…"   About an hour ago   Up 15 hours                    127.0.0.1:8080->80/tcp     egroupware-nginx
51844b33c8f3   containrrr/watchtower                     "/watchtower --sched…"   About an hour ago   Up 15 hours                    8080/tcp                   egroupware-watchtower
74e70dd97de2   egroupware/egroupware:21.1                "/entrypoint.sh php-…"   About an hour ago   Up 20 seconds                  9000/tcp                   egroupware
b958b5219dcf   busybox                                   "/bin/true"              About an hour ago   Exited (0) About an hour ago                              egroupware-db
c30ab67a3f8f   quay.io/egroupware/collabora-key:stable   "/start-collabora-on…"   About an hour ago   Up 15 hours                    127.0.0.1:9980->9980/tcp   collabora-key
534ec6e2c9af   rocketchat/rocket.chat:latest             "docker-entrypoint.s…"   5 hours ago         Up 15 hours                    127.0.0.1:3000->3000/tcp   rocketchat
d070cd1ea241   mongo:4.0                                 "docker-entrypoint.s…"   8 weeks ago         Up 15 hours                    27017/tcp                  rocketchat-mongo
86369265f8e7   phpswoole/swoole:4.6-php7.4-alpine        "docker-php-entrypoi…"   7 months ago        Up 15 hours                                               egroupware-push
eab6c3b612a1   c2a1be6e3df8                              "docker-entrypoint.s…"   2 years ago         Exited (0) 2 years ago                                    eab6c3b612a1_eab6c3b612a1_eab6c3b612a1_eab6c3b612a1_eab6c3b612a1_eab6c3b612a1_egroupwarerocketchat_mongo-init-replica_1
comic@christel:~$

Im vergleich zu einer funktionierenden Installation (meiner eigenen) erkenne ich leider nix. Woran kann das jetzt noch liegen bzw. wo kann ich noch nachsehen?

vielen Dank und viele Grüße
Andreas Stein

StefanU 2022-02-08 13:39:46 UTC #2

Hallo Andreas.

Wir hatten hier im Forum das ein oder andere mal etwas zum 502…

Laufen die Container durch oder werden die/der immer wieder neu gestartet?
Läuft die Datenbank/ist erreichbar?

Stefan

Andreas_Stein 2022-02-08 14:00:17 UTC #3

Hallo Stefan,
die Container laufen durch, und die db habe ich auch schon neu gestartet - ohne Fehler im syslog. Bei der Durchsicht des nginx-logs (docker logs -f egroupware-nginx) sehe ich aber folgenden Eintrag, den ich wiederum nicht nicht zu oder einordnen kann:
2022/02/08 11:50:57 [error] 23#23: *158 connect() failed (111: Connection refused) while connecting to upstream, client: 172.20.0.1, server: _, request: “GET /egroupwre/index.php?cd=yes HTTP/1.1”, upstream: “fastcgi://172.20.0.2:9000”, host: “xxxxx.selfip.org”

was bedeutet das?

viele Grüße
Andreas

Andreas_Stein 2022-02-08 18:18:43 UTC #4

Hallo Stefan,
dein Bauchgefühl war wohl richtig - der egroupware container startet permanent neu (docker-compose logs -f egroupware):
egroupware | Installation failed --> exiting!
egroupware |
egroupware | Retrying EGroupware installation in 3 seconds …
egroupware | /usr/bin/php7.4 -d memory_limit=-1 /usr/share/egroupware/setup/setup-cli.php --setup-cmd-database sub_command=create_db ‘domain=default’ ‘db_type=mysqli’ ‘db_host=localhost’ ‘db_port=3306’ ‘db_name=egroupware’ ‘db_user=egroupware’ ‘db_pass=6#XkdO:Tbs5D}Mdc’ ‘db_root=root’ ‘db_root_pw=eed9a22bb97a6f93de2800f253283e4f’ 'db_grant_host=%'
egroupware | Can not connect to mysqli database mysql on host localhost:3306 using user root! (ADOdb::Connect(localhost:3306, root, $Password, mysql) failed.)
egroupware | /usr/share/egroupware/setup/inc/class.setup_cmd_database.inc.php (158)
egroupware |
egroupware | Installation failed --> exiting!
egroupware |
egroupware | Retrying EGroupware installation in 3 seconds …
egroupware | /usr/bin/php7.4 -d memory_limit=-1 /usr/share/egroupware/setup/setup-cli.php --setup-cmd-database sub_command=create_db ‘domain=default’ ‘db_type=mysqli’ ‘db_host=localhost’ ‘db_port=3306’ ‘db_name=egroupware’ ‘db_user=egroupware’ ‘db_pass=xBB4gxAK-N3-x484’ ‘db_root=root’ ‘db_root_pw=eed9a22bb97a6f93de2800f253283e4f’ 'db_grant_host=%'
egroupware | Can not connect to mysqli database mysql on host localhost:3306 using user root! (ADOdb::Connect(localhost:3306, root, $Password, mysql) failed.)
egroupware | /usr/share/egroupware/setup/inc/class.setup_cmd_database.inc.php (158)
egroupware |
egroupware | Installation failed --> exiting!
egroupware |
egroupware | Retrying EGroupware installation in 3 seconds …

die Datenbank läuft allerdings einwandfrei - mit dem ursprünglichen PW. Gibt es irgendetwas, was sich mit dem Update geändert hat?

viele Grüße
Andreas

StefanU 2022-02-08 19:04:28 UTC #5

Hallo Andreas.

Eigentlich nicht. Es wurde ja nur der Container mit den EGroupware-Sourcen getauscht.

Du kannst ja problemlos den letzten Container wieder “installieren”:

Es würde mich aber wundern wenn das besser wird. Versuch es halt…

Und bitte sichere deine Daten besser mal weg:

Sind alle (EGroupware-)Pakete auf dem System installiert?

Stefan

Andreas_Stein 2022-02-09 05:39:39 UTC #6

Hallo Stefan,

hab ich - nach wie vor gleiche Fehlermeldung wie oben (egroupware | Can not connect to mysqli database mysql on host localhost:3306 using user root! (ADOdb::Connect(localhost:3306, root, $Password, mysql) failed.))
Mittlerweile habe ich via VPN einen webmin-Zugang zu der VM: der MySQL-Server arbeitet scheinbar fehlerfrei, die eGroupware-DB ist vollständig lesbar (hab nur 2 3 Tabellen mal angesehen).
Auch wenn ich in der docker-compose.override.yml unter
egroupware:
environment:
- EGW_DB_HOST=localhost
statt localhost die IP-Adresse angebe, bekomme ich immernoch die gleiche Fehlermeldung, d.h. mit “localhost” statt der angegebenen IP-Adresse.

kann ich nicht genau sagen, aber ich glaube schon. der Aufruf …egroupware//setup funktioniert eben auch nicht.

wird die docker-compose.override.yml evtl. garnicht ausgeführt?
wie könnte ich das kontrollieren?
viele Grüße
Andreas

RalfBecker 2022-02-09 07:05:10 UTC #7

Dh. EGroupware kann Deine auf dem Host laufende Datenbank nicht erreichen. Da das leider immer wieder mal vorkommt, verwenden wir bei neuen Installationen inzwischen immer eine MariaDB in einem Container.

Wenn die Datenbank selbst problemlos läuft, sprich Du sie mit dem mysql Kommando auf dem Host erreichen kannst, würde ich zuerst mal einen Restart der EGroupware Container machen, wenn das nichts hilft einen Recreate.
Restart: cd /etc/egroupware-docker; docker-compose restart
Recreate: cd /etc/egroupware-docker; docker-compose up -d --force-recreate

Ralf

Andreas_Stein 2022-02-09 07:20:27 UTC #8

Hallo Stefan,
der Fehler ist gefunden.
Die header.inc.php wurde am 8.2.2022 um 05:08Uhr bearbeitet und hatte 0 Byte.
Datei aus Sicherung wiederhergestellt und neugestartet - alles wieder ok.
kleine Anmerkung:
um einen “älteren” Stand einzuspielen, habe ich die image - Variable auf “latest” - was meiner Meinung nach ein Wiederspruch ist. Entsprechend kam eGroupware dann auch hoch mit dem gelben Pfeil/Hinweis, es liegt ein Update vor. Ich habe dann die Image-Variable wieder auf 21.1 gesetzt, manueUpdate ausgeführt, und jetzt ist alles wieder gut.
Irgendwie passen die Begrifflichkeiten hier nicht
Warum die header.inc.php allerdings beim Update auf null gesetzt wurde, ist mir schleierhaft. Warum passiert sowas bzw. warum wird diese Datei beim Update überhaupt angefaßt?
viele Grüße
Andreas

RalfBecker 2022-02-09 07:57:33 UTC #9

Das letzte Maintenance Release 21.1.20220207 war noch nicht als latest getaged. habe ich jetzt gemacht. Und auch wieder eingeschaltet, das das automatisch passiert.

Generell empfehlen wir den (rolling) Tag des Major Releases z.B. “21.1” zu verwenden und nicht “latest”. Dann hat man die Kontrolle wann man das Update auf das nächste Major Release macht. Wir erhöhen das Tag in der Regel automatisch mit einem Linux Paket in der docker-compose.override.yml.

Der header.inc.php wird beim Update “angefasst” um dort für das Update ein Passwort zu setzen und dieses nach dem Update auch wieder auf das des Users zurück zu stellen. Das sollte auch passieren wenn es einen Fehler beim Update gibt.

Mir sind bisher ein paar Fälle mit eine 0 Byte header.inc.php unter gekommen, aber bisher immer im Zusammenhang mit einem vollen Dateisystem.

Generell kann es natürlich nicht schaden ein Backup der header.inc.php zu haben.

Ralf

Andreas_Stein 2022-02-09 08:06:38 UTC #10

Danke für die Info. Das mit dem vollen Dateisystem kommt unter Umständen auch hier hin - von 200GB sind/waren noch 11GB frei. Sollte eigentlich reichen, aber zum Zeitpunkt des Updates kann das anders gewesen sein.

viele Grüße

Andreas

StefanU 2022-02-09 08:11:39 UTC #11

Habe das nun in den Artikeln korrigiert. Hatte sich halt mit der Zeit geändert…

latest spielt das als latest getaggte image ein. Nicht later…
Schau mal:
https://hub.docker.com/r/egroupware/egroupware/tags

Heißt in dem Fall dass du (jetzt) die vorige Version haben möchtest:
21.1.20211130 => /etc/egroupware-docker/docker-compose.override.yaml

Aber nicht durch das Update. Das Image hat nur ein paar hundert MB (ausgepackt) und bei Automatik wird das alte Image gelöscht.

Stefan

StefanU 2022-02-09 08:23:03 UTC #12

Ich habe die Doku:

angepasst. Punkt 2:
/var/lib/egroupware/default => /var/lib/egroupware

Nimmt dann somit alle Mandanten und auch

egroupware-docker-install.log
header.inc.php

mit.

Stefan