Pour les gouroux de Linux !!

[PierreG]

Bonsoir à tous..   Ma question s'adresse au savant luxien.    

Contexte :

J'ai deux imprimantes, une Ender 3 et une CR10 (ben ouais, rien de nouveau sous le soleil, c'est écris dans mon profil), chacune étant pilotée par un Pi 4, avec Octoprint !  Sur chacun de ces Octoprint, j'ai installé Spool Manager (j'adore ce plugin pour gérer mes bobines de filament).  Mais voilà, j'aimerais bien que chacun des plugin utilise la même BD, afin que le suivi des bobines se fasse, peu importe quelle imprimante j'utilise.

Mon premier test, a été de déporter vers un autre Pi (qui gère Plex Media et sert de NAS) ma BD (spoolmanager.db).    Le répertoire qui accueille la BD est accessible en lecture, écriture et création.    J'ai modifié mon fstab (/etc/fstab) pour associer le répertoire distant au répertoire local (normalement où est située la BD).

proc            /proc           proc    defaults          0       0
PARTUUID=6e3066b4-01  /boot           vfat    defaults          0       2
PARTUUID=6e3066b4-02  /               ext4    defaults,noatime  0       1

//192.168.1.110/Autre/Octopi/spoolmanager       /home/pi/.octoprint/data/SpoolManager   cifs    credentials=/root/.smbcredentials,iocharset=utf8,file_mode=0777,dir_mode=0777,de$
# a swapfile is not a swap partition, no line here
#   use  dphys-swapfile swap[on|off]  for that

//192.168.1.110 est le Pi sur lequel se trouve la BD.     Le fichier smbcredentials contient le username et le passwors pour accéder au Pi.

Voilà le problème:  Octoprint arrives à lire la BD.  J'ai donc toute mon inventaire affichée. Mais lorsque l'impression est terminée, Octoprint ne peut mettre la BD à jour avec la quantitée de filament utilisée.  je joins la partie du Log.

Ca semble etre une question de verrouillage de la BD.   Je précise, que l'autre Pi n'accede pas à cette BD pour l'instant (elle ne peut donc pas etre verrouillée par un accès tiers).

Des idées ??

Merci à l'avance !!

octoprint.log

[Savate]

@PierreG,

Manifestement SpoolManager en mode local utilise SQLLite qui ne fonctionne pas très bien avec du NFS (problème de verrous ...)

Dans le code du plugin (et dans les discussions) il semblerait que l'on puisse utiliser postgresssql ou mysql comme Base de donnée en passant le plugin en mode 'pas local'.

Par contre je pense qu'il faut installer postgresssql ou mysql sur le nas (ça c'est facile) et migrer les données (ça ce n'est pas forcément simple) sur la nouvelle base.

En gros ce n'est pas gagné, mais ça semble faisable  

Modifié (le) Février 11, 2022 par Savate

[PPAC]

Pour moi, c'est une histoire d'accès concurrent a une base de données SQLite ( https://www.google.com/search?q=sqlite+accès+concurrent )

A l'origine SQLite n'était, il me semble, pas conçue pour être utilisé par plusieurs thread et donc non plus par plusieurs processus.

Des niveau de verrou on était introduit (selon la version de SQLite ) pour permettre cela mais c'est, il me semble, bien moins fin qu’avec d'autre système de gestion de base de données MySQL par exemple.)

Donc la solution de Savate semble la plus adapté pour garantir que tu ne te retrouve pas avec un fichier/ une base de données incohérente.

Ou alors il faut étudier le/les programme qui utilise le fichier pour déterminer si en les modifiant ( pour chaque requête SQL, changer le mode d’accès ( cette notion de verrou/protection qui sera mis en place)  pour trouver un meilleur compromis ... en gros si un processus lis la base, un autre a t'il le droit d'y écrire ou doit t'il attendre que le 1er est finis de lire ( et donc le 1er doit t'il de temps en temps lâcher le verrou / arrêter la lecture ... ))

[PierreG]

@Savate  @PPAC     Merci beaucoup....

Je sais quoi chercher maintenant....     

[Yo']

Salut @PierreG,

 

Avec Blender, j'ai eu des problèmes pour accéder à un stockage sur le réseau, que je n'avais pas avant upgrade de l'OS.

J'ai résolu le problème en lançant blender en mode administrateur (sudo ./blender).

 

ça commence à devenir compliqué la gestion des droits sous linux.

Il faut les bons attributs dans fstab du client et les bons attributs dans le smb.conf du serveur.

 

[fran6p]

Le développeur du greffon «spool manager» travaille sur la gestion de la BDD via une «vraie» base de données Mariadb/Postgresql mais ce n'est pas encore totalement fonctionnel : roadmap

Son autre greffon que j'ai longtemps utilisé avant de basculer sur SpoolMngr, Filament manager permettait lui une gestion via base de données (Postgresql). Mais je préfère SpoolManager lui dédié à la gestion des bobines

Une explication concernant le problème des BDD locales «partagées» : https://github.com/OllisGit/OctoPrint-SpoolManager/issues/5

[PierreG]

Il y a 3 heures, fran6p a dit :

Mais je préfère SpoolManager

Moi aussi je préfère SpoolManager...   Il est plus complet je trouve !!!

Merci pour les liens....     je vais surveiller ca !!