structure d'un serveur domotique codage lazarus sur raspberry

[spearman]

Bonjour,
j'ai developpé un serveur domotique sous lazarus (code commun avec appli clients win11 et Android sous Delphi 11).
Le serveur est basé sur une tform qui tourne depuis plusieurs mois sur raspberry pi2 model B.
la tform me permet:
1)d'afficher dans 3 panels distintcs les logs liés :
-echanges session utilisateurs,
-échanges cartes I/O(Vellman k8055,k8090,microteleinfo) en USB
-logs applicatifs
2)d'executer des taches (arret serveur,chargement nouveau site domotique,parametres generaux,reparer data,..) via des tbuttons basiques
Mon probleme est les fuites memoires car le serveur plante apres 6 à 12h (a priori swap saturée process domsrvlazv15 dans commande "top").

Valgrind m'affiche des centaines de fuites liés:
-apparemment au code de gestion de la form
-et bien au code et aux threads applicatifs
Aussi, pour "elaguer", je décide de supprimer le type du serveur pour passer à une simple application console afin de
supprimer déjà les fuites liés à la gestion tform, pour me concentrer sur les fuites applicatives.
Ma question: comment structurer mon serveur pour:
-Exec serveur dans une fenetre console
-Afficher les logs en temps reel dans 3 fenetres consoles disctinctes
-passer des commandes d'exec de taches particulieres
En vous remerciant de votre réponse et conseils.
PS:ci-dessous, extrait commande "top" et extrait exec serveur avec valgrind. Je nai pas encore reussi a inclure une image pour copie ecran form serveur actuel
Bonne journee.

Code : Tout sélectionner

pi@pi1:~ $ top
top - 10:38:41 up 28 min,  1 user,  load average: 0,40, 0,51, 0,54
Tasks: 134 total,   1 running,  85 sleeping,   0 stopped,   1 zombie
%Cpu(s):  3,8 us,  1,8 sy,  0,0 ni, 94,4 id,  0,0 wa,  0,0 hi,  0,1 si,  0,0 st
KiB Mem :   948308 total,   502076 free,   141056 used,   305176 buff/cache
KiB Swap:   102396 total,   102396 free,        0 used.   733656 avail Mem 

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                                             
 2458 pi        20   0   65032  32028  23276 S   7,1  3,4   0:05.93 domsrvlazV15                                                                                        
  434 root      20   0  158640  63832  31168 S   5,2  6,7   1:30.55 Xorg                                                                                                
 1735 pi        20   0   46376  18252  15240 S   4,9  1,9   0:20.48 lxterminal                                                                                          
  420 root      20   0   48968  28556  17424 S   3,9  3,0   1:09.76 vncserver-x11-c                                                                                     
 2434 pi        20   0    8240   3180   2724 R   2,3  0,3   0:01.08 top                                                                                                 
  879 root      20   0   16872  12608  12096 S   1,6  1,3   0:09.61 vncagent                                                                                            
top - 10:39:32 up 29 min,  1 user,  load average: 0,56, 0,53, 0,54
Tasks: 134 total,   2 running,  84 sleeping,   0 stopped,   1 zombie
%Cpu(s):  3,6 us,  2,3 sy,  0,0 ni, 93,5 id,  0,0 wa,  0,0 hi,  0,6 si,  0,0 st
KiB Mem :   948308 total,   502076 free,   141004 used,   305228 buff/cache
KiB Swap:   102396 total,   102396 free,        0 used.   733712 avail Mem 

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                       
 2458 pi        20   0   65032  32028  23276 R   6,9  3,4   0:09.17 domsrvlazV15                                  
  420 root      20   0   48968  28556  17424 S   5,6  3,0   1:12.99 vncserver-x11-c                               
  434 root      20   0  158640  63892  31168 S   4,6  6,7   1:34.87 Xorg                                          
 1735 pi        20   0   46376  18252  15240 S   2,9  1,9   0:22.18 lxterminal                                    
 2434 pi        20   0    8240   3180   2724 R   2,0  0,3   0:02.22 top                                           
  879 root      20   0   16872  12608  12096 S   0,7  1,3   0:10.66 vncagent                                      
   10 root      20   0       0      0      0 I   0,3  0,0   0:01.43 rcu_sched  
        
