Arrêter un script Python lancé dans rc.local

[Bud Spencer]

T’en fais pas pour la susceptibilité et le saut d’humeur. On a tous nos moments où on est tout chafouin.

La réponse à ta question ‘arreter un script …’, si on regarde bien, domi qui était le premier à t’avoir répondu t’avait donné la solution, tout le reste n’était que de la discussion technique sur des points de détails sans intérêt pour toi (du moins dans l’immédiat …).

Pourquoi un ctrl+c ne fonctionne pas ? Facile : Quand tu lances un programme depuis une commande rc.local, par defaut, c’est l’utilisateur root qui l’exécute au démarrage. Donc tu vois bien les lignes ton programme défiler à l’écran, mais ça ne te donne pas pour autant les droits root sur ce que tu tapes au clavier. C’est pour ça (entre autre) que tu pourras faire autant de ctrl+c que tu veux, ton programme ne s’arrêtera jamais. Là aussi, la réponse de domi t’avais donnée ‘une bonne info’ puisque qu’il avait précisé que la commande ps qu’il t’avait donnée affichait non seulement le pid mais aussi l’user qui avait lancé le process. Pour t’en convaincre, tu pourras essayer de taper ta commande kill sans mettre sudo devant, ça ne marchera pas.

[dyox]

Est-ce que le script python a besoin d'être lancé avec les droits root ?

Si la réponse est non, ne peut-il pas lancé son script à chaque reboot avec cron ? Son script devrait avoir les droits de l'utilisateur courant, non ?
Et donc le ctrl+C devrait fonctionner.

En tout cas,merci à tout les participants, j'ai appris pleins de choses !

[spourre]

Ce n'est pas un problème de droit.
Zeb l'a très bien expliqué (dès la page 1), c'est un problème de lancement en tâche de fond (le fameux &) .
Soit on veut une recette miracle, soit on essaye de comprendre. J'ai déjà insisté sur la philosophie et la cohérence d'UNIX (et donc de Linux, pour les autres OS que je connais moins bien, je ne sais pas).
Dans UNIX, tout est fichier (et vice-versa). Le terminal d’affichage (pas obligatoirement un écran), le clavier, tout est fichier.
Un programme UNIX, par défaut, ouvre 3 fichiers (en plus de ceux déclarés dans le programme):
- Entrée standard (clavier par exemple)
- Sortie standard (écran par exemple)
- Erreur standard (écran par exemple).

Le terminal (écran/clavier) physique est attaché au programme lancé, dans un shell, à partir de ce terminal.
Envoyer le programme en tache de fond revient à le détacher. C"est comme si il n'était plus connecté (en vrai, c'est un peu plus compliqué et met en œuvre un programme spécifique de gestion du terminal.).

Ne pouvant plus accéder au clavier, le programme peut encore recevoir des signaux (bien décrits par Zeb). Les signaux sont un sous-ensemble des Inter Process Communication (IPC) et la primitive système pour envoyer un signal s’appelle (malheureusement) kill.

Sylvain

[Bud Spencer]

Aucune objection sur ce que tu écris Syvain ni sur que qu’a écrit Zeb. Comme le po n’avait visiblement pas tout saisie, j’ai trouvé plus simple de lui expliquer que ce n’est pas parce que son programme lance par root défile à l’écran (je ne parle pas encore de le mettre en tache de fond) que cela lui donnait les même droit au clavier. Les problèmes de redirection des entrée/sortie sont dans le ‘entre autre’.

On peut très bien interagir au clavier avec un programme console lancé par rc.local, mais pour ça, il faudrait déjà que l’user qui lance le script soit auto-loggué avant de démarrer le script. J’avais fait ça avec les anciennes versions de PI pour faire des bornes vidéo de promos qui tournaient en boucle dans des magasins. L’user était aulogger puis un script lancé par rc.local montait une clé usb et lancait la video (omxplayer) qui se trouvait dessus. Un ctrl+c arrêtait la video et démarrait une procédure de shutdown.

Le tout est de savoir ce qu’on veut faire exactement. Est-ce que l’on veut un programme qui tourne en tache de fond (appelons ca un service) avec qui on dialoguera via des signaux, des sockets ou des named-pipe ou un programme qui démarre, qui occupe la console et avec lequel on veut pouvoir interagir au clavier ? Les 2 cas sont possible mais l’approche n’est pas du tout la même. J'avais déjà un peu répondu à ca :

...C’est juste un problème de programme mal conçu et mal démarré …

