UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[BananaJoe]

@klassisch naja, jetzt darf er alle Datenbanken, iobroker müsste auf der Datenbank berechtigt werden mit vollzugriff.
Aber so geht es auch, ist aber nicht so gewollt

[klassisch]

@bananajoe Sorry, das habe ich nicht verstanden.
Ist der "global" Haken bei Heidi nicht in Ordnung?

Durch einen neuen user kommt Grafana einen Schritt weiter und testet irgendwas. Darf dann aber doch irgendwie nicht.

Zu viele Benutzer, zu viele Rechte, Fehlermeldung zu unspezifisch.

lEin Verbindungsversuch ist fehlgeschlagen, da die Gegenstelle nach einer bestimmten Zeitspanne nicht richtig reagiert hat, oder die hergestellte Verbindung war fehlerhaft, da der verbundene Host nicht reagiert hat."
logger=context t=2022-03-25T10:55:26.63+0100 lvl=info msg="Request Completed" method=POST path=/api/ds/query status=400 remote_addr=127.0.0.1 time_ms=21045 size=233 referer=http://localhost:3000/datasources/edit/-JNX6my7z

In den 70ern und 80ern hat unsere Univac auch immer gesagt "USR did ERR". War etwa genauso aufschlußreich....

[BananaJoe]

@klassisch pff da bin ich der falsche. Ich mache das inzwischen seit über 20 Jahren und lege meine Datenbanken z.B. per

reate database iobroker character set utf8 collate utf8_bin;
create user 'iobroker'@'localhost' identified by 'test1234'
grant all privileges on iobroker.* to 'iobroker'@'localhost'

legte eine Datenbank iobroker an auf die ein lokaler Benutzer / ein Benutzer ausschließlich lokal zugreifen kann der iobroker heißt und das Passwort test1234 hat.

Ich kenne HeidiSQL zwar, nutze das aber nur sehr selten.

Ich bin so alt, meine Musik und Bilder sind noch Ordner sortiert, nicht nach Tags oder Metadaten.

[klassisch]

Noch ne Frage.MariaDB läuft bei mir derzeit im Probebetrieb. Aber alle paar Tage bekomme ich logeinträge mit Fehlermeldungen.
Der Dienst MariaDB läuft dann nicht mehr und muß neu gestartet werden.
Habe ich da irgendeine Option vergessen, daß das Ding durchläuft? Gibt es da ein timeout?

[BananaJoe]

@klassisch wie wäre der Inhalt des Logs denn? Es gibt bei normalen Installationen unter var/log/mysql/error.log ein Log im welchen der Grund stehen sollte. (Ja, Ordner mysql auch bei mariadb, zumindest unter Ubuntu, Ordner mariadb aber auch möglich)

Vermutlich so etwas wie out of Memory (rate ich jetzt einfach mal) was auch davon abhängt wie der Server Konfiguriert ist. Ist jedenfalls der häufigste Grund warum der nach ein paar Tagen aufgeben sollte. Insbesondere wenn mehr Cache konfiguriert ist RAM vorhanden ist.

[klassisch]

@bananajoe Vielen Dank,
Unter Win sind die Namen anscheinend anders.
Da gibt es auf der Datenplatte unter

Rechnername.err

ein Logfile

Ich zitiere mal, was ich kurz vor bzw. dem letzten Absturz halte

2022-03-25 17:42:48 59 [Warning] Aborted connection 59 to db: 'unconnected' user: 'unauthenticated' host: 'DESKTOP-NAME.fritz.box' (This connection closed normally without authentication)
2022-03-25 17:44:57 134 [Warning] Access denied for user 'pcuser'@'DESKTOP-NAME.fritz.box' (using password: YES)
2022-03-25 17:45:58 169 [Warning] Access denied for user 'pcuser'@'DESKTOP-NAME.fritz.box' (using password: YES)

Also es scheint irgendein Rechteproblem zu sein.
Ich wart mal den nächsten Crash ab und schaue dann im log nach BEVOR ich neu starte. Dann erwische ich zumindest hoffentlich die richtige Stelle.

