J'ai créé un script dans /etc/init.d/ qui doit exécuter plusieurs autres scripts d'autres utilisateurs (privilégiés non root) à partir de leurs répertoires personnels, comme s'ils les avaient démarrés.
Je lance ces scripts avec: sudo -b -u <username> <script_of_a_particular_user>
Et il fonctionne. Mais pour chaque script utilisateur qui continue de fonctionner (par exemple, un chien de garde), je vois un processus sudo parent correspondant, toujours vivant et fonctionnant en tant que root. Cela crée un gâchis dans la liste des processus actifs.
Ma question est donc la suivante: comment lancer (bifurquer) un autre script à partir d'un script bash existant en tant qu'autre utilisateur et le laisser en tant que processus orphelin (autonome)?
Explication plus détaillée:
j'essaie essentiellement de fournir aux autres utilisateurs de la machine un moyen d'exécuter des choses au démarrage ou à l'arrêt du système en exécutant des fichiers exécutables trouvés dans les sous-répertoires respectifs trouvés dans leur répertoire personnel, nommés .startUp et .shutDown. Comme je n'ai trouvé aucun autre moyen de le faire, j'ai écrit mon script bash qui fait exactement cela et je l'ai configuré en tant que script de service (en suivant l'exemple squelette) dans /etc/init.d/ donc quand il est exécuté avec l'argument de démarrage, il lance tout à partir des répertoires .startUp et lorsqu'il est exécuté avec l'argument d'arrêt, il lance tout à partir des répertoires .shutDown de tous les utilisateurs comme eux.
Sinon, je suis également intéressé si j'aurais pu utiliser une solution existante pour résoudre ce problème.
MISE À JOUR
J'ai regardé un peu et j'ai trouvé cette question:
/unix/22478/detach-a-daemon-using-sudo
Réponse acceptée là-bas, à utiliser:, sudo -u user sh -c "daemon & disown %1"fonctionne pour moi. Mais j'ai aussi essayé sans renier% 1 et c'est pareil. Voici donc ce qui fonctionne pour moi comme je m'y attendais:
sudo -u <username> bash -c "<script_of_a_particular_user> &"Ma question supplémentaire est maintenant, pourquoi ça marche sans renier? dois-je quand même quitter l' appel désavoué , quel que soit le cas, pour un cas particulier potentiel?
MISE À JOUR 2
Apparemment, cela fonctionne aussi:
su <username> -c "<script_of_a_particular_user> &"Y a-t-il une différence entre cet appel et l'appel sudo? Je sais que c'est potentiellement une toute autre question. Mais puisque je trouve moi-même les réponses ici, peut-être pour le bien de ce sujet, quelqu'un pourrait clarifier cela ici.
MISE À JOUR 3
Ces deux méthodes avec su ou sudo produisent maintenant un nouveau processus startpar (processus unique qui s'exécute en tant que root) après avoir démarré la machine. Visible dans la liste des processus comme:
startpar -f -- <name_of_my_init.d_script>Pourquoi ce processus est-il engendré? Évidemment, je fais quelque chose de mal car aucun autre script init.d n'a ce processus en cours d'exécution.
MISE À JOUR 4
Le problème avec startpar est résolu. J'ai commencé une autre question pour cela:
processus startpar laissé suspendu lors du démarrage des processus à partir de rc.local ou init.d
Et une autre question pour discuter davantage des mécanismes de lancement pour les utilisateurs non privilégiés:
Fournir aux utilisateurs normaux (non root) des capacités d'initialisation et d'arrêt automatique
Vous pouvez utiliser le démon start-stop- out de init.d avec l'
--useroption.la source
Je n'ai pas entièrement testé cela, mais je pense que quelque chose comme:
au démarrage puis
lors de l'arrêt.
La gestion du script .shutDown pourrait être effectuée par quelque chose comme le démarrage, mais vous ne pouvez pas être sûr que les scripts se terminent car l'arrêt devrait de toute façon se produire :-)
devrait faire l'affaire, vous devriez peut-être ajouter une redirection d'entrée, mais vous devrez alors vous soucier du remplissage des fichiers journaux.
la source
Avez-vous essayé d'utiliser
su?-cindique à su d'exécuter la commande, et le dernier paramètre est l'utilisateur pour l'exécuter en tant que.la source