Je dois écrire un programme qui doit être conscient d'un autre exemple d'exécution sur cette machine et de communiquer avec elle, puis mourir. Je veux savoir s'il y a une façon canonique de le faire sous Linux.
Ma première pensée était d'écrire un fichier contenant le PID du processus et recherchez ce fichier chaque fois que le programme exécute, mais où est le "droit" et le nom de ce fichier? Y a-t-il un meilleur ou plus "correct"?
Ensuite, je dois communiquer, affirmant que l'utilisateur a essayé de l'exécuter, mais comme il y a un autre exemple, il va remettre le travail et sortir. J'ai pensé à simplement envoyer un signal, comme Sigusr1, mais cela ne me permettrait pas d'envoyer plus d'informations, comme l'affichage X11 d'où l'utilisateur a exécuté le deuxième processus. Comment envoyer ces informations?
Le programme est lié contre GTK, une solution qui utilise la glib est ok.
6 Réponses :
Mettre le PID dans un fichier est un moyen courant de y parvenir. Pour les démons ("programmes système"), le lieu commun à mettre un tel fichier est L'envoi d'informations à l'instance "Master" est la plus couramment réalisée à l'aide des prises de domaine UNIX, également appelées prises locales. Avec une prise, vous n'aurez plus besoin d'un fichier PID (si personne n'écoute sur la prise, le processus sait qu'il est maître). /var/run/program.pid . Pour les programmes utilisateur, placez le fichier PID masqué dans le HomeDir de l'utilisateur (si le programme dispose également de fichiers de configuration, puis mettez les fichiers de configuration et le fichier PID dans un sous-directeur de la DIR).
Un fichier PID seul est à peu près inutile. Si l'application se bloque, il peut ne pas supprimer son fichier PID afin qu'il doit être supprimé manuellement. Une meilleure option consiste à verrouiller le fichier PID, car le système d'exploitation libère toujours la serrure lorsque le processus se termine d'une manière ou d'une autre. Vous ne pouvez pas voir ce verrou cependant en faisant ls -la . Une prise de domaine UNIX seul suffit.
@Maxim: faux. Unlink (...) supprime le fichier après la fermeture du fichier. Donc fd = ouvert (chemin, ...); Dislink (chemin); est l'astuce habituelle d'avoir un fichier temporaire.
@Alexandru: presque à droite, vous avez manqué le fait que nous discutions des fichiers PID, pas des fichiers temporaires. Le fichier PID ne doit pas être supprimé avant la fin de l'application.
Sockets de domaine UNIX. Demandez à la première instance Créer un dans un répertoire temporaire, alors d'autres instances communiquent avec elle via cela.
Peut-être pas un répertoire temporaire - / var / exécuté est assez courant pour les fichiers de socket.
Écrire un fichier PID est une approche commune. Cochez la bibliothèque pidfile (3) .
Il y a beaucoup de façons de faire cela. La façon dont vous avez proposé (à l'aide d'un fichier contenant le PID) est valide et est utilisée par de nombreuses applications.
Quelques fois le fichier de configuration de l'application contient le chemin du fichier PID, d'autres fois qu'un chemin codé est utilisé. Habituellement, l'application placez le fichier PID dans n'aurait pas de suggestion générale sur où mettre votre fichier PID, choisissez simplement l'endroit que vous préférez. / tmp , dans / var (si ils fonctionnent avec UID 0) ou dans leur annuaire local ( ~ / .application / < / code>).
Linux a-t-il l'équivalent d'un mutex ou d'un sémaphore nommé? Donc, vous pouvez vérifier si c'est «verrouillé», puis avertissez l'utilisateur qu'ils en ont déjà un et fermez-le?
Cela a-t-il un sens de ce lien? http://www.linuxquesquestions.org/Questions/ Programmation-9 / Named-MuTex-in-Linux-296816 /
Semaphores nommés semble fonctionner comme un moyen de résoudre le problème des multiples cas, bien qu'il s'agisse d'un plutôt peu orthodoxe.
Bien que cela fonctionnerait, il est plutôt moche dans la mesure où l'espace de noms est partagé entre tous les processus de la machine, et tout autre utilisateur pourrait dous votre programme en ouvrant un sémaphore nommé avec le même nom. Personnellement, je n'utiliserais jamais Posix nommé Semaphores / mémoire partagée sans noms randomisés et communiquerai le nom à travers un autre canal sûr, pas inscriptible, sauf par un processus avec les principaux privilèges.
Vous pouvez certainement utiliser une prise de domaine UNIX; Je pense que la plupart des applications (qui n'utilisent pas de système de niveau supérieur comme DCOP ou DBU) les utilisent.
Si vous êtes heureux, vous pouvez utiliser un "espace de noms abstrait" UNIX; Ce sont plutôt bien parce qu'ils n'ont pas besoin d'exister dans le système de fichiers.
Si votre programme est orienté sur l'utilisateur, il devrait probablement être au courant des multi -iques; Un utilisateur ne doit pas être en mesure de déclencher un comportement dans la copie de l'application d'un autre utilisateur, et la sécurité doit être en place pour garantir que les utilisateurs ne peuvent pas se poser facilement (exemple: la copie de la programmation de l'utilisateur est-elle en train d'arrêter l'utilisateur B du départ?).
Je pense que garder les fichiers à l'intérieur de la maison de l'utilisateur empêchera d'interférer avec un autre utilisateur.
Ouais c'est une implémentation possible.