Nachdem ich ja schon im anderen Thema geschrieben habe https://forum.fhem.de/index.php?topic=81533 (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. :(
Dannmach doch mal ein "pstree", dort siehst Du dann, welcher Prozess den sleep aufruft
Das sleep kommt von rpimonitor-help. Allerdings habe ich rpimonitor schon gelöscht apt-get purge rpimonitor. Das Paket auch nicht mehr installiert, aber dieser Prozess ist immer noch drin.
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
Packet löschen <> Programm beenden.
Setzte mal ein "kill" auf das Programm an.
Ok, Prozess gekillt - keine Veränderung im Verhalten von fhem. Der letzte Eintrag im Log ist wieder der gleiche:
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 ps xa ist kein fhem Prozess mehr sichtbar.
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...
Hast Du per cpan Module eingespielt?
Könntest Du diese löschen und durch Distri-Versionen ersetzen?
Ich hab einfach cpan upgrade all gemacht
CPAN <> Distri-Perl
Deshalb .. kannst Du die per CPAN installierten Modules löschen und per Distri installieren (apt-get)?
Davon würde ICH abraten, da dadurch meist (ur)alte Versionen auf dem System landen. Was hat das mit dem Problem zu tun?
ZitatKann es was mit einer Systemaktualisierung zu tun haben?
Und ich habe beruflich genau die Umgekehrte Erfahrung .. vor allem nach Updates
Zitat von: dev0 am 04 Januar 2018, 19:30:38
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.
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.
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...
Zitat von: persching am 03 Februar 2018, 09:58:59
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?
Ok, dein Beitrag hat mich angespornt. Ich habe nun configDB und logDB getrennt - zuvor hatte ich alles in eine sqlite Datenbankfile geschrieben. Das war mir im ersten Moment nicht klar, wie ich das wieder trennen kann. Aber ich hab mir die Datenbank angesehen und gemerkt, dass es ja verschiedene Tabellen gibt. Jetzt sind sie wie gesagt getrennt und nun funktioniert auch alles wieder so wie es soll. Und sollte sowas wieder passieren ist es auch einfacher neu zu beginnen, weil die configDB eigenständig ist.
Danke!! Thema erledig!! :)