pi@pi1:~/dev/domsrvcliv15/domsrvlazv15 $ valgrind ./domsrvlaz
==1976== Memcheck, a memory error detector
==1976== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==1976== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==1976== Command: ./domsrvlaz
==1976== 
==1976== Invalid read of size 4
==1976==    at 0x2F138: SYSTEM_$$_FPC_CPUINIT (in /home/pi/dev/domsrvcliv15/domsrvlazv15/domsrvlaz)
==1976==  Address 0x7d9b4dc0 is on thread 1's stack
==1976==  16 bytes below stack pointer
==1976== 
==1976== Invalid read of size 4
==1976==    at 0x2EB44: SYSTEM_$$_FPSIGACTION$LONGINT$PSIGACTIONREC$PSIGACTIONREC$$LONGINT (in /home/pi/dev/domsrvcliv15/domsrvlazv15/domsrvlaz)
==1976==  Address 0x7d9b4d48 is on thread 1's stack
==1976==  16 bytes below stack pointer
==1976== 
==1976== Invalid read of size 4
==1976==    at 0x50CA4: SYSTEM_$$_INSTALLDEFAULTSIGNALHANDLER$LONGINT$SIGACTIONREC (in /home/pi/dev/domsrvcliv15/domsrvlazv15/domsrvlaz)
==1976==  Address 0x7d9b4d88 is on thread 1's stack
==1976==  16 bytes below stack pointer
==1976== 
==1976== Invalid read of size 4
==1976==    at 0x48EE0: SYSTEM_$$_ASSIGN$TEXT$RAWBYTESTRING (in /home/pi/dev/domsrvcliv15/domsrvlazv15/domsrvlaz)
==1976==  Address 0x7d9b4b04 is on thread 1's stack
==1976==  20 bytes below stack pointer
==1976== 
==1976== Invalid read of size 4
==1976==    at 0x2EC58: SYSTEM_$$_FPMMAP$POINTER$LONGWORD$LONGINT$LONGINT$LONGINT$INT64$$POINTER (in /home/pi/dev/domsrvcliv15/domsrvlazv15/domsrvlaz)
==1976==  Address 0x7d9b4ce0 is on thread 1's stack
==1976==  16 bytes below stack pointer
==1976== 
==1976== Invalid read of size 4
==1976==    at 0x5437C: CTHREADS_$$_CALLOCATETHREADVARS (in /home/pi/dev/domsrvcliv15/domsrvlazv15/domsrvlaz)
==1976==  Address 0x7d9b4d2c is on thread 1's stack
==1976==  20 bytes below stack pointer
==1976== 
==1976== Invalid read of size 4
==1976==    at 0x47C88: SYSTEM_$$_INITTHREADVARS$TRELOCATETHREADVARHANDLER (in /home/pi/dev/domsrvcliv15/domsrvlazv15/domsrvlaz)
==1976==  Address 0x7d9b4d84 is on thread 1's stack
==1976==  20 bytes below stack pointer
.......................................
==1800== Invalid read of size 4
==1800==    at 0x271CA8: SYSUTILS_$$_CHANGEFILEEXT$RAWBYTESTRING$RAWBYTESTRING$$RAWBYTESTRING (in /home/pi/dev/domsrvcliv15/domsrvlazv15/domsrvlaz)
==1800==  Address 0x7d8f698c is on thread 1's stack
==1800==  20 bytes below stack pointer
==1800== 
==1800== Invalid read of size 8
==1800==    at 0x4865B38: ??? (in /usr/lib/arm-linux-gnueabihf/libarmmem.so)
==1800==  Address 0x5c0894c is 12 bytes inside a block of size 17 alloc'd
==1800==    at 0x4847568: malloc (vg_replace_malloc.c:299)
==1800==    by 0x4F2DD67: g_malloc (in /lib/arm-linux-gnueabihf/libglib-2.0.so.0.5000.3)
==1800== 
==1800== Invalid read of size 4
==1800==    at 0x3864B4: GTK2INT$_$TGTK2WIDGETSET_$__$$_PASSCMDLINEOPTIONS (in /home/pi/dev/domsrvcliv15/domsrvlazv15/domsrvlaz)
==1800==  Address 0x7d8f6a60 is on thread 1's stack
==1800==  16 bytes below stack pointer
==1800== 
==1800== Invalid read of size 4
==1800==    at 0x386338: GTK2INT$_$TGTK2WIDGETSET_$__$$_GTK2CREATE (in /home/pi/dev/domsrvcliv15/domsrvlazv15/domsrvlaz)
==1800==  Address 0x7d8f6aa0 is on thread 1's stack
==1800==  16 bytes below stack pointer
==1800== 
==1800== Invalid read of size 4
==1800==    at 0x390EFC: GTK2INT$_$TGTK2WIDGETSET_$__$$_PARSERCFILE (in /home/pi/dev/domsrvcliv15/domsrvlazv15/domsrvlaz)
==1800==  Address 0x7d8f6a60 is on thread 1's stack
==1800==  16 bytes below stack pointer
==1800== 
==1800== Invalid read of size 4
==1800==    at 0x38635C: GTK2INT$_$TGTK2WIDGETSET_$__$$_GTK2CREATE (in /home/pi/dev/domsrvcliv15/domsrvlazv15/domsrvlaz)
==1800==  Address 0x7d8f6aa0 is on thread 1's stack
==1800==  16 bytes below stack pointer
==2046== Invalid read of size 4
==2046==    at 0x3EE1F4: CONTROLS$_$TCONTROL_$__$$_CMTEXTCHANGED$TLMESSAGE (in /home/pi/dev/domsrvcliv15/domsrvlazv15/domsrvlaz)
==2046==  Address 0x7dfcb6d0 is on thread 1's stack
==2046==  16 bytes below stack pointer
==2046== 
==2046== Invalid read of size 4
==2046==    at 0x3F801C: CONTROLS$_$TCONTROL_$__$$_REALSETTEXT$TTRANSLATESTRING (in /home/pi/dev/domsrvcliv15/domsrvlazv15/domsrvlaz)
==2046==  Address 0x7dfcb928 is on thread 1's stack
==2046==  16 bytes below stack pointer
==2046== 
==2046== Invalid read of size 4
==2046==    at 0x3E96F8: CONTROLS$_$TWINCONTROL_$__$$_REALSETTEXT$TTRANSLATESTRING (in /home/pi/dev/domsrvcliv15/domsrvlazv15/domsrvlaz)
==2046==  Address 0x7dfcb9e8 is on thread 1's stack
==2046==  16 bytes below stack pointer
==2046== 
==2046== Invalid read of size 4
==2046==    at 0x3F8138: CONTROLS$_$TCONTROL_$__$$_SETTEXT$TTRANSLATESTRING (in /home/pi/dev/domsrvcliv15/domsrvlazv15/domsrvlaz)
==2046==  Address 0x7dfcba30 is on thread 1's stack
==2046==  16 bytes below stack pointer
==2046== 
==2046== Invalid read of size 4
==2046==    at 0x2CC8A8: TYPINFO_$$_SETSTRPROP$TOBJECT$PPROPINFO$ANSISTRING (in /home/pi/dev/domsrvcliv15/domsrvlazv15/domsrvlaz)
==2046==  Address 0x7dfcbc3c is on thread 1's stack
==2046==  20 bytes below stack pointer
==2046== 
==2046== Invalid read of size 4
==2046==    at 0x269AC0: CLASSES$_$TREADER_$__$$_READIDENT$$ANSISTRING (in /home/pi/dev/domsrvcliv15/domsrvlazv15/domsrvlaz)
==2046==  Address 0x7dfcbd90 is on thread 1's stack
==2046==  16 bytes below stack pointer
==2046== 
==2046== Invalid read of size 4
==2046==    at 0x34EFF8: LRESOURCES$_$TLRSOBJECTREADER_$__$$_READIDENT$TVALUETYPE$$ANSISTRING (in /home/pi/dev/domsrvcliv15/domsrvlazv15/domsrvlaz)
==2046==  Address 0x7dfcbd40 is on thread 1's stack
==2046==  16 bytes below stack pointer
==2046== 
==2046== Invalid read of size 4
==2046==    at 0x34F03C: LRESOURCES$_$TLRSOBJECTREADER_$__$$_READIDENT$TVALUETYPE$$ANSISTRING (in /home/pi/dev/domsrvcliv15/domsrvlazv15/domsrvlaz)
==2046==  Address 0x7dfcbd40 is on thread 1's stack
==2046==  16 bytes below stack pointer
==2046== 
==2046== Invalid read of size 4
==2046==    at 0x269AFC: CLASSES$_$TREADER_$__$$_READIDENT$$ANSISTRING (in /home/pi/dev/domsrvcliv15/domsrvlazv15/domsrvlaz)
==2046==  Address 0x7dfcbd90 is on thread 1's stack
==2046==  16 bytes below stack pointer
.................................................
==2147==    at 0x4CC714: GTK2WSFACTORY_$$_REGISTERCUSTOMPANEL$$BOOLEAN (in /home/pi/dev/domsrvcliv15/domsrvlazv15/domsrvlaz)
==2147==  Address 0x7db7be68 is on thread 1's stack
==2147==  16 bytes below stack pointer
==2147== 
==2147== Invalid read of size 4
==2147==    at 0x4BB778: WSEXTCTRLS_$$_REGISTERCUSTOMPANEL (in /home/pi/dev/domsrvcliv15/domsrvlazv15/domsrvlaz)
==2147==  Address 0x7db7bea8 is on thread 1's stack
==2147==  16 bytes below stack pointer
==2147== 
==2147== Invalid read of size 4
==2147==    at 0x4BB78C: WSEXTCTRLS_$$_REGISTERCUSTOMPANEL (in /home/pi/dev/domsrvcliv15/domsrvlazv15/domsrvlaz)
==2147==  Address 0x7db7bea8 is on thread 1's stack
==2147==  16 bytes below stack pointer
==2147== 
==2147== Invalid read of size 4
==2147==    at 0x4BB7A0: WSEXTCTRLS_$$_REGISTERCUSTOMPANEL (in /home/pi/dev/domsrvcliv15/domsrvlazv15/domsrvlaz)
==2147==  Address 0x7db7bea8 is on thread 1's stack
==2147==  16 bytes below stack pointer
==2147== 
==2147== Invalid read of size 4
==2147==    at 0x4BB7B4: WSEXTCTRLS_$$_REGISTERCUSTOMPANEL (in /home/pi/dev/domsrvcliv15/domsrvlazv15/domsrvlaz)
==2147==  Address 0x7db7bea8 is on thread 1's stack
==2147==  16 bytes below stack pointer
==2147== 
==2147== Invalid read of size 4
==2147==    at 0x4BB7C8: WSEXTCTRLS_$$_REGISTERCUSTOMPANEL (in /home/pi/dev/domsrvcliv15/domsrvlazv15/domsrvlaz)
==2147==  Address 0x7db7bea8 is on thread 1's stack
==2147==  16 bytes below stack pointer
==2147== 
==2147== Invalid read of size 4
==2147==    at 0x4BB7DC: WSEXTCTRLS_$$_REGISTERCUSTOMPANEL (in /home/pi/dev/domsrvcliv15/domsrvlazv15/domsrvlaz)
==2147==  Address 0x7db7bea8 is on thread 1's stack
==2147==  16 bytes below stack pointer
==2147== 
==2147== Invalid read of size 4
==2147==    at 0x4BB7F0: WSEXTCTRLS_$$_REGISTERCUSTOMPANEL (in /home/pi/dev/domsrvcliv15/domsrvlazv15/domsrvlaz)
==2147==  Address 0x7db7bea8 is on thread 1's stack
==2147==  16 bytes below stack pointer
==2147== 
==2147== 
==2147== More than 1000 different errors detected.  I'm not reporting any more.
==2147== Final error counts will be inaccurate.  Go fix your program!
==2147== Rerun with --error-limit=no to disable this cutoff.  Note
==2147== that errors may occur in your program without prior warning from
==2147== Valgrind, because errors are no longer being displayed.
==2147== 

