Aug 2020
1 / 18
Aug 2020
Sep 2020
denniswstr
Aug '20

Hallo zusammen,

ich habe gestern abend auf einem Intel Nuc einen Ubuntu 20.01 Server installiert und dann die neue Version von Egroupware via Docker installiert. Hat auch alles wunderbar funktioniert. Konnte mich einloggen, änderungen vornehmen, etc.

Dann habe ich gestern abend als ich soweit fertig war den Intel Nuc ausgestellt. Vorhin als ich den dann wieder hochgefahren habe und auf Egroupware zugreifen wollte, Kam immer nur die Fehlereldung “502 Bad Gateway”

Kann da jemand helfen?

StefanUEGroupware GmbH
Aug '20

Hallo Dennis.

Grundsätzlich muss man beim Start eines solchen umfangreichen (Docker) Systems ein wenig mehr Geduld aufbringen bis alles oben ist. Anders als bei einem Webserver mit einer einfachen Webanwendung…
Ich denke du hast lange gebug gewartet(?)…

Dann solltest du als erstes einmal schauen, wie der Startus deiner Docker-Container ist:
docker ps -a

Das zeig dann mal bitte hier.

Stefan

denniswstr
Aug '20

Hallo Stefan,

danke für die schnelle Antwort.
Gewartet habe ich teilweise sogar eine Stunde.

Hier einmal docker ps-a

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
db0852876924 nginx:stable-alpine “/docker-entrypoint.…” 3 hours ago Up 2 minutes 127.0.0.1:8080->80/tcp egroupware-nginx
993f6c3bce2c phpswoole/swoole:latest “/entrypoint.sh” 3 hours ago Up 2 minutes egroupware-push
95c6dd1b8252 containrrr/watchtower:latest “/watchtower --sched…” 3 hours ago Up 2 minutes 8080/tcp egroupware-watchtower
5bad4c10e3b5 egroupware/egroupware:20.1 “/entrypoint.sh php-…” 3 hours ago Up 36 seconds 9000/tcp egroupware
b39774bbd87d mariadb:10.4 “docker-entrypoint.s…” 3 hours ago Exited (0) 3 hours ago egroupware-db
d48115f67bca quay.io/egroupware/collabora-key:stable “/bin/sh -c 'bash st…” 3 hours ago Up 2 minutes 127.0.0.1:9980->9980/tcp collabora-key

StefanUEGroupware GmbH
Aug '20

Ich meinte Minuten, nicht Stunden :slight_smile:

Ist da vor 3 Stunden noch einmal ein Update gelaufen? Die Container sind vor 3 Stunden erstellt worden …

Beobachte das mal. Wird ein Container ständig neu gestartet oder ist einer down?

Gibt das Log etwas her?:

cd /etc/egroupware-docker
docker-compose logs -f egroupware

Stefan

denniswstr
Aug '20

Ich habe vor 3 Stunden noch einmal alles neu aufgesetzt, da ich dachte dass es vielleicht an der Installation liegt und ich etwas übersehen habe.

Ich habe die Datenbank nun einmal gestartet, die war nicht mit hochgefahren. Nun funktioniert alles.

Kann ich einstellen dass die Datenbank automatisch immer mit startet?

StefanUEGroupware GmbH
Aug '20

Na ja, das sollte sie schon. Natürlich.

Sagt das Docker-Log etwas dazu?

Ich installiere mal bei mir…

Stefan

denniswstr
Aug '20

Ja, folgendes:
egroupware | Installation failed --> exiting!
egroupware |
egroupware | Retrying EGroupware installation in 3 seconds …
egroupware | /usr/bin/php7.3 -d memory_limit=-1 /usr/share/egroupware/setup/setup-cli.php --update 'all,admin,>fk?U_]|U]A:!>Ip’
egroupware | EGroupware API version 20.1 found.
egroupware | EGroupware configuration file (header.inc.php) version 1.29 exists and is up to date
egroupware | Your database is not working! mysqli://egroupware:2W)o48vpt2R1pRxM@db/egroupware:
egroupware |
egroupware | Installation failed --> exiting!

als ich dann die Datenbank selber gestartet habe, kam folgendes:
egroupware | Retrying EGroupware installation in 3 seconds …
egroupware |
egroupware | EGroupware successful updated
egroupware | * Starting periodic command scheduler cron
egroupware | …done.

Seitdem funktioniert es. Nur wenn ich jetzt das System neustarte, dann startet die Datenbank wieder nicht mit

TobiasT
Aug '20

Vielleicht habe ich das gleiche Problem, der egroupware-db container wird zwar gestartet aber gleich wieder beendet:

