Lancer et arrêter un programme externe

Bonjour,

Dans le cadre de mes études j'essaye de monter un serveur TCP en C, un client TCP/serveur WebSocket en Node.JS et un client final en HTML.

Pièce jointe 540221

J'ai déjà une partie qui tourne sur un Raspberry.
Le Server en C est se contente de renvoyer l'heure quand il reçoit un message. Il est lancer dans un thread et pour l'instant le serveur est bloquant, je dois regarder du coté de select() pour le rendre non bloquant.

Dans un premier temps j'aimerai implémenter le lancement et l'arrêt automatique du client/serveur en Node.JS directement avec mon code en C.
J'ai trouvé la commande system() mais je ne comprends pas comment récupérer le PID de la commande exécutée.
De même en cas d'interception de signal il faudrait tuer le client/serveur en Node.JS.

Le code est ici : https://github.com/a-tortevois/tcp-s...-client-server

Merci pour votre aide.

Bonjour

Citation:

---

Envoyé par dark_vidor

Dans un premier temps j'aimerai implémenter le lancement et l'arrêt automatique du client/serveur en Node.JS directement avec mon code en C.
J'ai trouvé la commande system() mais je ne comprends pas comment récupérer le PID de la commande exécutée.

---

Mauvaise idée. La commande system() est une commande en mode "tire et oublie". Elle te permet effectivement de lancer un programme externe mais le lance sans te donner aucune possibilité de contrôle. Et en plus elle est bloquante, c'est à dire qu'elle attend la fin de la commande exécutée pour te rendre la main et tout ce que tu peux espérer récupérer c'est l'état du programme exécuté quand il se termine.

Il te faut t'orienter vers le couple fork() + exec(). C'est le stantard dans ce type de programmation. Le process se duplique avec fork(). La partie père récupère le pid du fils (ce que tu veux) et la partie fils lance le programme choisi au travers d'une des primitives exec(). En effet il y en a 6 différentes selon ton besoin: les 3 premières de la famille "l" qui reçoivent les paramètres sous forme de liste et où on trouve execl() (la base), execlp() (utilise le PATH pour chercher la commande à exécuter), execle() (tu peux lui passer un environnement) ; et les 3 autres de la famille "v" qui reçoivent les paramètres sous forme de tableau et où on trouve 3 fonctions similaires execv(), execvp() et execve(). Et là, à la différence de system(), le père a le choix d'attendre la fin du fils (donc d'attendre la fin de la commande) via un wait() ou pas.

Tu pourrais être tenté par le couple fork() + system() dans le fils mais là aussi ce serait une mauvaise idée car à la différence de exec() qui remplace le process courant par celui du programme à exécuter, system() génère son propre fils pour exécuter le programme. Tu aurais donc ton propre fils (que tu maitrises) ayant généré son propre fils (que tu ne maitrises pas) et sur lequel tu n'aurais aucune action (et donc surtout pas possibilité d'arrêter le programme exécuté).

Accessoirement ta solution de thread qui renvoie l'heure aurait peut-être avantage à basculer elle-aussi plutôt sur un fork() avec le fils généré qui se contente là de renvoyer lui-même l'heure demandée (donc là pas besoin de exec()).

Citation:

---

Envoyé par dark_vidor

De même en cas d'interception de signal il faudrait tuer le client/serveur en Node.JS.

---

Pas de souci: avec le couple fork() + exec() le père connait le pid de ton node/js, il peut lui envoyer un kill() à la demande.

Merci pour cette réponse détaillée et constructive.
Je vais étudier le fork() et le exec() de près dès demain.

Citation:

---

Envoyé par Sve@r

Bonjour
Accessoirement ta solution de thread qui renvoie l'heure aurait peut-être avantage à basculer elle-aussi plutôt sur un fork() avec le fils généré qui se contente là de renvoyer lui-même l'heure demandée (donc là pas besoin de exec()).

---

