Hauptmenü

Probleme mit Update auf v30

Begonnen von Tamme_1337, 27.11.2023 08:02:25

⏪ vorheriges - nächstes ⏩

Tamme_1337

Hallo zusammen,
ich wollte das Update auf die v30 angehen, bekam aber hierbei nur folgenden Fehler im Docker-Log (kix_proxy):
2023/11/27 06:52:46 [error] 30#30: *1 connect() failed (111: Connection refused) while connecting to upstream, client: 172.27.12.105, server: , request: "GET / HTTP/1.1", upstream: "http://172.22.0.5:3000/", host: "172.17.140.14:20001", referrer: "http://172.17.140.14:20001/"
Mir ist augefallen das unsere docker-compose.yml anscheinend nicht mehr up2date ist, das gleiche mit der environment -Datei. Wenn ich nun das Git neu pulle, ändert das leider nichts an dem Fehler.

Der Container "kix_backend" wird kurz nach dem starten beendet. Hat jemand hierzu zufällig eine Idee?

Edit: Die WebUI startet nicht, demnach kann man sich nicht anmelden. Das ist das eigentliche Fehlerbild.

Viele Grüße.

Torsten Thau

Hallo Tamme,

der Fehler deute daraufhin, dass die kix-on-premise nicht aktuell ist. Ich vermute, dass beim "pull" nicht alle relvanten Dateien aktualisiert wurden. Sicher hast du eine Meldung bekommen bei "git pull". Bitte schau was diese sagt.

Wahrscheinlich hast du in "docker-compose.yml" Änderungen vorgenommen - z.B. die Repository-ID eingetragen. Wenn es nur das ist, gehe wie folgt vor:

- Stacks stoppen ("./stop.sh")
- das kix-on-premise  Verzeichnis umbenennen (z.B. "mv ./kix-on-premise ./kop.202311xx")
- kix-on-premise neu beziehen ( "git clone https://github.com/kix-service-software/kix-on-premise.git")
- die Repository-ID wieder eintragen (bzw. zusätzlich noch alle anderen von Dir vorgenommenen Änderungen, falls doch nicht nur die Repo-ID angepasst wurde)
- Stacks aktualiseren ("./update.sh")

CU, T.


Tamme_1337

Hallo Torsten,

danke für die Antwort. 
Genauso habe ich es auch probiert, leider ohne Erfolg. 
Änderungen sind nur in der "docker-compose.yml" vorgenommen worden, dort wird der Port der Datenbank veröffentlicht.
Gibt es eventuell noch andere Abhängigkeiten? Bei uns ist nur kix-start im Einsatz.

Die Meldung erhalte ich im Docker-Log des Proxys. 

Torsten Thau

Dann kann noch eine Ursache sein, dass die aktuellen Images nicht bezogen werden. Das von Dir benannte Fehlerbild bedeutet genau das. Der Aufruf von "update.sh" anstelle "start.sh" bewirkt genau das.

Ein anderer Weg ist, alle Stacks anzuhalten. Alle Images zu entfernen. Dann erfolgt auch bei einem "start.sh" ein Bezug der neuen Images. Bevor Du das machst, kannst Du auch schauen welchen Alters die von Deinem Docker verwendeten Images sind. Stand 2023/11/28 sollte das in etwa so ausschauen:

tto@orion:~/docker/kixstart/kix-on-premise/deploy/linux$ docker image ls | grep public
docker-registry.kixdesk.com/public/backend                                        stable    015a92956ecb   2 weeks ago     697MB
docker-registry.kixdesk.com/public/frontend                                       stable    b5057168d6f6   2 weeks ago     528MB
docker-registry.kixdesk.com/public/proxy                                          stable    b584dc940266   2 weeks ago     46MB
docker-registry.kixdesk.com/public/db                                             stable    6d2fb10d2d49   2 weeks ago     231MB
tto@orion:~/docker/kixstart/kix-on-premise/deploy/linux$

Ist das bei Dir der Fall?

Tamme_1337

Hallo Torsten,

bei mir schaut das eigentlich genauso aus.
docker-registry.kixdesk.com/public/redis      stable      1704fc5b9132   2 weeks ago    33.1MB
docker-registry.kixdesk.com/public/backend    stable      015a92956ecb   2 weeks ago    697MB
docker-registry.kixdesk.com/public/frontend   stable      b5057168d6f6   2 weeks ago    528MB
docker-registry.kixdesk.com/public/proxy      stable      b584dc940266   2 weeks ago    46MB
docker-registry.kixdesk.com/public/db         stable      6d2fb10d2d49   2 weeks ago    231MB

Allerdings verwundert es mich, warum ich einen "redis" Container habe, der bei dir nicht auftaucht. Vermutlich hat es mit kix-start zu tun?

Viele Grüße.

Tamme_1337

Hallo nochmal,

ich konnte das Problem eingrenzen. Es ist tatsächlich Versions unabhängig. Sobald kix mit dem "start.sh" Script gestartet wird passiert nichts mehr, bis der Frontend Container abstürzt. Wenn man kix auf der VM direkt startet und vorher die Netzwerkverbindung trennt, startet Kix ohne Probleme und man kann danach die Netzwerkschnittstelle wieder aktivieren. Durchaus seltsam. Aktuell nutzen wir nun die Version KIX 18 (Build: 4346-2.1831-2)

Vielleicht hat noch jemand eine Idee, wie wir es wieder hinbekommen, dass KIX sich auch mit Netzwerk starten lässt ;)

Viele Grüße

kerstin

Moin,

Ich bin mir nicht sicher, ob das irgendwie eine Zusammenhang hat. Aber bei uns konnte das Frontend auch irgendwann im letzten Jahr Anfang Dezember plötzlich nicht mehr gestartet werden. Wir hatten nichts geändert, weder neue images noch irgendwelche Konfigänderungen. Im Frontend log haben wir folgenden Fehler gefunden
frontend_1  | npm ERR! code EACCES
frontend_1  | npm ERR! syscall mkdir
frontend_1  |
npm ERR! path /.npm
frontend_1  |
npm ERR! errno -13
frontend_1  |
npm ERR!
frontend_1  |
npm ERR! Your cache folder contains root-owned files, due to a bug in
frontend_1  |
npm ERR! previous versions of npm which has since been addressed.
frontend_1  |
npm ERR!
frontend_1  |
npm ERR! To permanently fix this problem, please run:
frontend_1  |
npm ERR!  sudo chown -R 110010100:0 "/.npm"

Daraufhin haben wir im docker-compose.yml in der Frontend Config das "user: "110010100" auskommentiert und seitdem läuft es wieder. Ist so sicher nicht gedacht, aber wir hatten seitdem leider noch keine Gelegenheit dem Ganzen auf den Grund zu gehen. Vielleicht hilft das ja irgendwie weiter.

Schöne Grüße,
Kerstin

Torsten Thau

Hallo Kerstin,

Dein Fehlerbild hat Benedikt hier behandelt: https://forum.kixdesk.com/index.php?topic=12096.0

Ich hoffe das hilft Dir weiter.

kerstin

Hallo Torsten,

Super - Vielen Dank. Der Update steht tatsächlich als nächstes auf meiner ToDo Liste und ich hatte die Hoffnung, dass er das Problem gleich mitlöst. 
Aber so haben wir für die Übergangszeit einen eleganteren Workaround.

Vielen Dank und schöne Grüße,
Kerstin