[piper]

Bonjour,
La solution la plus simple (si c'est pour du débogage ou une surveillance ponctuelle) serait :
1) que ton code produise 3 fichiers de logs distincts
2) que lorsque tu lances ton exécutable manuellement, tu ouvres plusieurs autres terminaux manuellement
3) sur chacun de ces terminaux (1 parfichier de log à consulter), tu lances une commande manuellement comme ceci :

Code : Tout sélectionner

tail -f monfichierdelog

En effet, la commande tail en linux montre la fin du fichier (quelques lignes, 20 par défaut je crois, on peut changer ça pour 50 avec -n 50) Et l'option -f fait que, l'écran est rafraichit à chaque fois que le contenu du fichier change)

Maintenant, supposons que tu veuilles que ton code automatise ces tâches manuelles :
Il te faudra une application qui tourne sous X : le mode console pure te sera interdit car dans le mode console pur, il ne peut y avoir qu'un seul terminal. Idem à distance sous putty, sauf à écrire une application qui ouvrirait des fenêtres putty avec ouverture de sssion et lancement de la commande "tail"

Bon courage

[destroyedlolo]

Salut,

Il te faudra une application qui tourne sous X : le mode console pure te sera interdit car dans le mode console pur, il ne peut y avoir qu'un seul terminal. Idem à distance sous putty, sauf à écrire une application qui ouvrirait des fenêtres putty avec ouverture de sssion et lancement de la commande "tail"

