Docker-Gitea-Postgres Part 4: Gitea startet nicht

Teil 4 einer Reihe über Gitea & Postgres im Docker-Container: Gitea startet nicht

Hintergrund dieser Reihe ist das notwendige Update einer Docker-Gitea-Instanz und in diesem Rahmen auch das Major-Version-Upgrade der zugehörigen Postgres-Datenbank.

Docker und Debugging - zwei Welten treffen aufeinander

Vorlauf

Bis zu diesem Schritt lief soweit alles problemlos ab:

  • Backup von Gitea - und auch dessen Restore auf einer anderen Maschine!
  • Backup der alten Postgres-9-Instanz
  • Testweiser Restore des Postgres-Backups auf einem Postgres-9 und Postgres-14

Gitea startet nicht mehr - oder doch?

Ein Versuch auf das Web-Frontend zuzugreifen, brachte verschiedene Fehler des Reverse-Proxys zu Tage. Ein Zugriff auf Gitea war aber nicht möglich.

Erst nach einiger Zeit und einigen docker ps -a fiel mir auf, dass der Gitea-Container sich offensichtlich immer wieder beendete - aber eben nicht sofort, sondern nach ca. einer Minuten. Er wurde dann wieder neu gestartet und nach einer weiteren Minute begann das Spiel von vorne. Von einem Blick in die Logs erhofft man sich ja Aufschluss, was da gerade vor sich geht:

root@docker:~ # docker logs gitea
Server listening on :: port 22.
Server listening on 0.0.0.0 port 22.
cmd/web.go:102:runWeb() [I] Starting Gitea on PID: 15
cmd/web.go:150:runWeb() [I] Global init
routers/init.go:107:GlobalInitInstalled() [I] Git Version: 2.30.3, Wire Protocol Version 2 Enabled
routers/init.go:110:GlobalInitInstalled() [I] AppPath: /usr/local/bin/gitea
routers/init.go:111:GlobalInitInstalled() [I] AppWorkPath: /app/gitea
routers/init.go:112:GlobalInitInstalled() [I] Custom path: /data/gitea
routers/init.go:113:GlobalInitInstalled() [I] Log path: /data/gitea/log
routers/init.go:114:GlobalInitInstalled() [I] Configuration file: /data/gitea/conf/app.ini
routers/init.go:115:GlobalInitInstalled() [I] Run Mode: Prod
Received signal 15; terminating.

Und das wiederholte sich immer und immer wieder. Die ersten beiden Zeilen kommen BTW vom OpenSSH-Server, welcher auch im Gitea-Container läuft.

Nach einiger Zeit (und Frust) bin ich dann wieder mal in den Container gegangen und hab dort nach weiteren Informationen gesucht. Und siehe da, im Gitea-Log-File stehen Informationen, die es - warum ich immer - nicht ins docker logs geschafft haben:

root@bash-5.1# cat /data/gitea/logs/gitea.log
[...]
routers/common/db.go:27:InitDBEngine() [I] ORM engine initialization attempt #8/10...
cmd/web.go:153:runWeb() [I] PING DATABASE postgres
routers/common/db.go:33:InitDBEngine() [E] ORM engine initialization attempt #8/10 failed. Error: pq: password authentication failed for user "gitea"
routers/common/db.go:34:InitDBEngine() [I] Backing off for 3 seconds
[...]

Warum zum Geier schafft es eine solch essentielle Fehlermeldung nicht in die docker logs?! Warum auch immer ich die Idee hat, mir im Container die Logs anzusehen - ohne diese Zeilen hätte ich vermutlich bald aufgegeben und wäre wieder auf die alte Postgres-Version zurückgegangen.

Was sagt denn die Datenbank dazu?

Mit diesem Hinweis schaute ich dann natürlich auch noch in die docker logs der Datenbank. Und siehe da:

root@bash-5.1# docker logs gitea_db
[...]
FATAL:  password authentication failed for user "gitea"
DETAIL:  User "gitea" does not have a valid SCRAM secret.
    Connection matched pg_hba.conf line 100: "host all all all scram-sha-256"
[...]

Der Fehler ist also weniger bei Gitea- als in der Postgres-Datenbank zu suchen - wobei "Fehler" hier natürlich auch nicht korrekt ist. Der alte, aus dem Backup stammende, gitea-Benutzer der Postgres-Datenbank hat einfach kein passend verschlüsseltes Passwort!

Das Setzen eines neue Passworts wird im Teil 5: Postgres MD5- und SCRAM-Passwörter beschrieben.

Fazit

Solche Dinge begegnen mir im Docker-Umfeld immer und immer wieder. Gar keine Logs, Logs nicht an der vermuteten/offiziellen Stelle, zu schnell rotiert Logs - Gründe dafür gibt's viele. Aber genau das sorgt dafür, dass man ohne tiefes Wissen gar keine Chance mehr hat, selbständig aus dieser Situation wieder herauszukommen. Docker wurde eingeführt, damit sich Admins mit gewissen Themen nicht mehr beschäftigen müss(t)en - aber dann eben einfach an einer Wand zerschellen, weil sie keine Ahnung (in diesem Fall rund um die Logs) haben...