In fine non je ne pense pas, car ça ne sera pas l'heure qui va être renvoyé mais des variables du programme principal (qui se résume dans l'exemple en un usleep(), mais en vrai j'ai du code ;)), l'idée est de faire un push des variables quand il y a une modification (d’où implémentation d'un serveur non bloquant), de les envoyer via la socket en TCP et des récupérer sur des web socket pour afficher sur une IHM (un site web local) et envoyer pouvoir envoyer sur un cloud ou un API.

Je suis partie comme cela pour ne pas à avoir à gérer plusieurs clients dans le code en C et ne pas avoir à gérer du web socket, pour que le "serveur" en C reste simple et relativement souple à maintenir.
L'idée c'est de déléguer la gestions des "clients externes" à mon "client TCP-serveur-Node.JS" (puisque mon IHM sera basé sur React ou Angular, donc j'aurai déjà du Node.JS) qui sert de "passerelle" avec le code en C et les différents services qui pourraient venir s'interfacer avec.
C'est n'est pas cette brique qui est la plus complexe à construire et ça fera très bien le "job" sans surcharger le RPi.
(Et puisque parce que je suis faignant et que j'avais pas envie de refaire un truc en C alors que en Node.JS c'est déjà très bien fait ^^, mais ça faut pas le dire :mouarf:)

J'ai rajouté le code d'un serveur non bloquant, il me reste quelques bugs à corriger...
Quand je rentre dans le "timeout", les messages ne sont plus détecté :(

Restant à l'écoute des suggestions et remarques.

Citation:

---

Envoyé par dark_vidor

Je vais étudier le fork() et le exec() de près dès demain.

---

Petit exemple de démo

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

#include <stdio.h> #include <unistd.h> #include <errno.h> #include <string.h> #include <sys/types.h> #include <sys/wait.h>   void fils() { printf("Je suis le fils (%d) - Mon père est %d\n", getpid(), getppid()); sleep(10); // Attente (pour démo) execl("/bin/ls", "/bin/ls", "-l", "-a", NULL); printf("test\n"); // Ne sera jamais exécuté, le execl() a remplacé ce code par celui du "ls" }   int main(int argc, char *argv[]) { pid_t pid; switch(pid=fork()) { case -1: // Erreur fprintf(stderr, "Erreur fork() - %s\n", strerror(errno)); break; case 0: //Fils fils(); break; default: // Père printf("je suis le père (%d) - pid fils: %d\n" , getpid(), pid); // Attente fin fils waitpid(pid, NULL, 0); printf("Fils terminé\n"); } }

---

Citation:

---

Envoyé par dark_vidor

In fine non je ne pense pas, car ça ne sera pas l'heure qui va être renvoyé mais des variables du programme principal (qui se résume dans l'exemple en un usleep(), mais en vrai j'ai du code )

---

Hum... le souci c'est que je ne sais pas du tout comment Linux gère le mélange fork+thread. Ce sont tous deux des outils dédiés à programmer en multitâche mais l'un est natif Unix et l'autre provient du monde zindow et je ne suis pas certain qu'on puisse les mélanger. Enfin tu vas jouer à l'explorateur dans ce domaine...:aie:

Citation:

---

Envoyé par dark_vidor

(Et puisque parce que je suis faignant et que j'avais pas envie de refaire un truc en C alors que en Node.JS c'est déjà très bien fait ^^, mais ça faut pas le dire :mouarf:)

---

Très bonne philosophie. Inutile de réinventer ce qu'on peut récupérer ;)

Merci pour l'exemple. :ccool:

J'ai pensé à une autre solution ce matin : Mon programme en C est lancé par un service au démarrage, rien ne m’empêche (en théorie) de lancer un second service qui attends que le port soit en écoute pour lancer le "client TCP-serveur-Node.JS", et de coup la gestion du contrôle et des redémarrage des services est déléguée à Linux :|

Je vais creuser ça ...

Code:

---

1 2 3 4 5

#!/bin/bash echo "Wait for port 1998 is open" while netstat -lnt | awk '$4 ~ /:1998$/ {exit 1}'; do sleep 10; done echo "Port 1998 is now open" node wss.js

---

Il semblerait qu'il y ai un problème en passant par les services, c'est bizarre :

Citation:

---

root@raspberrypi:~# systemctl status myapp.service
● myapp.service - MyApp Service
Loaded: loaded (/etc/systemd/system/myapp.service; enabled; vendor preset: enabled)
Active: failed (Result: timeout) since Sun 2020-02-23 16:16:08 UTC; 11s ago
Process: 589 ExecStart=/usr/bin/myapp (code=exited, status=1/FAILURE)
Process: 590 ExecStartPost=/usr/bin/wss (code=killed, signal=TERM)
Main PID: 589 (code=exited, status=1/FAILURE)
Tasks: 0 (limit: 2200)
Memory: 2.3M
CGroup: /system.slice/myapp.service

févr. 23 16:16:08 raspberrypi myapp[589]: Message send to the client: It's 16:15:05
févr. 23 16:16:08 raspberrypi myapp[589]: Message received from the client: test
févr. 23 16:16:08 raspberrypi myapp[589]: Message send to the client: It's 16:15:17
févr. 23 16:16:08 raspberrypi myapp[589]: Message send to the client: It's 16:15:47
févr. 23 16:16:08 raspberrypi myapp[589]: Catch SIGTERM
févr. 23 16:16:08 raspberrypi myapp[589]: server_stop()
févr. 23 16:16:08 raspberrypi myapp[589]: Thread `server` stop
févr. 23 16:16:08 raspberrypi systemd[1]: myapp.service: Main process exited, code=exited, status=1/FAILURE
févr. 23 16:16:08 raspberrypi systemd[1]: myapp.service: Failed with result 'timeout'.
févr. 23 16:16:08 raspberrypi systemd[1]: Failed to start MyApp Service.

---

----- Edit

Il manquait un & à la fin de la commande, du coup le script bash déclenchait le timeout

Code:

---

node wss.js &

---

Citation:

---

Hum... le souci c'est que je ne sais pas du tout comment Linux gère le mélange fork+thread.

---

man fork :

Citation:

---

Le processus fils est créé avec un unique thread --- celui qui a appelé fork(). L'espace d'adressage virtuel complet du parent est copié dans le fils. Cela inclut les états des mutexes, les variables de condition et autres objets pthreads ; l'utilisation de pthread_atfork(3) peut être préférable afin de gérer les problèmes qui pourraient être provoqués.

---

Citation:

---

Envoyé par chrtophe

man fork :

---

Ça me conforte dans l'idée de passer par le service qui lance un script bash ...

J'ai mis à jour mon script, ça me parait bon après quelques tests