[gelöst] configDB.pm verhindert start von FHEM

[wk]

Ich habe seit dem Frühjahr das Problem, dass nach jedem Update der configDB.pm sich FHEM nicht mehr starten lässt.

Ich bekomme dann auf den Befehl:

Code Auswählen Erweitern

systemctl status fhem.service
× fhem.service - FHEM Home Automation
     Loaded: loaded (/etc/systemd/system/fhem.service; enabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Thu 2022-12-08 11:28:41 CET; 10s ago
    Process: 174885 ExecStart=/usr/bin/perl fhem.pl configDB (code=exited, status=255/EXCEPTION)
        CPU: 123ms

Dec 08 11:28:41 uhs20 systemd[1]: fhem.service: Scheduled restart job, restart counter is at 5.
Dec 08 11:28:41 uhs20 systemd[1]: Stopped FHEM Home Automation.
Dec 08 11:28:41 uhs20 systemd[1]: fhem.service: Start request repeated too quickly.
Dec 08 11:28:41 uhs20 systemd[1]: fhem.service: Failed with result 'exit-code'.
Dec 08 11:28:41 uhs20 systemd[1]: Failed to start FHEM Home Automation.

Bisher habe ich immer wieder aus der Backup-Sicherung die Version 25860 vom 20.3.2022 eingespielt und es war gut. Gehofft habe ich immer, dass es nur ein vorübergehender Fehler wäre, der sich bei der nächsten Version erledigt.
Aber nachdem auch heute beim Einspielen der Version 26802 vom 6.12.2022 dieser Fehler bei mir wieder auftauchte, will ich es klären.

Mein FHEM läuft auf UBUNTU 22.04 mit PostgreSQL.
Welche Infos sind noch notwendig, damit ich zur Klärung beitragen kann.

[Wernieman]

Die üblichen Verdächtigen:
- Logfile von FHEM
- Eventuell FHEM im Debg-Modus starten -> Ausgabe posten

Aber grundsätzlich:
systemctl status fhem.service
Gibt nur die Sicht aus SystemD-Seite an. Hier z.B. das "fhem.service: Start request repeated too quickly.". Wenn jetzt fhem etwas länger zum starten braucht, z.B. wegen irgendeiner Innitialisierung (Stichwort USB-Check), kann es auch dazu kommen. Ist dann aber kein Fehler von FHEM sondern von SystemD (bzw. der Config des Service).

Deshalb fürs Debuggen besser gucken, ob der FHEM-Prozess läuft: "ps aux | grep fhem"

[wk]

Mit der alten Version läuft fhem:

Code Auswählen Erweitern

fhem      175743  3.2  1.7 156584 139936 ?       S    11:56   0:39 /usr/bin/perl fhem.pl configDB


mit der neuen Version läuft es nicht.

Code Auswählen Erweitern

journalctl -xeu fhem.service
bringt

Code Auswählen Erweitern

A start job for unit fhem.service has begun execution.
░░
░░ The job identifier is 37474.
Dec 08 12:18:28 uhs20 perl[176428]: 2022.12.08 12:18:28 1: PERL WARNING: NOTICE:  relation "fhemversions" already exists, skipping
Dec 08 12:18:28 uhs20 perl[176428]: 2022.12.08 12:18:28 1: PERL WARNING: NOTICE:  relation "fhemconfig" already exists, skipping
Dec 08 12:18:28 uhs20 perl[176428]: 2022.12.08 12:18:28 1: PERL WARNING: NOTICE:  relation "fhemstate" already exists, skipping
Dec 08 12:18:28 uhs20 perl[176428]: 2022.12.08 12:18:28 1: PERL WARNING: NOTICE:  relation "fhemb64filesave" already exists, skipping
Dec 08 12:18:28 uhs20 perl[176428]: 2022.12.08 12:18:28 1: PERL WARNING: DBD::Pg::db do failed: ERROR:  column "versiontag" does not exist
Dec 08 12:18:28 uhs20 perl[176428]: LINE 1: SELECT versiontag from fhemversions where version = 0
Dec 08 12:18:28 uhs20 perl[176428]:                ^
Dec 08 12:18:28 uhs20 perl[176428]: HINT:  Perhaps you meant to reference the column "fhemversions.version". at configDB.pm line 372.
Dec 08 12:18:28 uhs20 perl[176428]: 2022.12.08 12:18:28 1: PERL WARNING: DBD::Pg::db do failed: ERROR:  current transaction is aborted, commands ignored until end of transaction block at configDB.pm line 373.
Dec 08 12:18:28 uhs20 perl[176428]: DBD::Pg::db do failed: ERROR:  current transaction is aborted, commands ignored until end of transaction block at configDB.pm line 373.
Dec 08 12:18:28 uhs20 perl[176428]: 2022.12.08 12:18:28 1: PERL WARNING: Issuing rollback() due to DESTROY without explicit disconnect() of DBD::Pg::db handle dbname=fhem;host=localhost at configDB.pm line 373.
Dec 08 12:18:28 uhs20 systemd[1]: fhem.service: Control process exited, code=exited, status=255/EXCEPTION
░░ Subject: Unit process exited
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ An ExecStart= process belonging to unit fhem.service has exited.
░░
░░ The process' exit code is 'exited' and its exit status is 255.
Dec 08 12:18:28 uhs20 systemd[1]: fhem.service: Failed with result 'exit-code'.
░░ Subject: Unit failed
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ The unit fhem.service has entered the 'failed' state with result 'exit-code'.
Dec 08 12:18:28 uhs20 systemd[1]: Failed to start FHEM Home Automation.
░░ Subject: A start job for unit fhem.service has failed
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ A start job for unit fhem.service has finished with a failure.


[frank]

was sagt fhem.log?

[Wernieman]

Code Auswählen Erweitern

PERL WARNING: DBD::Pg::db do failed: ERROR:  column "versiontag" does not exist

Hatten wir schon mal im Forum ... eine kurze Suche: https://forum.fhem.de/index.php/topic,128952.msg1233085.html#msg1233085

Und wie mein Vorredner schrieb (und ich davor): Was sagen die anderen Logs?

Bitte um Input für Output

[wk]

Das fhem.log sagt zu dem Zeitpunkt gar nichts, da fhem ja nicht läuft.
Das syslog zeigt die oben geposteten Zeilen.

Den anderen Thread von CoolTux hatte ich nicht gefunden, aber wie gebe ich den Befehl ein?
Wenn ich ihn oben in der Befehlszeile eingebe, bekomme ich:

Code Auswählen Erweitern

Unknown command ALTER, try help.

[Wernieman]

Das ist ein Datenbankbefehlt, also in der Datenbank.

Du hast nur eine PostgressDB .. wie da der Befehl lautet ...

Und ja, auch wen fhem nicht läuft, kann es ins Logfile schreiben ....

[wk]

Also mit eurer Hilfe habe ich es gelöst.
Dass der Befehl direkt in der Datenbank einzugeben war, hatte ich nicht gecheckt.

Was ich noch nicht verstehe, dass andere user anscheinend keine Probleme hatten, denn Coolux und ich sind doch wohl nicht die Einzigen, die mit PostgreSQL arbeiten.

Vielen Dank für eure Geduld
Walter

[Wernieman]

mySQL (MariaDB) sind bedeutend verbreiteter als ProsgressSQL ... also mich wundert es nicht.

[betateilchen]

Was ich noch nicht verstehe, dass andere user anscheinend keine Probleme hatten, denn Coolux und ich sind doch wohl nicht die Einzigen, die mit PostgreSQL arbeiten.

Vielleicht sind andere user, wenn sie schon eine in diesem Szenario eher unübliche Datenbank verwenden, einfach auch in der Lage, eine eigentlich eindeutige und klar beschriebene Fehlermeldung im Logfile zu verstehen und daraus die richtigen Schlüsse zu ziehen?

Code Auswählen Erweitern


Dec 08 12:18:28 uhs20 perl[176428]: 2022.12.08 12:18:28 1: PERL WARNING: DBD::Pg::db do failed: ERROR:  column "versiontag" does not exist
Dec 08 12:18:28 uhs20 perl[176428]: LINE 1: SELECT versiontag from fhemversions where version = 0


Egal, Hauptsache, Du hast Dein Problem gelöst.

Generell ist es so, dass WENN solche Probleme mit configDB auftreten, das meistens im Umfeld von PostgreSQL auftreten, weil sich dieses Datenbanksystem in seinem Verhalten von anderen Datenbanksystemen häufig unterscheidet und man als Entwickler auch nicht immer an alles denken kann (insbesondere, wenn man das System selbst nicht einsetzt).


--