Ben non, ca marche aussi très bien en mode console pure :

1. soit tu lances plusieurs terminaux virtuels avec la commande screen
2. mais tu peux aussi "spliter" le terminal aussi en utilisant screen ou tmux

Mon ami google m'a dit que j'avais de la chance avec ce lien : https://linuxhint.com/split-linux-terminal/

J'utilise un max screen pour des taches qui prennent des heures ce qui me permet de me déconnecter mais de conserver les résultats. Par contre, je n'utilise pas la #2 car étant exclusivement sous Linux sur mes PC, c'est plus pratique de lancer plusieurs terminaux.
(il n'y a qu'au taf ou j'utilise des windowseries, mais l'utilisation de putty est tellement frustrante )

Aussi, pour "elaguer", je décide de supprimer le type du serveur pour passer à une simple application console afin de
supprimer déjà les fuites liés à la gestion tform, pour me concentrer sur les fuites applicatives.

C'est une bonne approche. Surtout qu'il y a des chances que corrigé une partie te donnera aussi des pistes pour le reste : ca sent fort le manque de destruction d'objets inutilisés.

Ma question: comment structurer mon serveur pour:
-Exec serveur dans une fenetre console

Franchement, sans connaitre ton appli, ca va être difficile de te répondre
Pour la lancer, il suffit généralement de lancer l'exécutable depuis un shell. Si tu te connectes à distance et que l'appli a besoin d'une interface graphique, il faut que le tunnel X soit activé. Je ne suis pas sûr que putty sache le faire (jamais testé). Normalement wsl2 est censé pouvoir le faire ... mais je n'ai JAMAIS réussi à le faire. A nouveau, utiliser une windowserie n'est pas la solution pour bosser.

