Les processus reçoivent signaux d'autres processus ou du noyau comme un avertissement ou une demande de changement d'état. Les processus récepteurs peuvent bloc , ignorer ou attraper signaux, sauf SIGKILL qui fait ce que son nom indique. Un processus reçoit SIGHUP (signal de raccrochage) lorsque son terminal de contrôle (virtuel ou pseudo) se déconnecte ou que son processus de contrôle (qui est généralement un shell) se termine. Cité dans adb shell source :
Les PTY envoient automatiquement SIGHUP au processus côté esclave lorsque le côté maître du PTY se ferme.
* Voir Terminaux et shells sur Android pour plus de détails sur les PTYs
Le processus peut alors traiter le signal pour continuer son exécution ou est simplement tué par le noyau.
nohup fait tourner un processus (généralement en arrière-plan) en ignorant simplement les éléments suivants SIGHUP même si la borne de commande se ferme. De plus, si les FD 0 , 1 y 2 du processus sont attachés au terminal, nohup redirige vers STDIN de /dev/null y STDOUT / STDERR a nohup.out archivo.
La fonction intégrée d'Android /system/bin/nohup a une mauvaise mise en œuvre comme beaucoup d'autres applets de toybox . Il remplace STDIN avec rien et laisse STDERR attaché à la borne. Ainsi, tous les outils de ligne de commande de l'interpréteur de commandes qui sont liés à l'environnement de travail de l'utilisateur. system_server se comportent de manière inattendue en raison de l'absence de FD 0 .
La solution consiste à utiliser nohup par exemple, à partir de busybox ou de do :
nohup tether.sh </dev/null &
Ou sans nohup :
tether.sh </dev/null &>/sdcard/usb.log &
Afin d'être sûr qu'un programme ignore SIGHUP , ajouter trap '' 1 au script au-dessus du programme à exécuter. Mais ce n'est pas nécessaire avec le MirBSD Korn Shell par défaut d'Android ( /system/bin/sh ) qui n'envoie pas SIGHUP à tous les travaux (processus enfants) de la même session, c'est-à-dire attachés au même terminal. Ainsi, nohup ou trap n'est pas essentiellement nécessaire, que le shell sorte ou soit tué.
Ensuite, mksh ne se détache pas complètement du ou des terminaux car en plus de STDIN/OUT/ERR il s'attache à /dev/tty directement ( réf. ) . Donc détacher les FDs 0/1/2 ne suffit pas. Il existe cependant un mode démon qui détache complètement la commande du terminal :
/system/bin/sh -T- tether.sh
Aussi mksh débloque tous les signaux bien que cela ne soit pas pertinent ici.
bash permet une meilleure gestion des tâches ; l'utilisateur peut configurer avec huponexit si oui ou non il faut toujours envoyer SIGHUP à tous les emplois à la sortie ( réf. ) . La fonction intégrée de Bash disown peut être utilisée pour exclure des travaux de la réception de signaux.
Pour maintenir l'exécution du script au premier plan, un multiplexeur comme tmux ou screen peut être utilisé. C'est ce que je fais, en particulier avec su les binaires des solutions d'enracinement qui ne se détachent pas (en raison de l'implémentation limitée des pseudo-terminaux), lorsqu'un programme est exécuté en arrière-plan. Voir cette question pour les détails.
RELATION : Comment lancer un exécutable au démarrage et le maintenir en fonctionnement ?
