keine Verbindung zur externen DB nach Neuinstallation

[volmin]

Ich habe ein Problem KIX18 rekonstruierbar zu installieren.
Meine Umgebung besteht aus zwei virtuelle Instanzen von debian 11.6.
Eine Instanz ist debian 11.6 mit einem Postgresql Server 13.
Es wurde laut GIT Repository Dokumentation die Datenbank "kix" (UTF8) und der Benutzer "kix" mit der/den Role/Rechten eingerichtet.
Die andere Instanz ist ein aktuelles debian 11.6.
Auf dieser Instanz wurde über "git clone?" KIX18 geclont.
Vor dem Start wurde im "kix-on-premise/deployment/linux" Verzeichnis die Datei "enviroment" verändert, "KIXDB_HOST=IP-Adresse-Postgresql".
Die Postgresql wird gestartet.
Jetzt starte man KIX über das mitgelieferte Script ./start.sh.
Die Datenbank wird auf der externen Instanz anlegt und funktioniert auch.


Auszug aus dem Log:
================================================================================
#[36mbackend_1   |#[0m + find /opt/kix/config/ -print0 -type l '!' -exec test -f '{}' ';' -exec rm -fv '{}' ';'
#[36mbackend_1   |#[0m + ln -s /opt/kix/conf.d/example.conf /opt/kix/config/
#[36mbackend_1   |#[0m + '[' '!' -f /mnt/shared/backend_api_token ']'
#[36mbackend_1   |#[0m ++ /opt/kix/bin/kix.Console.pl Admin::Token::Create --user admin --user-type Agent --valid-until '9999-12-31 23:59:59' --ignore-max-idle-time 1 --description 'frontend API token'
#[36mbackend_1   |#[0m ++ head -n 1
#[36mbackend_1   |#[0m ++ tail -n 2
#[36mbackend_1   |#[0m + BACKEND_API_TOKEN=eyJhbGciOiJIUzI1NiJ9.eyJEZXNjcmlwdGlvbiI6ImZyb250ZW5kIEFQSSB0b2tlbiIsIlVzZXJUeXBlIjoiQWdlbnQiLCJBbGxvd2VkT3BlcmF0aW9ucyI6W10sIkNyZWF0ZVRpbWVVb
================================================================================


Um die Beseitung einer Störung zu simulieren, wurde
1. Der Server der Datenbank Instanz neu aufgesetzt.
2. Das Backup der Postgresql Datenbank zurückgespielt.
3. Ein debian Server neuaufgesetzt, Docker installiert, Git Client.
4. Per Client "kix18" geclont".
5. In Datei "enviroment" wurde die Variable KIXDB_HOST wieder angepasst.
6. Nun wird das Script "./start.sh" ausgeführt.


Laut Log wird "versucht" das backend zu starten.
Siehe Bild wird ein Rekursionfehler erzeugt. Diese Fehler in der Config "frißt" den Speicher des laufenden Betriebssystems, aber das Kix-System startet nicht mehr funktionsf�hig.
Auszug aus dem Log mit Rekursion-Fehler(Stacktrace)
================================================================================
#[36mbackend_1   |#[0m + find /opt/kix/config/ -print0 -type l '!' -exec test -f '{}' ';' -exec rm -fv '{}' ';'
#[36mbackend_1   |#[0m + ln -s /opt/kix/conf.d/example.conf /opt/kix/config/
#[36mbackend_1   |#[0m + '[' '!' -f /mnt/shared/backend_api_token ']'
#[36mbackend_1   |#[0m ++ head -n 1
#[36mbackend_1   |#[0m ++ tail -n 2
#[36mbackend_1   |#[0m ++ /opt/kix/bin/kix.Console.pl Admin::Token::Create --user admin --user-type Agent --valid-until '9999-12-31 23:59:59' --ignore-max-idle-time 1 --description 'frontend API token'
#[36mbackend_1   |#[0m Deep recursion on subroutine "Kernel::System::ObjectManager::Get" at /opt/kix/Kernel/System/Cache.pm line 66.
#[36mbackend_1   |#[0m Deep recursion on subroutine "Kernel::System::ObjectManager::_ObjectBuild" at /opt/kix/Kernel/System/ObjectManager.pm line 267.
#[36mbackend_1   |#[0m Deep recursion on subroutine "Kernel::System::Cache::new" at /opt/kix/Kernel/System/ObjectManager.pm line 338.
#[36mbackend_1   |#[0m Deep recursion on subroutine "Kernel::System::Cache::Redis::new" at /opt/kix/Kernel/System/ObjectManager.pm line 338.
#[36mbackend_1   |#[0m Deep recursion on subroutine "Kernel::Config::Get" at /opt/kix/Kernel/System/Cache/Redis.pm line 42.
#[36mbackend_1   |#[0m Deep recursion on subroutine "Kernel::Config::LoadSysConfig" at /opt/kix/Kernel/Config.pm line 237.
#[36mbackend_1   |#[0m Deep recursion on subroutine "Kernel::System::SysConfig::ValueGetAll" at /opt/kix/Kernel/Config.pm line 146.
================================================================================
Die "Löschung" und der Wiederaufbau aller beteiligten Instanzen/Container muss möglich sein,
nur alleine das Datenbank-Backup muss ausreichend sein zur Wiederherstellung einer Produktionsinstanz.