Pour répondre a dyox, tu peux désigner un utilisateur précis autre que root dans une cmd rc.local, mais dans ce cas la commande doit être lancé avec sudo. (je nais jamais essayé avec un user non sudo, mais ca me semble quasi évident que ce n'est pas possible. Je laisse le soin a d'autre de confirmer ou pas)

[spourre]

Aucune objection sur ce que tu écris Syvain ni sur que qu’a écrit Zeb. Comme le po n’avait visiblement pas tout saisie, j’ai trouvé plus simple de lui expliquer que ce n’est pas parce que son programme lance par root défile à l’écran (je ne parle pas encore de le mettre en tache de fond) que cela lui donnait les même droit au clavier. Les problèmes de redirection des entrée/sortie sont dans le ‘entre autre’.
...

J'ose même pas lui parler de l'option nohup (no hang up) qui peut accompagner l'envoi en tache de fond
Un petit kill pour le fun (sans risque):

Code : Tout sélectionner

$ kill $$

Sylvain

[destroyedlolo]

Est-ce que le script python a besoin d'être lancé avec les droits root ?

Ca dépend uniquement de ce qu'il fait, pas de sa méthode de lancement.

Si la réponse est non, ne peut-il pas lancé son script à chaque reboot avec cron ?

Hormis s'il utilise un cron antédiluvien, oui : tous les démons cron récents ont un @reboot, @startup, @boot ou équivalent.

Son script devrait avoir les droits de l'utilisateur courant, non ?

Non, soit ceux de root s'il est lancé par rc.local, soit par l'utilisateur défini dans le cron si ... cron. A moins d'utiliser su.

Et donc le ctrl+C devrait fonctionner.

Comme je l'ai dis, uniquement si le signal lui est directement envoyé ou par son parent (terminal).

[Bud Spencer]

J'ose même pas lui parler de l'option nohup ...

Pas besoin Sylvain. S’il prend la peine de se documenter un tout petit peu sur l’exécution d’un programme en tache de fond sous linux, il tombera forcement dessus. Est-ce dont il a besoin ? … ça, Il ni à que lui qui le sait.

[spourre]

....
Pas besoin Sylvain. S’il prend la peine de se documenter un tout petit peu sur l’exécution d’un programme en tache de fond sous linux, il tombera forcement dessus. Est-ce dont il a besoin ? … ça, Il ni à que lui qui le sait.

Sur le coup, je te trouve bien optimiste
Quand je vois qu'il est inscrit depuis décembre 2014, ce n'est donc plus un débutant.
Quand je constate que sur 7 messages (dont la présentation) en plus de 2 ans 1/2, AUCUN n'est un message d'aide à plus débutant que lui.
Quand je constate que ses 7 messages sont TOUS des demandes d'aides
Quand je vois sa réaction quand, tout en étant dans le sujet, on ose creuser au delà de sa simple demande et lui donner à réfléchir au lieu de lui mâcher le travail.

Pour moi, c'est clairement un CONsommateur ressemblant trait pour trait, à celui dont j'ai fait le portrait dans un autre fil. Il prend le forum pour une hotline à son usage exclusif, trépigne s'il n'a pas une réponse immédiate et n'apporte rien en retour

EOT sur ce fil.

Sylvain

[Manfraid]

Merci de rester sur le sujet même si je comprend votre point de vue

[zeb]

Pour répondre a dyox, tu peux désigner un utilisateur précis autre que root dans une cmd rc.local, mais dans ce cas la commande doit être lancé avec sudo. (je nais jamais essayé avec un user non sudo, mais ca me semble quasi évident que ce n'est pas possible. Je laisse le soin a d'autre de confirmer ou pas)

J'infirme ! Et destroyedlolo aussi, en donnant la bonne commande (su), mais c'est noyé dans le reste de ses messages :

Non, soit ceux de root s'il est lancé par rc.local, soit par l'utilisateur défini dans le cron si ... cron. A moins d'utiliser su.

------------

[..]tout en étant dans le sujet, on ose creuser au delà de [la] simple demande et [..] donner à réfléchir[..]
EOT sur ce fil.

Sylvain, arrête de faire ta tête de cochon !
Les sujets n'appartiennent pas à ceux qui les initient et tout ce qui va dans le sens de partager de bonnes pratiques et de bonnes connaissances est positif. Quand bien même l'auteur du premier message paraîtrait CON, SOT ou MATEUR ! La question et les réponses sont publiques, pour que cela rende service au plus grand nombre.

Creusons, discutons, digressons, recentrons, débattons, échangeons, enseignons et apprenons, quelque soit le sujet.

Reviens Spourre