Speicher habe ich 8GB auf meinem i5. Und der Task Manager zeigt jetzt keine auffällige Speicherbelegung durch MariaDB

[BananaJoe]

@klassisch wenn die Datenbank steht, die letzten 10 Zeilen wären interessant (ggf. mehr, alles was du in den letzten Sekunden kommt). Bevor du die wieder startest.

Ich bin sicher die stürzt nicht ab sondern beendet sich wegen eines Grundes selbst.

[klassisch]

@bananajoe Danke, momentan läuft sie gerade (noch). Beim nächsten ungewollten Beenden schaue ich im log nach.
Kann man da ein loglevel einstellen? Soll ich da etwas höher stellen?

[BananaJoe]

@klassisch könnte man wohl aber bisher hatte bei solchen Fehlern der Standard gereicht.

[klassisch]

@bananajoe gestern Abend hat MariaDB wieder gestreikt

Im ioBroker sieht das log so aus:

2022-03-30 17:34:50.601  - error: sql.0 (13376) Cannot insert INSERT INTO `iobroker`.ts_number (id, ts, val, ack, _from, q) VALUES(3, 1648654479478, 997, 0, 2, 0);: Error: read ECONNRESET (id: 0_userdata.0.power.smartMeterSampleTime)
2022-03-30 17:34:50.618  - error: sql.0 (13376) Cannot insert INSERT INTO `iobroker`.ts_number (id, ts, val, ack, _from, q) VALUES(3, 1648654486481, 3000, 0, 2, 0);: Error: read ECONNRESET (id: 0_userdata.0.power.smartMeterSampleTime)
2022-03-30 17:34:50.620  - error: sql.0 (13376) Cannot insert INSERT INTO `iobroker`.ts_number (id, ts, val, ack, _from, q) VALUES(3, 1648654465480, 998, 0, 2, 0);: Error: read ECONNRESET (id: 0_userdata.0.power.smartMeterSampleTime)
2022-03-30 17:34:50.622  - error: sql.0 (13376) Cannot insert INSERT INTO `iobroker`.ts_number (id, ts, val, ack, _from, q) VALUES(1, 1648654485012, 615.7, 1, 2, 0);: Error: read ECONNRESET (id: 0_userdata.0.power.smartmeterReading)
2022-03-30 17:34:50.625  - error: sql.0 (13376) Cannot insert INSERT INTO `iobroker`.ts_number (id, ts, val, ack, _from, q) VALUES(3, 1648654488487, 996, 0, 2, 0);: Error: read ECONNRESET (id: 0_userdata.0.power.smartMeterSampleTime)
2022-03-30 17:34:50.628  - error: sql.0 (13376) Cannot insert INSERT INTO `iobroker`.ts_number (id, ts, val, ack, _from, q) VALUES(3, 1648654483480, 1000, 0, 2, 0);: Error: read ECONNRESET (id: 0_userdata.0.power.smartMeterSampleTime)
2022-03-30 17:34:50.637  - error: sql.0 (13376) Cannot insert INSERT INTO `iobroker`.ts_number (id, ts, val, ack, _from, q) VALUES(3, 1648654482480, 1000, 0, 2, 0);: Error: read ECONNRESET (id: 0_userdata.0.power.smartMeterSampleTime)
2022-03-30 17:34:50.640  - error: sql.0 (13376) Cannot insert INSERT INTO `iobroker`.ts_number (id, ts, val, ack, _from, q) VALUES(3, 1648654469479, 999, 0, 2, 0);: Error: read ECONNRESET (id: 0_userdata.0.power.smartMeterSampleTime)
2022-03-30 17:34:50.643  - error: sql.0 (13376) Cannot insert INSERT INTO `iobroker`.ts_number (id, ts, val, ack, _from, q) VALUES(3, 1648654474480, 994, 0, 2, 0);: Error: read ECONNRESET (id: 0_userdata.0.power.smartMeterSampleTime)
2022-03-30 17:34:50.649  - error: sql.0 (13376) Cannot insert INSERT INTO `iobroker`.ts_number (id, ts, val, ack, _from, q) VALUES(3, 1648654467480, 995, 0, 2, 0);: Error: read ECONNRESET (id: 0_userdata.0.power.smartMeterSampleTime)
2022-03-30 17:34:50.650  - error: sql.0 (13376) Cannot insert INSERT INTO `iobroker`.ts_number (id, ts, val, ack, _from, q) VALUES(3, 1648654472479, 1000, 0, 2, 0);: Error: read ECONNRESET (id: 0_userdata.0.power.smartMeterSampleTime)
2022-03-30 17:34:50.653  - error: sql.0 (13376) Cannot insert INSERT INTO `iobroker`.ts_number (id, ts, val, ack, _from, q) VALUES(1, 1648654470014, 610.5, 1, 2, 0);: Error: read ECONNRESET (id: 0_userdata.0.power.smartmeterReading)
2022-03-30 17:34:50.655  - error: sql.0 (13376) Cannot insert INSERT INTO `iobroker`.ts_number (id, ts, val, ack, _from, q) VALUES(3, 1648654480480, 1002, 0, 2, 0);: Error: read ECONNRESET (id: 0_userdata.0.power.smartMeterSampleTime)
2022-03-30 17:34:50.658  - error: sql.0 (13376) Cannot insert INSERT INTO `iobroker`.ts_number (id, ts, val, ack, _from, q) VALUES(3, 1648654475488, 1007, 0, 2, 0);: Error: read ECONNRESET (id: 0_userdata.0.power.smartMeterSampleTime)
2022-03-30 17:34:51.487  - error: sql.0 (13376) Error: connect ECONNREFUSED 127.0.0.1:3306
2022-03-30 17:34:52.486  - error: sql.0 (13376) Error: connect ECONNREFUSED 127.0.0.1:3306
2022-03-30 17:34:54.485  - error: sql.0 (13376) Error: connect ECONNREFUSED 127.0.0.1:3306
2022-03-30 17:34:56.482  - error: sql.0 (13376) Error: connect ECONNREFUSED 127.0.0.1:3306
2022-03-30 17:34:57.485  - error: sql.0 (13376) Error: connect ECONNREFUSED 127.0.0.1:3306
2022-03-30 17:34:58.488  - error: sql.0 (13376) Error: connect ECONNREFUSED 127.0.0.1:3306