root@docker-host:/etc/egroupware-docker# docker-compose up
Creating egroupware-watchtower ... done
Creating egroupware-db         ... done
Creating egroupware            ... done
Creating egroupware-push       ... done
Creating egroupware-nginx      ... done
Attaching to egroupware-db, egroupware-watchtower, egroupware, egroupware-push, egroupware-nginx
egroupware-watchtower | time="2020-08-17T07:28:46Z" level=info msg="Starting Watchtower and scheduling first run: 2020-08-18 04:00:00 +0000 UTC"
egroupware-db exited with code 0
egroupware    | Fix APC(u) configuration, set apc.shm_size=128M in /etc/php/7.3/cli/conf.d/20-apcu.ini
egroupware    | /usr/bin/php7.3 -d memory_limit=-1 /usr/share/egroupware/setup/setup-cli.php --update 'all,admin,A.....X#'
egroupware    | EGroupware API version 20.1 found.
egroupware    | EGroupware configuration file (header.inc.php) version 1.29 exists and is up to date
egroupware    | Your database is not working! mysqli://egroupware:i.....u@db/egroupware:
egroupware    |
egroupware    | Installation failed --> exiting!
egroupware    |
egroupware    | Retrying EGroupware installation in 3 seconds ...

Das egroupware-docker_db volume sieht ok aus.
Wie bekomme ich das wieder zum laufen?

RalfBeckerEGroupware GmbH
Aug '20

Die Frage bei beiden ist: war das ein Update einer 19.1 auf 20.1 oder eine Neuinstallation von 20.1?

Warum ich frage ist, dass NUR eine Neuinstallation von 20.1 den egroupware-db Container tatsächlich verwendet!

Das Update von 19.1 trägt unter /etc/egroupware-docker/docker-compose.override.yml einen kleinen busybox Container ein der sich sofort wieder beendet, da dort die Datenbank ja auf dem Host selbst läuft.

Wenn es ein Update ist und die Datenbank auf dem Host nicht automatisch startet, dan muss diese per systemctl enable <Name-des-Pakets> explicit enabled werden, damit sie bei einem Neustart auch automatisch startet! Dann entweder einen weiteren Reboot machen, oder manuell starten mit systemctl start <Name-des-Paketes> ( hängt leider von der Linux Distribution und der Version ab: mysql, mysqld, mariadb-server, …).

Ralf

TobiasT
Aug '20
2

Es war ein Update von 19.1, aber da war der egroupware-db service konfiguriert (direkt in der docker-compose.yml) und es lief ohne Probleme.

Bin wohl beim durchschauen der docker-compose.override.yml nie bis zum Ende gegangen. Ich habe den busybox container dort jetzt auskommentiert. Die Installation läuft wieder.

Danke für den Hinweis!

denniswstr
Aug '20

Bei mir war es eine Neuinstallation von 20.1.
Habe bisher auch noch keine Lösung gefunden.

StefanUEGroupware GmbH
Aug '20

Ich habe nun noch einmal Installationen mit Ubuntu Server 20.04 UND Ubuntu Server 18.04 getestet. Bei beiden stirbt die MariaDB weg.
Nach reboot:

image
image.png1910x157 98.6 KB

Nun noch mit Debian 10 getestet: Leider auch das Problem…

@RalfBecker: Kannst du bitte mal schauen ob du das reproduzieren kannst?

Stefan

RalfBeckerEGroupware GmbH
Aug '20

Wenn ich das mal zusammenfassen darf: Ihr sagt bei einer 20.1 Neuinstallation, bei der die Datenbank im Container läuft, wird in der docker-compose.override.yml der busybox container eingetragen?

Das sollte nur für die 19.1 Updates passieren, um nicht zwei Datenbanken zu starten.

Ralf

RalfBeckerEGroupware GmbH
Aug '20

Es fehlen aber auch Angaben um Dir zu helfen?

Steht bei Dir unter /etc/egroupware-docker/docker-compose.override.yml ein NICHT auskommentierter Abschnitt db mit busybox, der den eigentlichen MariaDB (egroupware-db) Container am Start hindert, oder geht der Start aus anderen Gründen schief?

Sprich im letzteren Fall hift es einfach den Datenbank Container manuelle zu starten:

cd /etc/egrouwpare-docker
docker-compose up -d

Ralf

RalfBeckerEGroupware GmbH
Aug '20

Habe das Problem gefunden, in unserem /etc/egroupware-docker/docker-compose.yml fehlt im Abschnitt db restart: always :frowning:

Wenn ich das eintrage kann ich die Maschine rebooten und die Datenbank kommt auch automatisch wieder hoch :slight_smile:

Ich würde allerdings vorschlagen das jetzt nicht manuell bei Euch einzutragen, sonst gibt es mit dem nächsten Maintenance Release wieder einen Konflikt der manuell aufgelöst werden muss.

Der Workaround nach einem Reboot (bis zum nächsten Maintenance Release, vermutlich heute noch) ist ja relativ simple nach dem Reboot folgendes ausführen:

cd /etc/egroupware-docker
docker-compose up -d

Ralf

13 days later