Page 1 sur 2
Question de newbie : interuptions
Posté : lun. 16 mai 2016 16:41
par vague nerd
Bonjour.
J'intercepte le contrôle+C comme suit :
Code : Tout sélectionner
def end_read(signal,frame):
global continue_reading
print "Ctrl+C captured, ending read."
continue_reading = False
GPIO.cleanup()
signal.signal(signal.SIGINT, end_read)
while continue_reading:
#do something really important
Cependant, quand je pers ma connexion ssh (timeout par exemple), la boucle conditionnée par "continue_reading" s'arrête (while continue_reading:), mais le GPIO.cleanup() n'est pas appelé.
Je ne comprend pas ce qui se passe (pas de trace du process avec une autre conneion ssh). J'imagine que end_read() n'est pas appelé, mais pourquoi la boucle s'arrête-elle ?
Des idées ? Est-ce plutôt une question linux ?
Est-il possible de programmer une autre interruption correspondant à "session closed" ?
Cdt.
Re: Question de newbie : interuptions
Posté : mar. 17 mai 2016 08:23
par Manfraid
Salut,
si tu a lancer le script en ssh et que tu pert la connexion c'est normal que le reste du code n'est pas appeler, et je ne pense pas que l'on puisse capturer le signal
ce que je peu te conseillé c'est d'utilisé screen ou tmux (une préférence pour le 2ème) pour lancer tes scripts, comme ça en cas de perte de connexion ton script fonctionne toujours
Re: Question de newbie : interuptions
Posté : mar. 17 mai 2016 10:17
par vague nerd
si tu a lancer le script en ssh et que tu pert la connexion c'est normal que le reste du code n'est pas appeler
Je comprend bien que le code répondant à l'interception du crtl+c ne soit pas appelé. Par contre, je suis surpris que le script en cours d'exécution (boucle disons sans fin) soit tué...
Tout process (non demon) lancé par ssh est tué à la perte de la session ?
(Hé ben, mes souvenirs de linux sont bien vieux...)
Cdt.
Re: Question de newbie : interuptions
Posté : mar. 17 mai 2016 10:40
par Manfraid
oui voila c'est exactement ça, c'est pour cela que je lance toujours un tmux sur mes machine que je prend en ssh comme ça même si perte de connexion les script/commande en cours reste active, c'est très pratique par exemple si tu fait une compilation sur le rasp sans avoir peur de perdre le ssh
Re: Question de newbie : interuptions
Posté : mar. 17 mai 2016 12:14
par vague nerd
Ok, merci.
J'imagine qu'a terme, je lancerai le script comme ça :
en demon, quoi.
Mais du coup, faut que je trouve une meilleur condition pour arrêter ma boucle.
Là, c'est un boolean qui passe à faux sur interception du ctrl+c.
Cdt.
Re: Question de newbie : interuptions
Posté : mar. 17 mai 2016 12:53
par Manfraid
même avec cette commande le script s’arrêtera a la perte du ssh
Re: Question de newbie : interuptions
Posté : mar. 17 mai 2016 13:08
par vague nerd
même avec cette commande le script s’arrêtera a la perte du ssh
Ha ben m***e, j'étais sûr de mon coup, là...
Cdt.
Re: Question de newbie : interuptions
Posté : mar. 17 mai 2016 13:10
par Manfraid
je me doute, en fait quand tu met le "&" en fin de ligne tu met jsute ton script en background mais dépendant du shell ouvert en ssh voila pourquoi celui-ci va se couper une fois le ssh fermer
pour ça je te conseille vraiment d'essayer tmux, car une foit détaché de la session toutes tes actions en cours le resterons
Re: Question de newbie : interuptions
Posté : mar. 17 mai 2016 13:12
par vague nerd
même avec cette commande le script s’arrêtera a la perte du ssh
Ha ben m***e, j'étais sûr de mon coup, là...
Ben je viens d'essayer : le script ne s'est pas arrêté...
EDIT :
le script est toujour là (et fonctionne, c'est pas un zombi).
Cdt.
Re: Question de newbie : interuptions
Posté : mar. 17 mai 2016 13:41
par vague nerd
Dans un premier pseudo terminal (pts/0) :
Code : Tout sélectionner
pi@automate ~/rfid-rc522/MFRC522-python $ who
pi pts/0 2016-05-17 03:35 (ip.ip.ip.ip)
pi@automate ~/rfid-rc522/MFRC522-python $ ps aux | grep python
root 2284 0.4 2.7 24492 10504 ? S 03:34 1:57 /usr/bin/python -O /usr/share/wicd/daemon/wicd-daemon.py
root 2325 0.2 2.8 15020 10892 ? S 03:34 1:09 /usr/bin/python -O /usr/share/wicd/daemon/monitor.py
pi 8570 0.0 0.4 3584 1856 pts/0 S+ 11:35 0:00 grep --color=auto python
Dans un second pseudo terminal (pts/1) :
Code : Tout sélectionner
pi@automate ~/rfid-rc522/MFRC522-python $ who
pi pts/0 2016-05-17 03:35 (ip.ip.ip.ip)
pi pts/1 2016-05-17 11:36 (ip.ip.ip.ip)
pi@automate ~/rfid-rc522/MFRC522-python $ who m i
pi pts/1 2016-05-17 11:36 (ip.ip.ip.ip)
pi@automate ~/rfid-rc522/MFRC522-python $ sudo python readWithLight.py &
[1] 8627
pi@automate ~/rfid-rc522/MFRC522-python $ Press Ctrl-C to stop.
Fermeture du second terminal et retour sur le premier :
Code : Tout sélectionner
pi@automate ~/rfid-rc522/MFRC522-python $ who
pi pts/0 2016-05-17 03:35 (ip.ip.ip.ip)
pi@automate ~/rfid-rc522/MFRC522-python $ ps aux | grep python
root 2284 0.4 2.7 24492 10504 ? S 03:34 1:59 /usr/bin/python -O /usr/share/wicd/daemon/wicd-daemon.py
root 2325 0.2 2.8 15020 10892 ? S 03:34 1:10 /usr/bin/python -O /usr/share/wicd/daemon/monitor.py
root 8627 0.0 0.7 4608 2668 ? S 11:37 0:00 sudo python readWithLight.py
root 8628 47.9 1.5 8656 5932 ? R 11:37 1:03 python readWithLight.py
pi 8658 0.0 0.4 3584 1748 pts/0 S+ 11:39 0:00 grep --color=auto python
pi@automate ~/rfid-rc522/MFRC522-python $
Le process 8627 est bien rattaché à "?" et pas à pts/1.
EDIT : pas besoin de modifier la condition d'arrêt de ma boucle (un boolean mis à faux sur interception du ctrl+c).
va bien (typiquement, ctrl+c envoie SIGINT !).
Cdt.