Comment déterminer le nom de processus d'une application?

Voici la situation:

En travaillant sur (la prochaine version de) un éditeur de liste rapide Unity, je voudrais ajouter un moyen fiable de "redémarrer" les icônes du lanceur. Pour ce faire, je dois supprimer l'icône (modification des paramètres) et la replacer à la même position. Jusqu'à présent, aucun problème. Cependant, si l'application en question est en cours d'exécution, l'utilisateur risque de perdre des données, car l'application se fermera lorsque son icône sera supprimée du lanceur. J'ai besoin d'un moyen fiable pour trouver le nom du processus d'une application, pour permettre à l'éditeur de vérifier dans la liste des processus en cours d'exécution si l'application est en cours d'exécution et d'envoyer un message d'avertissement à l'utilisateur que l'icône ne peut pas être redémarrée si l'application est fonctionnement.

Ce que j'ai fait jusqu'à présent, c'est que l'éditeur regarde dans le fichier de bureau, pour lire la commande, également lire la commande, supprimée de la section du répertoire, et en outre rechercher dans les scripts distants possibles auxquels la commande de fichier de bureau pourrait se référer, à la recherche de chaînes commençant avec "./"

Bien que la méthode semble bien fonctionner avec toutes les applications sur lesquelles je l'ai testée, j'ai le sentiment qu'il doit y avoir un moyen plus simple de couvrir le problème de manière "tout en un" ...

Y a-t-il?

Des suggestions pour attraper des situations plus exceptionnelles sont également les bienvenues!

launcher process .desktop

— Jacob Vlijm
source

Pourquoi une application se ferme-t-elle lorsque son icône est supprimée du lanceur? Quitter une application qui n'est pas épinglée au lanceur entraîne la suppression de son icône, mais pourquoi la suppression de l'icône quitterait-elle l'application?

— Eliah Kagan

@Eliah: arrêter n'est probablement pas la bonne expression, l'application plante tout simplement ....

— Jacob Vlijm

@JacobVlijm donc, c'est un droit spécifique à Unity? L'unité a déjà un mécanisme pour cela. Quelles sont les exigences? Seulement pour connaître le nom du processus comme dans la sortie pset xprop?

— Sergiy Kolodyazhnyy

@Serg Le nom du processus, "calculé" à partir du .desktopfichier, qui n'est pas nécessairement WM_CLASS. WM_CLASS peut être défini à partir de l'application.

— Jacob Vlijm

@JacobVlijm ah, supposons donc que vous ayez commencé firefox.desktop, il lance Firefox avec PID 1234, mais a changé WM_CLASSpour quelque chose comme 'Totally Not Firefox'. Le .desktopfichier ne change cependant pas. Vous souhaitez obtenir le nom attaché au PID 1234 indépendamment de WM_CLASS. Je pense que je vois exactement ce qui doit être fait. Mais vous n'avez pas répondu à ma première question - est-ce OK si ce n'est que pour Unity?

— Sergiy Kolodyazhnyy

Réponses:

Il n'y a aucun moyen de résoudre ce problème dans le cas général. Quel que soit le mécanisme que vous proposez, je pense qu'il sera toujours possible d'écrire un processus qui vous échappera, à moins que vous ne modifiiez la façon dont les processus sont lancés en premier afin de les suivre de cette façon.

Upstart doit faire face exactement au même problème pour suivre si les démons sont toujours en cours d'exécution, et les auteurs de travaux upstart doivent spécifier les détails (le nombre de fourches) pour upstart à suivre. Étant donné que les arrivants ne peuvent pas le gérer sans aide, je ne pense pas que vous le puissiez non plus. Et le débutant contrôle même la façon dont les processus sont lancés, ce que je ne pense pas que vous soyez ici.

Je pense que le mieux que vous puissiez faire est ce que vous faites déjà. Regarder /proc/<pid>/statet /proc/<pid>/cmdlineest un moyen raisonnablement général, mais ne capturera toujours pas tous les cas. La pgrepcommande enveloppe cela. Si vous ne l'utilisez pas déjà pgrep, jetez un œil à la page de manuel de pgrep pour les options sur lesquelles vous pouvez comparer .

Cela dit, je ne suis pas convaincu que vous ayez vraiment besoin de le faire en premier lieu. Si vous ne pouvez pas suivre le processus, je ne vois pas comment Unity pourrait le faire non plus. Une meilleure approche ne serait-elle pas d'éliminer les plantages d'application en premier lieu? J'examinerais en détail les raisons pour lesquelles vos applications se bloquent (c'est sûrement un bug quelque part?), Plutôt que d'essayer de le contourner comme vous l'avez décrit. Je me demande si cela n'affecte que les applications Unity qui appellent Unity pour des fonctionnalités supplémentaires via DBus ?

— Robie Basak
source

Merci pour votre réponse complète! J'examinerai les détails (en particulier votre dernier paragraphe), et proposerai probablement l'icône "redémarrer" comme option "expérimentale" si je ne trouve pas une soulution à 100%. La bonne nouvelle est qu'entre-temps, je n'ai trouvé aucune exception sur la méthode que j'ai utilisée. Encore merci!

— Jacob Vlijm

La xpropcommande (suivie par alt-tab pour la fenêtre d'application appropriée, puis cliquez une fois dans la fenêtre) semble faire l'affaire pour moi.

— el_gallo_azul
source

WM_CLASScorrespond souvent au nom du processus, mais certainement pas toujours. Définir (coder) une fenêtre, je peux lui en donner autant que WM_CLASSje veux. J'ai même fait moi-même pour créer des fenêtres, exécutées à partir de différents processus, regroupées dans une icône de lanceur.

— Jacob Vlijm

Oh. C'est une honte. Cela valait la peine que j'ajoute l'avertissement "... semble faire l'affaire pour moi" à la fin. C'est une fonction que je m'attendais vraiment à intégrer dans le système d'exploitation, et je pensais que je ne savais tout simplement pas comment le faire. À tout le moins, je m'attendrais à ce que les informations contenues dans «À propos».

— el_gallo_azul