Es scheint also Probleme mit dem Datenpunkt "smartMeterSampleTime" zu geben. Der wird von einem Script etwa sekündlich erzeugt und läuft stabil durch. Also auch jetzt noch.

Im Errorlog von MariaDB selbst war da gar nichts zu sehen. Da sieht man nur den letzten Start

2022-03-28  8:05:24 0 [Note] InnoDB: Starting final batch to recover  540 pages from redo log.
2022-03-28  8:05:24 0 [Note] InnoDB: 128 rollback segments are active.
2022-03-28  8:05:24 0 [Note] InnoDB: Removed temporary tablespace data file: "./ibtmp1"
2022-03-28  8:05:24 0 [Note] InnoDB: Creating shared tablespace for temporary tables
2022-03-28  8:05:24 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
2022-03-28  8:05:24 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB.
2022-03-28  8:05:24 0 [Note] InnoDB: 10.7.3 started; log sequence number 32056487; transaction id 313154
2022-03-28  8:05:24 0 [Note] Plugin 'FEEDBACK' is disabled.
2022-03-28  8:05:24 0 [Note] InnoDB: Loading buffer pool(s) from F:\mariadb\data\ib_buffer_pool
2022-03-28  8:05:24 0 [Note] InnoDB: Buffer pool(s) load completed at 220328  8:05:24
2022-03-28  8:05:24 0 [Note] Server socket created on IP: '::'.
2022-03-28  8:05:24 0 [Note] Server socket created on IP: '0.0.0.0'.
2022-03-28  8:05:26 0 [Note] C:\Program Files\MariaDB 10.7\bin\mysqld.exe: ready for connections.
Version: '10.7.3-MariaDB'  socket: ''  port: 3306  mariadb.org binary distribution

[BananaJoe]

@klassisch wenn es das error.log ist dann läuft aus dessen Sicht der dienst noch.

