29.01.2019, 09:57
Nicht nur die Datenbank auch der MQTT-Server und das node-red Modul werden nicht mehr geschrieben.
Das Programm smartpireadout stellt seine Arbeit ein. Es ist zwar in der Prozessliste noch vorhanden, ruft man aber Top auf erscheint es nicht mehr in den oberen Rängen. Das ist nach einem Neustart anders.
Zeitlich gibt es keine Regelmäßigkeit. Der Ausfall ist bei uns nach 8, 10 aber auch schon nach einer Stunde aufgetreten.
An der Datenbank liegt das Verhalten nicht, ich habe im File /etc/smartpi mal folgendes eingetragen (weil es über die Oberfläche nicht geht):
[database]
counter_enabled = true
counterdir = /var/smartpi
database_enabled = false
dir = /var/smartpi/db
Die Datenbank wird dann auch wirklich nicht geschrieben. Trotzdem tritt das oben beschriebene Verhalten auf.
Hier mal ein Auszug aus dem syslog zur Zeit des "Absturzes":
Jan 26 19:06:10 smartpi smartpi[307]: time="2019-01-26T19:06:10+01:00" level=info msg="## Shared File Update ## 2019-01-26 19:06:10 I1: 0.5049316644388678 I2: 0.7634404619668893 I3: 2.1576513980491945 I4: 1.7449781729178298 V1: 228.2407 V2: 230 V3: 230 P1: 92.172924 P2: 175.59130625238453 P3: 496.25982155131476 COS1: 0.676092703575316 COS2: 1 COS3: 1 F1: 49.99023628197617 F2: 52.021946758788864 F3: 104.0650406504065 Balanced: 1.0386594152719524 "
Jan 26 19:06:42 smartpi smartpi[307]: time="2019-01-26T19:06:42+01:00" level=error msg="Readout delayed: 31.247075233s"
Jan 26 19:06:46 smartpi smartpi[307]: time="2019-01-26T19:06:46+01:00" level=info msg="## Shared File Update ## 2019-01-26 19:06:46 I1: 0.5021041071723237 I2: 0.7694959385908151 I3: 2.1680357897803075 I4: 1.7483562280592764 V1: 227.8055 V2: 230 V3: 230 P1: 92.01762 P2: 176.98406587588747 P3: 498.64823164947074 COS1: 0.5996348475233524 COS2: 1 COS3: 1 F1: 49.99023628197617 F2: 46.613255644573925 F3: 83.1979200519987 Balanced: 1.0644903618853736 "
Jan 26 19:07:09 smartpi smartpi[307]: root 323 1 0 18:30 ? 00:00:00 su pi -c /usr/local/bin/smartpiserver
Jan 26 19:07:09 smartpi smartpi[307]: pi 600 323 0 18:30 ? 00:00:00 /usr/local/bin/smartpiserver
Jan 26 19:07:09 smartpi smartpi[307]: root 322 1 0 18:30 ? 00:00:00 su pi -c /usr/local/bin/smartpireadout
Der MQTT Client stellt aber schon ca. 5 Minuten vorher seinen Betrieb ein. Die letzten 3 Zeilen wiederholen sich dann permanent.
Die Error Fehlermeldung wiederholt sich 6 mal bevor das Programm seinen Dienst komplett einstellt.
Jan 26 19:04:18 smartpi smartpi[307]: time="2019-01-26T19:04:18+01:00" level=error msg="Readout delayed: 31.24703694s"
Jan 26 19:04:54 smartpi smartpi[307]: time="2019-01-26T19:04:54+01:00" level=error msg="Readout delayed: 31.247427508s"
Jan 26 19:05:30 smartpi smartpi[307]: time="2019-01-26T19:05:30+01:00" level=error msg="Readout delayed: 31.24692847s"
Jan 26 19:06:06 smartpi smartpi[307]: time="2019-01-26T19:06:06+01:00" level=error msg="Readout delayed: 31.247677045s"
Jan 26 19:06:42 smartpi smartpi[307]: time="2019-01-26T19:06:42+01:00" level=error msg="Readout delayed: 31.247075233s"
Jan 26 19:07:18 smartpi smartpi[307]: time="2019-01-26T19:07:18+01:00" level=error msg="Readout delayed: 31.247524165s"
Bei ersten Mal wird der MQTT-Server nicht mehr beschrieben, beim letzten Mal dann der File nicht mehr.
Das Script /usr/local/bin/smartpi_check_umts.sh haben wir angepasst. Da das Programm smartpireadout aber nicht abstürzt, sondern nur seine Arbeit einstellt, wird es nicht neu gestartet.
Wenn man aber das Programm mit kill abschießt wird es vom script neu gestartet und funktioniert auch wieder.
Wir haben den Raspberry auf dem aktuellen Softwarestand (OS und smartpi).
Das Programm smartpireadout stellt seine Arbeit ein. Es ist zwar in der Prozessliste noch vorhanden, ruft man aber Top auf erscheint es nicht mehr in den oberen Rängen. Das ist nach einem Neustart anders.
Zeitlich gibt es keine Regelmäßigkeit. Der Ausfall ist bei uns nach 8, 10 aber auch schon nach einer Stunde aufgetreten.
An der Datenbank liegt das Verhalten nicht, ich habe im File /etc/smartpi mal folgendes eingetragen (weil es über die Oberfläche nicht geht):
[database]
counter_enabled = true
counterdir = /var/smartpi
database_enabled = false
dir = /var/smartpi/db
Die Datenbank wird dann auch wirklich nicht geschrieben. Trotzdem tritt das oben beschriebene Verhalten auf.
Hier mal ein Auszug aus dem syslog zur Zeit des "Absturzes":
Jan 26 19:06:10 smartpi smartpi[307]: time="2019-01-26T19:06:10+01:00" level=info msg="## Shared File Update ## 2019-01-26 19:06:10 I1: 0.5049316644388678 I2: 0.7634404619668893 I3: 2.1576513980491945 I4: 1.7449781729178298 V1: 228.2407 V2: 230 V3: 230 P1: 92.172924 P2: 175.59130625238453 P3: 496.25982155131476 COS1: 0.676092703575316 COS2: 1 COS3: 1 F1: 49.99023628197617 F2: 52.021946758788864 F3: 104.0650406504065 Balanced: 1.0386594152719524 "
Jan 26 19:06:42 smartpi smartpi[307]: time="2019-01-26T19:06:42+01:00" level=error msg="Readout delayed: 31.247075233s"
Jan 26 19:06:46 smartpi smartpi[307]: time="2019-01-26T19:06:46+01:00" level=info msg="## Shared File Update ## 2019-01-26 19:06:46 I1: 0.5021041071723237 I2: 0.7694959385908151 I3: 2.1680357897803075 I4: 1.7483562280592764 V1: 227.8055 V2: 230 V3: 230 P1: 92.01762 P2: 176.98406587588747 P3: 498.64823164947074 COS1: 0.5996348475233524 COS2: 1 COS3: 1 F1: 49.99023628197617 F2: 46.613255644573925 F3: 83.1979200519987 Balanced: 1.0644903618853736 "
Jan 26 19:07:09 smartpi smartpi[307]: root 323 1 0 18:30 ? 00:00:00 su pi -c /usr/local/bin/smartpiserver
Jan 26 19:07:09 smartpi smartpi[307]: pi 600 323 0 18:30 ? 00:00:00 /usr/local/bin/smartpiserver
Jan 26 19:07:09 smartpi smartpi[307]: root 322 1 0 18:30 ? 00:00:00 su pi -c /usr/local/bin/smartpireadout
Der MQTT Client stellt aber schon ca. 5 Minuten vorher seinen Betrieb ein. Die letzten 3 Zeilen wiederholen sich dann permanent.
Die Error Fehlermeldung wiederholt sich 6 mal bevor das Programm seinen Dienst komplett einstellt.
Jan 26 19:04:18 smartpi smartpi[307]: time="2019-01-26T19:04:18+01:00" level=error msg="Readout delayed: 31.24703694s"
Jan 26 19:04:54 smartpi smartpi[307]: time="2019-01-26T19:04:54+01:00" level=error msg="Readout delayed: 31.247427508s"
Jan 26 19:05:30 smartpi smartpi[307]: time="2019-01-26T19:05:30+01:00" level=error msg="Readout delayed: 31.24692847s"
Jan 26 19:06:06 smartpi smartpi[307]: time="2019-01-26T19:06:06+01:00" level=error msg="Readout delayed: 31.247677045s"
Jan 26 19:06:42 smartpi smartpi[307]: time="2019-01-26T19:06:42+01:00" level=error msg="Readout delayed: 31.247075233s"
Jan 26 19:07:18 smartpi smartpi[307]: time="2019-01-26T19:07:18+01:00" level=error msg="Readout delayed: 31.247524165s"
Bei ersten Mal wird der MQTT-Server nicht mehr beschrieben, beim letzten Mal dann der File nicht mehr.
Das Script /usr/local/bin/smartpi_check_umts.sh haben wir angepasst. Da das Programm smartpireadout aber nicht abstürzt, sondern nur seine Arbeit einstellt, wird es nicht neu gestartet.
Wenn man aber das Programm mit kill abschießt wird es vom script neu gestartet und funktioniert auch wieder.
Wir haben den Raspberry auf dem aktuellen Softwarestand (OS und smartpi).
