Comment un service de session DB= Python DBus sait-il que l'utilisateur se déconnecte?
Supposons que vous disposez d'un service DBus sur le bus de session (le bus par utilisateur). Votre service peut démarrer via un /etc/xdg/autostart/* fichier, ou il pourrait démarrer la première fois qu'une application essaie d'utiliser votre nom de service connu. Quoi qu'il en soit, disons que le bus de session DBus est le processus qui démarre votre service.
Et puis l'utilisateur se déconnecte. Alors que se passe-t-il? DBus envoie-t-il des signaux exploitables SIG <foo> à votre service, ou est-il étroit à SIGKILL? Existe-t-il un autre moyen de savoir que l'utilisateur se déconnecte? Fondamentalement, j'ai quelques actions de nettoyage que je dois exécuter, ce qui inclut la suppression des sous-processus commencés par subprocess.Popen et multiprocessing.
Maintenant, avant de dire, "Popen et multiprocessing sont mauvais, ne les utilisez pas", dans mon expérience actuelle, je ne suis pas en les utilisant. J'essaie juste de comprendre comment un service Python DBus peut se connecter à quelque chose qui lui permet d'exécuter des actions de nettoyage, quelle que soit l'architecture globale.
Aucun conseil? Des exemples? Notez que mon exemple s'exécutera dans un GObject.MainLoop et utilise Python3 sur Ubuntu Precise (ou Quantal).
Vous pouvez soit faire quelque chose comme ceci:
bus = dbus.SessionBus()
bus.call_on_disconnection(your_method_to_do_stuff)
Ou vous pouvez vous connecter au signal NameLost sur le org.FreeDesktop.DBus interface. Le premier ne vous laisse pas passer d'arguments supplémentaires, et votre méthode ne peut prendre que l'objet de connexion de bus lui-même comme argument. Ce dernier est un peu plus compliqué, mais ne semble pas non plus permettre de passer d'autres arguments de votre propre chef, et vous êtes limité à prendre les arguments que le signal lui-même envoie, qui dans ce cas est une chaîne du bus de messages nommez votre processus précédemment détenu.
D'un autre côté, si votre processus reste en place après cela, vous devriez théoriquement obtenir un SIGKILL à un moment donné également.
Si vous vous souciez uniquement de l'exécution sous GNOME et Unity, vous devriez pouvoir vous connecter à interface DBus du gestionnaire de sessions . Cela vous donne non seulement un message "sur le point de vous déconnecter" via les signaux QueryEndSession et EndSession, mais vous permet également de bloquer la déconnexion/l'arrêt jusqu'à ce que vous ayez fini de nettoyer si vous le souhaitez, via EndSessionResponse.
Je ne sais pas dans quelle mesure KDE implémente une interface compatible.