C’est mort? Je suis bon pour une réinstallation (du container)?
Dans les logs, c’est la même série de messages qui tourne en boucle…
MQTT fonctionne et le reste du pi aussi. Un reboot n’a rien changé.
Bah comment tu t’es retrouvé dans cette situation ? Quelles manipulations as tu faites ?
Edit : j’ai l’impression que ta migration de base a foiré lors de la mise à jour, j’espère que tu es seul dans ce cas ( ça s’est bien passé de mon côté)
Si ça ne te dérange pas (si tu as des données sensible et que ça te dérange t’es pas obligé, je propose juste), est-ce que tu pourrais faire un :
docker stop gladys
Puis récupérer le fichier de DB: gladys-production.db qui se trouve dans le volume que tu as du spécifier quand tu as lancé un container Gladys qui pointe vers ton SSD.
C’est la partie gauche de cette partie dans ton docker run:
Et si ça ne te dérange pas, de me l’envoyer en privée sur le forum pour que je vois ce qui ne va pas (tu le mets sur un dropbox/drive, ce que tu veux) Comme ça on sera cerné sur la partie migration de DB.
Eventuellement, je peux te corriger le fichier et tu pourras le réintégrer à ton instance
Je sais c’est un peu artisanal, mais ça m’intéresse vraiment de savoir pourquoi chez toi particulièrement ça n’a pas fonctionné, alors que ça a fonctionné chez tout le monde à priori (en tout cas moi mon instance s’est mise à jour toute seul sans problème, @VonOx de même, et tous les précédents testeurs n’avaient pas eu de problèmes)
Alors, vu que j’avais fait un backup de la DB le 21, je me suis dit que j’allais la réinjecter (avant de voir ton message).
Et ça n’a pas fonctionné, le message est identique.
Je ne puis donc plus te refiler la DB en question car étant un peu idiot, j’ai écrasé la ‘défectueuse’ sans la sauvegarder (puisqu’elle était défectueuse)
Je t’envoie toutefois la DB sauvegardée (700Mo) et passée dans Gladys, vu qu’elle semble défectueuse également?
Merci pour ton support !
PS: je promets que j’ai rien fait d’anormal pendant la mise à jour (il y a eu une mise à jour?)
Gladys a juste arrêté de fonctionner (‘inaccessible’). Je m’en suis rendu compte quand les aquariums ne se sont pas éteins et qu’on a atteint les 24 degrés dans le salon
Ah, au moins il y a quelque chose de positif: c’est un vrai problème lié à ta DB et pas un problème random (genre instance qui reboot, ce genre de chose). C’est bon à savoir !
Par curiosité, tu avais installé Gladys à quelle époque la première fois (pour savoir de quand date cette DB) ? A la sortie de la v4 ? Pendant la beta ? Pendant l’alpha ?
Dans toutes la vie de cette DB, tu confirme que tu n’as jamais installé de « build custom » qui tape sur cette même DB ?
De toute façon je serais fixé en voyant la DB tout à l’heure, je te tiens au courant!
Yes j’ai sorti Gladys v4.6.0 avec l’affichage courbes sur le dashboard. J’ai pas encore eu le temps de communiquer dessus, je ferais ça en fin de semaine sur mes jours Gladys L’idée c’était aussi d’attendre les premiers retours avant de communiquer dessus, pour l’instant à part toi personne s’est plaint donc c’est plutôt positif
Salut!
La première installation date de décembre '20 et je pense que la DB vient de ce moment là.
Je n’ai pas joué avec les versions tests ou béta.
Par contre, j’ai eu quelques coupures de courant ces derniers temps. Peut-être une piste?
J’avais bien vu qu’elle était en build mais tu nous as pris par surprise… Pour Halloween?
Ces fichiers apparaissent uniquement quand la DB est en cours d’utilisation, ce sont des fichiers temporaires qui permettent à SQLite de stocker des « WAL » (write-ahead-log), afin que si Gladys crash, ta DB puisse récupérer lorsque Gladys reboot.
Si jamais tu veux faire une copie/backup de ta DB, il faut nécessairement que Gladys soit stoppée / ou que tu utilise l’utilitaire de backup officiel de SQLite (sqlite3 .backup je crois), sinon si tu copie juste le fichier .db tu peux atterir sur un fichier corrompu.
Est-ce que par hasard tu n’as pas bougée cette DB sans passer par un utilitaire officiel/sans stopper Gladys ?
Pour ton fichier, j’ai réussi à le corriger, par contre je pourrais pas te l’uploader avant demain au cowork, ma connexion en up est pas assez forte chez moi pour te l’envoyer
Dans mes souvenirs, j’ai toujours bien fait un ‘stop Gladys’ avant tout backup de la DB mais, ce n’est pas impossible que j’ai commis une erreur…
Je suppose que, vu que les données n’étaient pas exploitées, ça ne posait pas de problème que la DB soit corrompue.
Après, j’ai beaucoup cherché pour transférer l’installation sur SSD, j’ai eu une SD corrompue etc. Autant de sources d’erreurs potentielles!
Bref, merci beaucoup d’avoir pris le temps d’y regarder.
Si c’est possible et que ça t’arrange, n’hésite pas à tronquer la DB pour l’alléger, je n’ai pas de données vitales…
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 (juste un extrait car c’est beaucoup plus long), “Aggrégation donnée capteur horaire” :
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
Même souci chez moi. J’ai l’impression que le backup Gladys Plus lock la base et si l’aggrégation se lance en même temps (au démarrage par exemple), j’ai cette erreur.
De plus, j’ai des erreurs de ce genre après quelques minutes pour la partie agrégation
horaire.
J’ai redémarré plusieurs fois le Raspberry Pi mais ça reste bloqué à 52%. Je précise que je suis sur carte SD et pas un SSD
2021-10-28T10:37:51+0200 <info> device.calculateAggregate.js:38 (DeviceManager.calculateAggregate) Calculating aggregates device feature state for interval hourly
2021-10-28T10:37:51+0200 <info> index.js:63 (Server.<anonymous>) Server listening on 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: Exiting child process with 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)
Hello !!
Idem de mon côté, à nouveau les erreurs, de temps en temps, mais pas permanent. Il me semblait que tu avais fait ce qu’il fallait @pierre-gilles, mais j’ai l’impression que ce n’est pas la même erreur :
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: 'UPDATE `t_device_feature` SET `last_monthly_aggregate`=$1,`updated_at`=$2 WHERE `id` = $3'
},
original: [Error: SQLITE_BUSY: database is locked] {
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
}
Ca me rend fou ça, je sais que @lmilcent les avait aussi lors du dev mais j’ai jamais réussi à reproduire… Si tu peux regarder peut-être ce que te renvoie l’API @cicoub13 ?
ça peut-être dû au backup Gladys Plus qui se lance en même temps, je vais essayer de voir pour empêcher l’aggrégation quand le backup tourne.
L’idée c’était aussi d’attendre les premiers retours avant de communiquer dessus, pour l’instant à part toi personne s’est plaint donc c’est plutôt positif 
