Fehlerbehebung bei fehlgeschlagenem Start

Wenn MobilityManager nicht startet oder niemals bereit wird, liegt die Ursache üblicherweise in einem fehlenden Geheimnis, einer nicht erreichbaren Datenbank oder einem falsch konfigurierten Anbieter. Dieser Artikel ordnet die häufigsten Fehler ihren Lösungen zu.

Beginnen Sie mit den Protokollen und Health-Endpunkten

Lesen Sie die Container- oder Prozessprotokolle nach dem ersten Fehler — Startprüfungen brechen mit einer klaren Meldung sofort ab.

Prüfen Sie die Health-Endpunkte:

curl -i http://localhost:8080/livez
curl -i http://localhost:8080/readyz

Eine bestandene Liveness-Prüfung bei fehlgeschlagener Readiness-Prüfung deutet auf ein Abhängigkeitsproblem hin (üblicherweise die Datenbank) und nicht auf einen Absturz.

Der JWT-Schlüssel fehlt oder ist zu schwach

Symptom: der Start löst einen Fehler aus, dass Jwt:Key ein starkes Geheimnis (≥32 Byte) sein muss und kein eingecheckter Standardwert sein darf.

Lösung: setzen Sie Jwt__Key auf einen frischen Zufallswert von mindestens 32 Byte, der keiner der Beispielschlüssel ist. In Docker Compose ist dies JWT_KEY; in Kubernetes ist es ein Secret-Eintrag.

Der Dokumentverschlüsselungsschlüssel fehlt

Symptom: der Start löst einen Fehler aus, dass DocumentStorage:EnableEncryptionAtRest aktiviert ist, aber DocumentStorage:LocalEncryptionKey nicht konfiguriert ist.

Lösung: stellen Sie einen base64-kodierten 32-Byte-Schlüssel in DocumentStorage__LocalEncryptionKey bereit oder setzen Sie DocumentStorage__EnableEncryptionAtRest=false, falls Sie keine Verschlüsselung benötigen.

Der Datenbankanbieter ist ungültig

Symptom: ein Fehler Unsupported database provider.

Lösung: setzen Sie DatabaseProvider auf genau PostgreSQL oder SqlServer. Beim Wert wird zwischen Groß- und Kleinschreibung unterschieden.

Die Anwendung startet, leitet aber alle nach /setup weiter

Symptom: die Anwendung startet und bleibt funktionsfähig, aber jede Seite leitet zum Einrichtungsassistenten weiter.

Ursache: das System ist noch nicht konfiguriert, oder die Anwendung läuft gegen die In-Memory-Ausweichdatenbank, weil die Verbindungszeichenfolgen oder der Anbieter fehlen.

Lösung: stellen Sie sicher, dass DatabaseProvider und beide Verbindungszeichenfolgen gesetzt und erreichbar sind, und schließen Sie dann das Onboarding ab. Die Anwendung ist erst dann "konfiguriert", wenn sie über einen Benutzer, eine aktive Lizenz und einen Mandanten verfügt.

Hinweis: Migrationen werden übersprungen — nicht als fehlgeschlagen gewertet —, wenn die Datenbank beim Start nicht erreichbar ist. Suchen Sie nach einer Warnung über das Anwenden von Migrationen und die Nutzung des Onboarding-Assistenten und beheben Sie die Konnektivität, nicht die Migration selbst.

Die Datenbank ist nicht erreichbar

Überprüfen Sie Host, Port, Datenbankname, Benutzername und Kennwort in der Verbindungszeichenfolge.
Stellen Sie sicher, dass das Format der Verbindungszeichenfolge zum Anbieter passt (Npgsql für PostgreSQL, Server/Initial Catalog für SQL Server).
Prüfen Sie die Netzwerkrichtlinie und dass der Datenbankcontainer oder -dienst fehlerfrei läuft.
Bestätigen Sie für SQL Server, dass die Einstellungen für Encrypt und Zertifikatsvertrauen mit Ihrem Server kompatibel sind.

Uhrmanipulation bricht den Start ab

Symptom: ein kritischer Protokolleintrag besagt, dass eine Uhrmanipulation erkannt und der Start abgebrochen wurde.

Lösung: die Systemuhr scheint sich relativ zum Lizenzdatensatz rückwärts bewegt zu haben. Stellen Sie die korrekte Systemzeit wieder her und starten Sie neu.