-passer des commandes d'exec de taches particulieres

Malheureusement, pas de solution toute faite : ca ne dépend que de ton application. Voici 2 pistes que j'utilise sur les miennes :

• utiliser une socket Linux pour passer les commandes.
• pour tous mes démons qui communiquent par MQTT (donc tous ceux de ma domotique), j'ai simplement créé un topic dédié dans lequel j'envoie les commandes.

Dans un cas comme dans l'autre, le problème est de l'intégrer dans l'application, car évidemment, tu ne vas pas tout bloquer en attente de message. Avec une socket, poll() sera ton ami car permet d'être notifié lorsqu'un message arrive. Pour mes applis domotique, par MQTT donc, elles sont toujours multi-threadées donc c'est plus facile : un nouveau thread est créé à l'arrivée de chaque message. Si les commandes doivent interagir avec un autre composant, je passe par une queue de message interne à l'application et les composants concernés regarde si des messages les concernent dans la queue.

Par exemple, lorsqu'une température arrive, ca donne :

• thread crée à l'arrivée d'une valeur
  1. ajoute la valeur dans la collection de valeurs correspondantes qui sert à afficher les courbes
  2. soumet dans la queue la valeur à afficher
  3. soumet l'ordre de retracer la courbe
• dans le thread qui gère l'IHM (séquentiel)
  • Maj du widget de la valeur si la queue contient un ordre le demandant
  • maj du widget de la courbe si la queue contient un ordre le demandant

