Ich habe ein großes Problem mit Gladys.
Die Weboberfläche ist nicht erreichbar und nichts funktioniert mehr.
Ich bin auf einem rpi4 mit SSD. Keine aktuelle Konfiguration.
Ist das tot? Muss ich den Container neu installieren?
In den Logs läuft dieselbe Nachrichtenserie in einer Endlosschleife…
MQTT funktioniert und der Rest des Pi auch. Ein Neustart hat nichts geändert.
Wie bist du in diese Situation geraten? Was hast du gemacht?
Bearbeitung: Ich habe den Eindruck, dass deine Basismigration beim Update schiefgelaufen ist. Ich hoffe, du bist der Einzige, dem das passiert ist (bei mir ist alles gut gelaufen).
@GBoulvin sind wir uns einig, hattest du beim letzten Update schon mal ein Problem? Warst du nicht derjenige, der Probleme mit dem Speicherplatz auf Gladys hatte?
Jedenfalls keine Panik, es gibt immer einen Weg, deine Daten zu migrieren, also lösche bitte nichts
Bist du dir ganz sicher, dass dein SSD von Gladys verwendet wird, dass genug Platz vorhanden ist und dass alles in Ordnung ist?
Genau dieselbe Frage wie @VonOx, hast du nichts Besonderes an deiner Instanz gemacht? Hast du keine speziellen Builds auf deiner Produktions-DB installiert?
Falls es dir nichts ausmacht (falls du sensible Daten hast und es dir unangenehm ist, musst du es nicht tun, ich schlage es nur vor), könntest du bitte folgendes ausführen:
docker stop gladys
Dann die Datenbankdatei gladys-production.db aus dem Volume holen, das du beim Starten des Gladys-Containers angegeben hast und das auf deine SSD zeigt.
Das ist der linke Teil dieses Teils in deinem docker run:
Und falls es dir nichts ausmacht, könntest du mir die Datei privat im Forum schicken, damit ich sehen kann, was nicht stimmt (du kannst sie auf einen Dropbox/Drive stellen, was auch immer du möchtest). So können wir die Datenbankmigration eingrenzen.
Vielleicht kann ich dir die Datei korrigieren und du kannst sie dann in deine Instanz zurückintegrieren
Ich weiß, es ist ein bisschen handwerklich, aber es interessiert mich wirklich zu wissen, warum es bei dir besonders nicht funktioniert hat, während es bei allen anderen anscheinend funktioniert hat (zumindest hat sich meine Instanz selbst aktualisiert ohne Probleme, @VonOx ebenfalls, und alle vorherigen Tester hatten keine Probleme).
Also, da ich am 21. ein Backup der DB gemacht hatte, dachte ich, ich könnte sie wiederherstellen (bevor ich deine Nachricht gesehen habe).
Und es hat nicht funktioniert, die Fehlermeldung ist dieselbe.
Ich kann dir also die betreffende DB nicht mehr geben, da ich, ein bisschen dumm, die ‹ fehlerhafte › überschrieben habe, ohne sie zu sichern (da sie ja fehlerhaft war).
Ich schicke dir trotzdem die gesicherte DB (700 MB), die durch Gladys gelaufen ist, da sie wohl auch fehlerhaft ist?
Danke für deine Unterstützung!
PS: Ich verspreche, dass ich während des Updates nichts Ungewöhnliches gemacht habe (gab es ein Update?)
Gladys hat einfach aufgehört zu funktionieren (‹ nicht erreichbar ›). Ich habe es gemerkt, als die Aquarien nicht ausgeschaltet wurden und es im Wohnzimmer 24 Grad wurden
Ach, wenigstens gibt es etwas Positives: Es ist ein echtes Problem mit deiner DB und kein zufälliges Problem (z. B. eine Instanz, die neu startet, so etwas). Das ist gut zu wissen!
Aus Neugier, wann hast du Gladys zum ersten Mal installiert (um zu wissen, wie alt diese DB ist)? Bei der Veröffentlichung der v4? Während der Beta? Während der Alpha?
In all dem Leben dieser DB, bestätigst du, dass du nie eine « Custom Build » installiert hast, die auf dieselbe DB zugreift?
Jedenfalls werde ich heute Abend, wenn ich die DB sehe, Gewissheit haben, ich halte dich auf dem Laufenden!
Ja, ich habe Gladys v4.6.0 mit der Kurvenanzeige auf dem Dashboard veröffentlicht. Ich hatte noch keine Zeit, darüber zu kommunizieren, ich werde das am Wochenende an meinen Gladys-Tagen machen Die Idee war auch, die ersten Rückmeldungen abzuwarten, bevor ich darüber kommuniziere. Bisher hat sich außer dir niemand beschwert, also ist das eher positiv
Hallo!
Die erste Installation war im Dezember '20 und ich denke, dass die DB aus dieser Zeit stammt.
Ich habe nicht mit Test- oder Beta-Versionen herumgespielt.
Allerdings hatte ich in letzter Zeit ein paar Stromausfälle. Vielleicht ein Hinweis?
Ich hatte schon gesehen, dass sie im Bau war, aber du hast uns überrascht… Für Halloween?
Diese Dateien erscheinen nur, wenn die Datenbank in Verwendung ist. Es handelt sich um temporäre Dateien, die es SQLite ermöglichen, „WAL“ (write-ahead-log) zu speichern, damit deine Datenbank wiederhergestellt werden kann, falls Gladys abstürzt.
Falls du eine Kopie/Sicherung deiner Datenbank machen möchtest, muss Gladys zwingend gestoppt werden / oder du musst das offizielle SQLite-Backup-Tool (sqlite3 .backup, glaube ich) verwenden. Andernfalls kannst du, wenn du einfach nur die .db-Datei kopierst, auf eine beschädigte Datei stoßen.
Hast du zufällig diese Datenbank bewegt, ohne ein offizielles Tool zu verwenden oder Gladys zu stoppen?
Deine Datei konnte ich reparieren, aber ich kann sie dir erst morgen im Coworking hochladen, meine Upload-Geschwindigkeit zu Hause ist nicht stark genug, um sie dir zu schicken
In meinen Erinnerungen habe ich immer einen „Stop Gladys“ vor jedem DB-Backup gemacht, aber es ist nicht unmöglich, dass ich einen Fehler gemacht habe…
Ich nehme an, da die Daten nicht genutzt wurden, war es kein Problem, dass die DB beschädigt war.
Danach habe ich viel gesucht, um die Installation auf eine SSD zu übertragen, ich hatte eine beschädigte SD usw. So viele potenzielle Fehlerquellen!
Kurz gesagt, vielen Dank, dass du dir die Zeit genommen hast, es dir anzusehen.
Wenn es möglich ist und es dir passt, zögere nicht, die DB zu kürzen, um sie zu entlasten, ich habe keine lebenswichtigen Daten…
Ich erlaube mir, das von mir beobachtete Verhalten hinzuzufügen, ohne zu wissen, ob es einen Zusammenhang mit dem hier Dargestellten gibt?
In der Aufgabenliste stelle ich zwei Arten von Fehlern fest, die ständig auftreten (diese Seite wird sehr, sehr lang):
« Aggregation der Sensordaten monatlich/täglich/stündlich »:
Error: TypeError: Cannot read property '0' of undefined
at calculateTriangleArea (/src/server/node_modules/downsample/index.js:69:26)
at LTTBIndexesForBuckets (/src/server/node_modules/downsample/index.js:662:18)
at /src/server/node_modules/downsample/index.js:690:34
at /src/server/lib/device/device.calculcateAggregateChildProcess.js:119:27
at Map.forEach (<anonymous>)
at /src/server/lib/device/device.calculcateAggregateChildProcess.js:111:35
et (nur ein Auszug, da es viel länger ist), « Aggregation der Sensordaten stündlich »:
Error: TimeoutError [SequelizeTimeoutError]: SQLITE_BUSY: database is locked
at Query.formatError (/src/server/node_modules/sequelize/lib/dialects/sqlite/query.js:412:16)
at Query._handleQueryResponse (/src/server/node_modules/sequelize/lib/dialects/sqlite/query.js:72:18)
at Statement.afterExecute (/src/server/node_modules/sequelize/lib/dialects/sqlite/query.js:246:27) {
parent: [Error: SQLITE_BUSY: database is locked] {
errno: 5,
code: 'SQLITE_BUSY',
sql: "INSERT INTO `t_device_feature_state_aggregate` (`id`,`type`,`device_feature_id`,`value`,`created_at`,`updated_at`) VALUES
Ich habe das gleiche Problem. Es scheint, als würde der Gladys Plus-Backup die Datenbank sperren und wenn die Aggregation gleichzeitig startet (beispielsweise beim Hochfahren), erhalte ich diese Fehlermeldung.
Zusätzlich habe ich Fehler dieser Art nach einigen Minuten im Aggregationsteil
stündlich.
Ich habe den Raspberry Pi mehrmals neu gestartet, aber er bleibt bei 52% hängen. Ich möchte darauf hinweisen, dass ich eine SD-Karte und keinen SSD verwende
2021-10-28T10:37:51+0200 <info> device.calculateAggregate.js:38 (DeviceManager.calculateAggregate) Berechnung der Aggregatgerätezustände für das Intervall stündlich
2021-10-28T10:37:51+0200 <info> index.js:63 (Server.<anonymous>) Server hört auf Port 80
2021-10-28T10:44:47+0200 <warn> device.calculateAggregate.js:95 (Socket.<anonymous>) device.calculateAggregate stderr: RangeError: Maximum call stack size exceeded
at chunk (/src/server/utils/chunks.js:11:26)
at /src/server/lib/device/device.calculcateAggregateChildProcess.js:147:22
2021-10-28T10:44:47+0200 <warn> device.calculateAggregate.js:101 (ChildProcess.<anonymous>) device.calculateAggregate: Beenden des Child-Prozesses mit Code 1
2021-10-28T10:44:47+0200 <error> device.onHourlyDeviceAggregateEvent.js:22 (DeviceManager.onHourlyDeviceAggregateEvent) Error: RangeError: Maximum call stack size exceeded
at chunk (/src/server/utils/chunks.js:11:26)
at /src/server/lib/device/device.calculcateAggregateChildProcess.js:147:22
at ChildProcess.<anonymous> (/src/server/lib/device/device.calculateAggregate.js:102:23)
at ChildProcess.emit (events.js:400:28)
at maybeClose (internal/child_process.js:1058:16)
at Process.ChildProcess._handle.onexit (internal/child_process.js:293:5)
Hallo !!
Bei mir ist es genauso, die Fehler treten immer mal wieder auf, aber nicht dauerhaft. Ich dachte, du hättest das bereits erledigt @pierre-gilles, aber ich habe das Gefühl, dass es sich um einen anderen Fehler handelt:
Error: TimeoutError [SequelizeTimeoutError]: SQLITE_BUSY: Datenbank ist gesperrt
at Query.formatError (/src/server/node_modules/sequelize/lib/dialects/sqlite/query.js:412:16)
at Query._handleQueryResponse (/src/server/node_modules/sequelize/lib/dialects/sqlite/query.js:72:18)
at Statement.afterExecute (/src/server/node_modules/sequelize/lib/dialects/sqlite/query.js:246:27) {
parent: [Error: SQLITE_BUSY: Datenbank ist gesperrt] {
errno: 5,
code: 'SQLITE_BUSY',
sql: 'UPDATE `t_device_feature` SET `last_monthly_aggregate`=$1,`updated_at`=$2 WHERE `id` = $3'
},
original: [Error: SQLITE_BUSY: Datenbank ist gesperrt] {
errno: 5,
code: 'SQLITE_BUSY',
sql: 'UPDATE `t_device_feature` SET `last_monthly_aggregate`=$1,`updated_at`=$2 WHERE `id` = $3'
},
sql: 'UPDATE `t_device_feature` SET `last_monthly_aggregate`=$1,`updated_at`=$2 WHERE `id` = $3',
parameters: undefined
}
Das macht mich verrückt, ich weiß, dass @lmilcent sie auch während der Entwicklung hatte, aber ich habe es nie geschafft, es zu reproduzieren… Vielleicht könntest du mal schauen, was die API dir zurückgibt, @cicoub13?
das könnte am Gladys Plus-Backup liegen, das gleichzeitig startet, ich werde versuchen, die Aggregation zu verhindern, wenn das Backup läuft.