ok Windows - Was sagt denn das Ereignisprotokoll? Auch Eventlog genannt, das von Windows selbst.
Es gibt einen Dienst für MariaDB, richtig? Der auf Automatisch steht. In den Erweiterten Einstellungen kann man dort setzen das er den Dienst bei einem Fehler wieder neu startet (was zwar die Symptome lindert habe den Grund nicht erklärt)

[klassisch]

@bananajoe Ja, vielen Dank, di Ereignisanzeige sagt was:

• Fehler 17:34, MariaDB: InnoDB: Operating system error number 55 in a file operation.

• Info 17:34 MariaDB: InnoDB: Some operating system error numbers are described at https://mariadb.com/kb/en/library/operating-system-error-codes/ . Der Link führt zu einer Website und dort steht unter 55:
  "55 ENOANO No anode" .

• Fehler 17:34 MariaDB: InnoDB: File (unknown): 'flush' returned OS error 255. Cannot continue operation

• Fehler 17:34 Application Error: Name der fehlerhaften Anwendung: mysqld.exe, Version: 10.7.3.0, Zeitstempel: 0x6205972c

  • Name des fehlerhaften Moduls: server.dll, Version: 10.7.3.0, Zeitstempel: 0x62059706
  • Ausnahmecode: 0x80000003
  • Fehleroffset: 0x00000000003e8582
  • ID des fehlerhaften Prozesses: 0x333c
  • Startzeit der fehlerhaften Anwendung: 0x01d84269cde184f4
  • Pfad der fehlerhaften Anwendung: C:\Program Files\MariaDB 10.7\bin\mysqld.exe
  • Pfad des fehlerhaften Moduls: C:\Program Files\MariaDB 10.7\bin\server.dll
  • Berichtskennung: fd3a5e4e-dbdb-4b02-ad2b-e68ce2eef71f
  • Vollständiger Name des fehlerhaften Pakets:
  • Anwendungs-ID, die relativ zum fehlerhaften Paket ist:

• 17:34 Win Error Reporting

  • Fehlerbucket 1742235423834438271, Typ 4

  • Ereignisname: APPCRASH

  • Antwort: Nicht verfügbar

  • CAB-Datei-ID: 0

  • Problemsignatur:

  • P1: mysqld.exe

  • P2: 10.7.3.0

  • P3: 6205972c

  • P4: server.dll

  • P5: 10.7.3.0

  • P6: 62059706

  • P7: 80000003

  • P8: 00000000003e8582

  • P9:

  • P10:

  • Angefügte Dateien:

  • \?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER2CE7.tmp.dmp

  • \?\C:\ProgramData\Microsoft\Windows\WER\Temp

  • \WER2D94.tmp.WERInternalMetadata.xml

  • \?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER2DC4.tmp.xml

  • \?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER2DC2.tmp.csv

  • \?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER2E01.tmp.txt

  • Diese Dateien befinden sich möglicherweise hier:

  • \?\C:\ProgramData\Microsoft\Windows\WER\ReportArchive

  • \AppCrash_mysqld.exe_8bb04fadc453dbcb7177ab22926491040a8e4dc_48e38982_45e41aa6-c491-4535-8a75-0ed9d29c1cbe

  • Analysesymbol:

  • Es wird erneut nach einer Lösung gesucht: 0

  • Berichts-ID: fd3a5e4e-dbdb-4b02-ad2b-e68ce2eef71f

  • Berichtstatus: 268435456

  • Bucket mit Hash: 99f2dff1847fb019d82da9e320c0fa7f

  • CAB-Datei-Guid: 0

Die verlinkten Dateien sind entweder nicht (mehr) vorhanden oder access denied.

MariaDB scheint also Probleme mit dem Filesystem oder einem "Flush" zu haben.

Ich lege die Daten auf einer externen Platte ab, auf der ich auch die history Daten und andere Daten eines anderen Vielschreiber-Programms ablege.

Beim nächsten "Husten" versuche ich mal die Daten auf die Syste-SSD zu schreiben - was ich eigentlich vermeiden wollte.

Ich vermute mal - ohne eine wirkliche Ahnung zu haben - daß die Implementierung unter Windows nicht ganz so robust zu sein scheint. Wäre schade.

