existe-t-il quelque chose comme un démon par utilisateur?


11

J'ai besoin d'exécuter certains processus d'arrière-plan qui durent aussi longtemps que je suis connecté avec un certain utilisateur.

Existe-t-il quelque chose comme un démon par utilisateur? Je ne connais que les démons mondiaux qui vivent du démarrage de l'ordinateur jusqu'à l'arrêt (ou le démarrage / arrêt manuel).

pour l'instant j'ai fait un script qui vérifie si le processus existe déjà et crée le processus s'il ne l'est pas. Ce script est ensuite exécuté avec la nohupcommande de my .profile. De cette façon, le processus se lance au démarrage et n'est lancé qu'une seule fois (même avec plusieurs rxvttermes entrants et sortants). Pourtant, il n'est jamais tué après la connexion (ce qui n'est pas un désastre mais il est plus propre de terminer également le processus).

Réponses:


9

systemd permet aux utilisateurs d'exécuter leurs propres instances systemd pour gérer les démons privés.

Si vous avez déjà installé systemd, il vous suffit de lancer systemd --useret de gérer vos services en exécutant systemctl --user. Les services aux utilisateurs seront recherchés dans ~/.config/systemd/user.

Par défaut, systemd tuera les services utilisateur à la déconnexion (comme vous l'avez demandé). Ce comportement peut être modifié en activant la persistance pour un utilisateur avec la loginctl --enable-linger $USERcommande.

Plus d'informations peuvent être trouvées sur la page ArchWiki .


1
Existe-t-il un paramètre pour faire en sorte que la fonction d'activation persiste à partir d'un fichier de configuration au lieu d'une commande bash
CMCDragonkai

4

Le service dbus est précisément destiné à cela ... ok, il peut être utilisé précisément pour cela :-). Le démon dbus par utilisateur est démarré lorsqu'un utilisateur se connecte à un environnement de bureau et se termine lorsque l'utilisateur se déconnecte (voir la page de manuel de dbus-launchet l'option --exit-with-session). Un service dbus peut être démarré avec l'instance dbus ou lorsque l'interface du service est appelée la première fois via dbus. Chaque utilisateur peut avoir ses propres spécifications de services dbus, définies dans un répertoire caché dans la maison des utilisateurs, ou globalement dans /etc. Voir la page d'accueil de dbus sur freedesktop pour beaucoup de documentation et d'implémentation de référence.

Je n'utilise que des distributions basées sur Debian ces jours-ci. Tous ceux-ci ont des scripts dans /etc/X11/Xsession.dlesquels très souvent modifient une chaîne qui à la fin sera évaluée comme la commande qui démarre l'environnement de bureau sélectionné. Il existe un tel script pour dbus, qui ajoute la commande au wrapper dbus dbus-launch. Ce wrapper lance un serveur dbus et au moins sur vanille Debian (et je suis prêt à dire "sur toutes les distributions basées sur Debian") a dbus-launchla possibilité --exit-with-session.

Vous devriez pouvoir encapsuler les processus que vous souhaitez exécuter pendant qu'un utilisateur est connecté à un service dbus et que le dbus IIRC se charge automatiquement de mettre fin à ses services avant de quitter.


2

Si vous utilisez BASH comme shell, vous pouvez essayer de faire une détection dans ~ / .bash_logout et arrêter le processus en cours d'exécution.

Ce que vous cherchez probablement à plus long terme est en interaction (par exemple via D-Bus) avec quelque chose comme ConsoleKit ou de systemd de logind .

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.