Je n'ai pas beaucoup exploré ton script mais l'erreur classique quand on fait ce genre de chose, c'est de reconnaître, en plus du processus examiné, le grep lui même. Ex :
$ ps | grep toto
obs 1005 ./toto
obs 1006 grep toto
Et selon la planification des tâches, le grep peut ou non apparaître dans la liste des processus.
Le meilleur moyen, à mon goût, d'éviter le lancement multiple de plusieurs applications est l'utilisation de sockets Unix que l'on peut interroger. Ainsi, on reste dans la philosophie du système de fichier, ça marche sur les archis distribuées et les serveurs, on n'exploite pas un port réseau (hérésie), et l'espace de nommage des sockets est virtuellement sans limite (contrairement aux ids des IPC SysV par exemple). En outre, si le fichier traîne dans le /var/run ou ailleurs, mais qu'il n'y a plus de processus à l'autre bout, on le sait très vite en l'interrogeant.
Maintenant, je conçois qu'exploiter des sockets en shell ...
# Voir grep
Posté par Obsidian . En réponse au message système de verrou ( 1 = 2, sisi avec linux ). Évalué à 2.
$ ps | grep toto
obs 1005 ./toto
obs 1006 grep toto
Et selon la planification des tâches, le grep peut ou non apparaître dans la liste des processus.
Le meilleur moyen, à mon goût, d'éviter le lancement multiple de plusieurs applications est l'utilisation de sockets Unix que l'on peut interroger. Ainsi, on reste dans la philosophie du système de fichier, ça marche sur les archis distribuées et les serveurs, on n'exploite pas un port réseau (hérésie), et l'espace de nommage des sockets est virtuellement sans limite (contrairement aux ids des IPC SysV par exemple). En outre, si le fichier traîne dans le /var/run ou ailleurs, mais qu'il n'y a plus de processus à l'autre bout, on le sait très vite en l'interrogeant.
Maintenant, je conçois qu'exploiter des sockets en shell ...