Edit: zu ENOANO findet man bei https://unix.stackexchange.com/questions/167368/what-is-enoano-no-anode-intended-to-be-used-for eine Antwort, bei der jemand richtig tief recherchiert hat.

Das scheint uralt zu sein, noch von Convergent/Burroughs Unix (CENTIX) stammend. Hat sich irgendwie durchgeschleppt, geriet aber in Vergessenheit

"So ENOANO probably indicated that either the kernel had run out of memory for inodes, or that the filesystem's inode table was full, in some commercial Unix in the 1980s. That Unix is now forgotten, its terminology is now forgotten, and due to some quirk the error code has stayed around."

[BananaJoe]

@klassisch der Dienst läuft unter welchen Benutzer?
Und die Datenbank auf einer USB-Festplatte abzulegen ist denkbar doof (wenn ich das richtig verstanden habe)

kein Zugriff ... es ist wichtig das der Benutzer unter dem MariaDB läuft zugriff hat. Wenn das SYSTEM ist sollte alles ok sein.

[klassisch]

@bananajoe Vielen Dank!
Das sieht interessant aus:

Keine Ahnung wie das zustande kommt und ob/wie ich das ändern könnte.

Ja, SSD wäre blöd, deshalb ist das derzeit eine WD purple, die ohnehin 24/7 läuft, wofür sie auch ausgelegt ist.

Aber wegen der "Flush" Thematik hätte ich das halt probeweise auf die SSD gelegt bis das Problem behoben ist.

[BananaJoe]

@klassisch ok, dann kannst du Prüfen ob der Benutzer NT-SERVICE\MariaDB die Rechte auf die Verzeichnisse hat (was er haben sollte)

[klassisch]

@bananajoe Vielen Dank! Auch mit Adminrechten angemeldet sehe ich diesen Benutzer leider nicht in der Benutzerverwaltung.

Prinzipiell darf Maria ja auf dieses Verzeichnis schreiben

Ich habe jetzt nochmals explizit für diesen Ordner eine Freigabe für den User MariDB erteilt. der User NT-SERVICE\MariaDB wurde abgelehnt, da nicht gefunden. MariaDB wurde akzeptiert und ist jetzt eingetragen. Mal sehen....

[BananaJoe]

@klassisch ja, das sind diese neuen Spezialbenutzer für Dienste welche automatisch ihre Kennwörter ändern.
Sehr löblich das die das einsetzen, das gibt es auch schon seit vielen Jahren ... aber ich hatte mich noch nicht näher damit beschäftigt. Ich weis das die gibt. Das war es auch schon.

Eigentlich sollte das Setup da alles selbst richtig machen.
Das Datenbankverzeichnis im Virenscanner ausklammern?

[klassisch]

@bananajoe Vielen Dank! Was es alles gibt. System vergibt und ändert selbst Passwörter.

Ich habe ja die Zugriffsrechte aufs Verzeichnis gewährt und warte ab.
Das mit dem Virenscanner mache ich als nächstes, wenn das Teil wieder stehen bleibt. Und das eigentlich eher ungern. Wäre ja schade, wenn eine Security Maßnahme dazu führen würde, daß eine fundamentalere ausgehebelt werden müßte.

[BananaJoe]

@klassisch Wenn nur das Verzeichnis mit den Datenbanken ausnehmen

[klassisch]

Heute Mittag um 14:08:40 gab es einen interessanten Vorfall.
Anscheinend hatte die externe Platte, auf die noch andere Programme zugreifen, einen hickup.
History hat sich beschwert, daß er einige Dateien nicht lesen könne.
Und dann kam auch sql.
Während sich history aber wieder gefangen hat, war das bei der sql nicht der Fall. Den ganzen Nachmittag Fehlermeldungen. Ein Neustart des MariaDB Dienstes, der zwar noch lief sich aber nicht merh aus dem Fehlersumpf befreien konnte, half dann.

Mein Fazit: Die MariaDB Implementierung unter Windows scheint nicht fehlertolerant ausgelegt zu sein. Einmal ein Problem mit dem (externen) Datenspeicher und es ist ein externer Eingriff erforderlich.

History ist da gutmütiger und robuster.