FHEM stürzt regelmäßig bei gplot Aufruf ab

[persching]

Nachdem ich ja schon im anderen Thema geschrieben habe https://forum.fhem.de/index.php?topic=81533 und dort betateilchen meinte, das wäre nicht das gleiche Problem eröffne ich nun mein eigenes Thema.

@betateilchen: ich weiß nicht woher der sleep prozess kommt. Aber er ist auf alle Fälle immer da. Auf dem Rechner läuft außer FHEM noch pihole, vielleicht davon irgendwas? Ich habe das Attribut plotfork=0 gesetzt, aber auch das ändert nichts.

[Wernieman]

Dannmach doch mal ein "pstree", dort siehst Du dann, welcher Prozess den sleep aufruft

[persching]

Das sleep kommt von rpimonitor-help. Allerdings habe ich rpimonitor schon gelöscht

Code Auswählen Erweitern

apt-get purge rpimonitor. Das Paket auch nicht mehr installiert, aber dieser Prozess ist immer noch drin.

Code Auswählen Erweitern


root@bananapim2plus:~# pstree
systemd─┬─2*[agetty]
        ├─cron
        ├─dbus-daemon
        ├─dhcpcd
        ├─dnsmasq
        ├─irexec
        ├─lighttpd───php-cgi───4*[php-cgi]
        ├─lircd
        ├─lircd-uinput
        ├─lircmd
        ├─master─┬─pickup
        │        └─qmgr
        ├─perl
        ├─pihole-FTL─┬─{loganalyzer}
        │            └─{socket listener}
        ├─rpimonitor-help───sleep
        ├─rsyslogd─┬─{in:imklog}
        │          ├─{in:imuxsock}
        │          └─{rs:main Q:Reg}
        ├─sshd───sshd───bash───pstree
        ├─2*[systemd───(sd-pam)]
        ├─systemd-journal
        ├─systemd-logind
        └─systemd-udevd


[Wernieman]

Packet löschen <> Programm beenden.

Setzte mal ein "kill" auf das Programm an.

[persching]

Ok, Prozess gekillt - keine Veränderung im Verhalten von fhem. Der letzte Eintrag im Log ist wieder der gleiche:

Code Auswählen Erweitern

2017.12.27 19:26:01 1: PERL WARNING: DBD::SQLite::st execute failed: database is locked at configDB.pm line 407.
DBD::SQLite::st execute failed: database is locked at configDB.pm line 407.
2017.12.27 19:26:01 1: PERL WARNING: Issuing rollback() due to DESTROY without explicit disconnect() of DBD::SQLite::db handle dbname=/opt/fhem/configDB.db at configDB.pm line 407.

mit

Code Auswählen Erweitern

ps xa ist kein fhem Prozess mehr sichtbar.

[persching]

Hat noch jemand eine Idee wonach ich suchen könnte? Kann es was mit einer Systemaktualisierung zu tun haben? Ich armbian und cpan am selben Tag wie fhem aktualisiert und vielleicht liegt hier der Hund begraben...

[Wernieman]

Hast Du per cpan Module eingespielt?

Könntest Du diese löschen und durch Distri-Versionen ersetzen?

[persching]

Ich hab einfach cpan upgrade all gemacht

[Wernieman]

CPAN <> Distri-Perl

Deshalb .. kannst Du die per CPAN installierten Modules löschen und per Distri installieren (apt-get)?

[dev0]

Davon würde ICH abraten, da dadurch meist (ur)alte Versionen auf dem System landen. Was hat das mit dem Problem zu tun?

[Wernieman]

Kann es was mit einer Systemaktualisierung zu tun haben?

Und ich habe beruflich genau die Umgekehrte Erfahrung .. vor allem nach Updates

[persching]

Was hat das mit dem Problem zu tun?

Das ist ja genau meine Frage, ob es überhaupt eine Fehlerquelle sein könnte. Ich bin eigentlich immer der Meinung das System aktuell sein sollte.

[Wernieman]

Das System sollte aktuell sein. Nur wenn man "verschiedene Quellen mischt", können immer Seiteneffekte auftreten.

Bköde ist, das dieser Fehler scheinbar ein "Wackelkontackt" ist, so kann man gans schlecht auf Fehlersuche gehen. Es wird also versucht, im Nebel zu stochern und zu hoffen, das man Erkenntnis findet.

[persching]

so, gestern hatte ich nun Zeit dem Ganzen auf den Grund zu gehen. Ich habe das komplette System neu aufgesetzt und fhem aus einem Backup wieder eingespielt. Zuerst habe ich das mit Debian Stretch und als dann der Fehler immer noch aktuell war dachte ich vielleicht liegt es ja daran und hab das Ganze mit Debian Jessie wiederholt. Auch hier ist der Fehler genauso vorhanden. Bei meinem ursprünglichen System hatte ich das per dist-upgrade von jessie auf stretch gemacht. Jedenfalls ist der Fehler immer da und darum gehe ich davon aus, dass die Datenbank defekt ist.
Wie kann ich nun meine Definitionen behalten und den Rest der Datenbank neu aufsetzen? Die historischen Werte wären mir mittlerweile egal...

[dev0]

Wie kann ich nun meine Definitionen behalten und den Rest der Datenbank neu aufsetzen?

Deine Frage zu sehr "schwammig". Was willst Du genau wissen, was nicht in der command reference beschrieben ist?