Closed Vikingfr closed 2 years ago
Je viens de tester sur une installation vierge. Même constat, il y a une répartition entre tous les téléphones disponibles. Je suis sur raspisms 3.5.2 / php 7.4 / python 3.9.2
Comment faire pour qu'un SMS ne soit envoyé que depuis le téléphone de l'utilisateur qui crée le SMS ?
Je vais jeter un oeil, serait-il possible de faire un export de la BDD et de me l'envoyer (en remplaçant les données privées par de la data random evidemment), pareil pour les fichiers de config gammu, que je puisse reproduire au plus proche.
voici les exports raspisms.zip
Pour l'instant je n'arrive pas à reproduire le soucis. Je ne comprend même pas comment cela peut arriver sachant que le sender transmet l'info sur une queue unique à chaque téléphone, et que chaque téléphone n'est censé lire que sa propre queue...
Serait-il possible d'avoir le fichier de log et de m'indiquer le numéro de ligne ou l'erreur survient.
PS : je suis notamment intéressé par les lignes "Closing queue" après un passage d'erreur d'envoi, parceque la seule explication que je vois ça serait deux identifiants de queue identiques, même si je n'arrive pas à imaginer comment ça serait possible.
je regarde demain pour sortir le log complet, mais j'ai posté plus haut la partie qui montre le soucis. Et j'ai reproduit ce soir le problème sur une installation neuve. Raspberry 3 / raspberry OS Lite (32b) Bullseye / raspisms 3.5.2 / php 7.4 / python 3.9.2 / mariaDB 10.3. Installation via le tuto sur https://raspisms.fr/download/ . Création des fichiers de config gammu. Login avec le compte d'exemple, modif du compte pour change l'email et le mot de passe et création d'un 1er tel. Création du second utilisateur (non admin), 'incarnation' de cet utilisateur, création du second tel, retour à l'utilisateur admin, puis création d'un sms envoyé à 4 fois le même numéro de tel.
Voici les dernières lignes du log... Elle se répètent . Le numéro de la file est en effet identique pour les deux téléphones
[2022-09-28T10:15:17.076211+02:00] RaspiSMS Daemon Phone 10.INFO: Closing queue : 2147483647 [] []
[2022-09-28T10:15:17.076457+02:00] RaspiSMS Daemon Phone 10.INFO: Stopping Phone daemon with pid 32185 [] []
[2022-09-28T10:15:17.937941+02:00] RaspiSMS Daemon Phone 10.INFO: Starting Phone daemon with pid 32357 [] []
[2022-09-28T10:20:17.626149+02:00] RaspiSMS Daemon Phone 9.INFO: Closing queue : 2147483647 [] []
[2022-09-28T10:20:17.626583+02:00] RaspiSMS Daemon Phone 9.INFO: Stopping Phone daemon with pid 32355 [] []
[2022-09-28T10:20:17.711395+02:00] RaspiSMS Daemon Phone 10.CRITICAL: Error reading MSG SEND Queue, error code : 22 [] []
[2022-09-28T10:20:18.213395+02:00] RaspiSMS Daemon Phone 10.CRITICAL: Error reading MSG SEND Queue, error code : 22 [] []
[2022-09-28T10:20:18.577044+02:00] RaspiSMS Daemon Phone 9.INFO: Starting Phone daemon with pid 32516 [] []
[2022-09-28T10:20:18.715111+02:00] RaspiSMS Daemon Phone 10.CRITICAL: Error reading MSG SEND Queue, error code : 22 [] []
[2022-09-28T10:20:18.715586+02:00] RaspiSMS Daemon Phone 10.INFO: Closing queue : 2147483647 [] []
[2022-09-28T10:20:18.715828+02:00] RaspiSMS Daemon Phone 10.INFO: Stopping Phone daemon with pid 32357 [] []
[2022-09-28T10:20:19.595580+02:00] RaspiSMS Daemon Phone 10.INFO: Starting Phone daemon with pid 32518 [] []
[2022-09-28T10:25:19.466369+02:00] RaspiSMS Daemon Phone 9.INFO: Closing queue : 2147483647 [] []
[2022-09-28T10:25:19.466795+02:00] RaspiSMS Daemon Phone 9.INFO: Stopping Phone daemon with pid 32516 [] []
[2022-09-28T10:25:19.886445+02:00] RaspiSMS Daemon Phone 10.CRITICAL: Error reading MSG SEND Queue, error code : 22 [] []
[2022-09-28T10:25:20.185133+02:00] RaspiSMS Daemon Phone 9.INFO: Starting Phone daemon with pid 32688 [] []
[2022-09-28T10:25:20.388221+02:00] RaspiSMS Daemon Phone 10.CRITICAL: Error reading MSG SEND Queue, error code : 22 [] []
[2022-09-28T10:25:20.437622+02:00] RaspiSMS Daemon Phone 10.INFO: Closing queue : 2147483647 [] []
[2022-09-28T10:25:20.438004+02:00] RaspiSMS Daemon Phone 10.INFO: Stopping Phone daemon with pid 32518 [] []
[2022-09-28T10:25:21.210906+02:00] RaspiSMS Daemon Phone 10.INFO: Starting Phone daemon with pid 32690 [] []
[2022-09-28T10:30:20.969006+02:00] RaspiSMS Daemon Phone 9.INFO: Closing queue : 2147483647 [] []
[2022-09-28T10:30:20.969622+02:00] RaspiSMS Daemon Phone 9.INFO: Stopping Phone daemon with pid 32688 [] []
[2022-09-28T10:30:21.163475+02:00] RaspiSMS Daemon Phone 10.CRITICAL: Error reading MSG SEND Queue, error code : 22 [] []
[2022-09-28T10:30:21.665065+02:00] RaspiSMS Daemon Phone 10.CRITICAL: Error reading MSG SEND Queue, error code : 22 [] []
[2022-09-28T10:30:21.815697+02:00] RaspiSMS Daemon Phone 9.INFO: Starting Phone daemon with pid 406 [] []
[2022-09-28T10:30:22.167224+02:00] RaspiSMS Daemon Phone 10.CRITICAL: Error reading MSG SEND Queue, error code : 22 [] []
[2022-09-28T10:30:22.167839+02:00] RaspiSMS Daemon Phone 10.INFO: Closing queue : 2147483647 [] []
[2022-09-28T10:30:22.168161+02:00] RaspiSMS Daemon Phone 10.INFO: Stopping Phone daemon with pid 32690 [] []
[2022-09-28T10:30:22.834078+02:00] RaspiSMS Daemon Phone 10.INFO: Starting Phone daemon with pid 408 [] []
[2022-09-28T10:35:22.804482+02:00] RaspiSMS Daemon Phone 9.INFO: Closing queue : 2147483647 [] []
[2022-09-28T10:35:22.805045+02:00] RaspiSMS Daemon Phone 9.INFO: Stopping Phone daemon with pid 406 [] []
[2022-09-28T10:35:23.059383+02:00] RaspiSMS Daemon Phone 10.CRITICAL: Error reading MSG SEND Queue, error code : 22 [] []
[2022-09-28T10:35:23.560981+02:00] RaspiSMS Daemon Phone 10.CRITICAL: Error reading MSG SEND Queue, error code : 22 [] []
[2022-09-28T10:35:23.561447+02:00] RaspiSMS Daemon Phone 10.INFO: Closing queue : 2147483647 [] []
[2022-09-28T10:35:23.561691+02:00] RaspiSMS Daemon Phone 10.INFO: Stopping Phone daemon with pid 408 [] []
[2022-09-28T10:35:24.188634+02:00] RaspiSMS Daemon Phone 9.INFO: Starting Phone daemon with pid 674 [] []
[2022-09-28T10:35:24.529428+02:00] RaspiSMS Daemon Phone 10.INFO: Starting Phone daemon with pid 676 [] []
`
UPDATE: le soucis viens de cette fonction: $this->msg_queue_id = (int) (QUEUE_ID_PHONE_PREFIX . $this->phone['id']); dans daemon/phone.php Je ne sais pas trop ce que devrait contenir QUEUE_ID_PHONE_PREFIX mais chez moi, c'est un grand nombre et du coup, en concaténant l'ID du téléphone, on dépasse 2147483647 qui est le max d'un int en 32 bits.
EDIT: du coup mon soucis est résolu, car en cherchant la déclaration du prefix, j'ai vu qu'il est dans le fichier de config env.php. Je l'ai donc fixé à une valeur simple et faible (100) ainsi on ne dépasse pas la capacité d'un int.
Ahhhh, voilà pourquoi j'arrivais pas à reproduire, j'ai test sur un ordi en 64 bits !
La solution d'utiliser une valeur fixe ne me semble pas la bonne car cela risque de créer des conflits avec d'autres logiciels qui feraient la même chose. Les queues ne sont fiables à l'échelle d'un système que si tout le monde fait l'effort d'utiliser ftok plutôt que de choisir son ID soit même, sinon on obtient des conflits de clé.
En revanche puisque nous avons le controle totale sur le int décrivant le type de message on peut utiliser celui-ci pour faire l'adressage. Le système utilisera donc une seule queue pour tous les téléphones et fera la séparation entre téléphones par type de message.
Je viens de pousser l'update 3.5.4 qui corrige le problème, il faut penser à mettre à jour le fichier env.php pour inclure les modifications apportées à env.php.dist si cela n'est pas fait automatiquement lors de l'update, et redémarrer le daemon systemd raspisms.
Pouvez-vous vérifier que tout fonctionne correctement avec cette modification ?
c'est fonctionnel ! merci pour ce correctif
Super, merci d'avoir remonté le soucis !
bonjour, j'ai une installation sur raspberry, avec 2 clés USB (et donc 2 sim). Un modem sur USB0, l'autre sur USB1. Chaque modem dispose d'un fichier de config gammu. Chaque modem fonctionne et je parviens, via gammu à envoyer de l'une ou l'autre des lignes en spécifiant l'un ou l'autre des fichiers de config. Bref, ça marche bien. Coté RaspiSMS, j'ai deux utilisateurs, le 1er est admin et utilise un modem (celui sur USB0), raspisms le déclare comme phone_id 5. Le second utilisateur dispose du second modem, déclaré avec son fichier de config et que raspisms déclare comme phone_id 8. Dans l'interface Web, l'utlisateur 1 ne voit dans le menu téléphone que son phone_id 5, et l'autre ne voit que le phone_id 8. Tout semble logique.
Pourtant, lorsque un utilisateur envoi des sms, que ce soit depuis l'interface web ou via l'api, de temps en temps, le SMS part depuis la mauvaise ligne. Le problème existe aussi bien avec l'utilisateur 1 qui parfois se retrouve à envoyer via la ligne 2 que l'utilisateur 2 qui envoi via le phone 5.
Je note que cela se produit, à priori, lors d''envois en masse. En envois ponctuels, ça ne semble pas se produire. A priori, lorsque la clé USB est en cours d'envoi, Raspisms bascule sur l'autre ligne. J'ai l'impression qu'il y a une répartition de charge automatique, ce qui n'est pas le fonctionnement que j'attends.
Comment bloquer utlisateur1>phone 5 et utilisateur2>phone 8 ?
Un bout de log pour voir le problème (1 sms créé par l'utilisateur 1, vers 4 destinataires. le daemon 8 envoi les sms du phone_id 5 alors que c'est le travail du daemon 5 ):