La queue est intelligente et je peux lui demander de ne pas autoriser les doublons pour un ordre particulier, ce qui évite que l'IHM passe sont temps à se mettre a jour avec des valeurs obsolètes si elle est plus lente que l'arrivée des données (pas de race condition)

Du coup,

• je suis sur de ne perdre aucune donnée vu que c'est le thread slave qui les ajoute dans la collection
• l'IHM affiche toujours les dernières valeur "si elle a le temps" et ne devient donc pas un goulet d'étranglement

Voila, un gros c'est le principe : l'arrivée d'une commande est traitée comme s'il s'agissait d'une donnée.

Esperant que ca te donne des idées.

[spearman]

Hello,
merci pour vos 1ers conseils precieux.
je vais m'ycoller en testant:
-d'abord la plus simple de piper
-et puis selon resultat, la solution Xtiplexeur de lolo sans doute un peu plus compliqué pour moi

Bonne journee, encore merci et a prochainement pour info de conclusion.

[piper]

Ben non, ca marche aussi très bien en mode console pure :

Ben tu m'expliqueras , car google t'as donné un exemple sous X : on est en mode fenêtré là

Quand je parle de mode console pur, c'est vraiment du pure (pas de bureau) :
Donc au mieux, du putty en headless pour avoir plusieurs fenêtres.

[destroyedlolo]

Ben non, ca marche aussi très bien en mode console pure :

Ben tu m'expliqueras , car google t'as donné un exemple sous X : on est en mode fenêtré là

Quand je parle de mode console pur, c'est vraiment du pure (pas de bureau) :

Le fait que l'exemple fournit est sous X n'implique pas que screen est limité à X : ça fonctionne très bien en mode console pure (y compris par la console physique "série"), et c'est même conçu pour ca.

tip du jour : configurer la console pour être en haute résolution (genre fullHD) permet d'avoir plus de place. Normalement, c'est déjà le cas avec les kernel modernes, sinon, c'est un paramètre à changer. Il faut évidemment que les modules modesetting/KMS et DRM soient chargées, à nouveau, ca devrait être le cas.

Donc au mieux, du putty en headless pour avoir plusieurs fenêtres.

Je suis obligé de l'utiliser au taf car on a une DSI poussiéreuse bloquée dans les années 90 alors que 99% de nos clients sont passés sous Linux. Et, la sécurité vendue nous fait passer par des farms "CyberArk" configurée pour que les serveurs des dits clients ne soient accessibles que par Putty.
Franchement, rien que la gestion calamiteuse des configs "TERM" et sa simulation toute personnelle des standards, fait que même l'utilisation par wsl serait plus confortable.

[Artemus24]

Salut à tous.

Vous parlez bien de ceci : screen.
A vrai dire, je ne l'utilise pas car je passe par Putty pour me connecter, même si j'ouvre plusieurs fois le même compte.

Il faudra l'expliquer l'utilité d'ouvrir plusieurs fenêtres dans une même console ?

Cordialement.
Artemus24.
@+

[destroyedlolo]

Salut,

Il faudra l'expliquer l'utilité d'ouvrir plusieurs fenêtres dans une même console ?

Je ne répondais qu'à

Il te faudra une application qui tourne sous X : le mode console pure te sera interdit car dans le mode console pur,

, ensuite, chacun y trouvera l'utilité qu'il veut.
En l'occurrent, ca a du me servir qu'une fois sur le Banana de ma Domotique dont la console est relié sur un PC qui me sert de backup et qui n'a pas d'interface graphique.

Maintenant, comme je le disais, screen permet de détacher un process dans un terminal "virtuel" ce qui permet de pouvoir continuer à interagir avec lui ET de voir se qu'il sort ... mais si on s'est déconnecté de la machine. Et ca, j'en use et abuse.
Par exemple, sûr un autre Banana qui me sert de dashboard pour ma domotique qui tourne H24 et où biensur je ne suis pas toujour connecté. Contrairement à un "nohup", comme je le disais, je peux continuer a lui envoyé des ordres si nécessaire juste en me relogant sur la machine et en réattachant le terminal virtuel.