Comment exécuter un processus de longue durée sur un événement Udev?

Je veux exécuter une connexion ppp lorsque mon modem USB est connecté, j'utilise donc cette udevrègle:

ACTION=="add", SUBSYSTEM=="tty", ATTRS{idVendor}=="16d8",\
    RUN+="/usr/local/bin/newPPP.sh $env{DEVNAME}"

(Mon modem apparaît en /devtant que ttyACM0)

newPPP.sh:

#!/bin/bash
/usr/bin/pon prov $1 >/dev/null 2>&1 &

Problème:

L' udevévénement se déclenche et newPPP.sh est en cours d'exécution, mais le newPPP.shprocessus est tué après ~ 4-5 secondes. pppn'a pas le temps de se connecter (son délai d'attente est de 10 secondes pour la connexion par ligne commutée).

Comment puis-je exécuter un processus de longue durée, qui ne sera pas tué?

J'ai essayé d'utiliser nohup, mais cela n'a pas fonctionné non plus.

Système: Arch Linux

Mise à jour

J'ai trouvé une solution ici , grâce à maxschlepzig .

J'utilise at nowpour exécuter mon travail indépendamment du processus udev.

Mais la seule question reste sans réponse: pourquoi fonctionne nohupet &ne fonctionne pas?

Si vous exécutez une distribution décente avec le support de systemd, le moyen le plus simple et le plus sûr techniquement est d'utiliser une unité de périphérique .

De cette façon, systemd contrôlera pleinement le script de longue durée et pourra même terminer correctement le processus une fois que le périphérique sera arrêté / supprimé - le détachement du processus signifie que vous abandonnez le contrôle total de l'état du processus et son histoire.

En plus de cela, vous pourrez inspecter l'état de l'appareil et de son service attaché en exécutant systemctl status my-ppp-thing.device.

Voir également cet article de blog pour plus d'exemples et de détails.

De nos jours, udev utilise des groupes de contrôle pour rechercher-n-détruire les tâches générées. Une solution consiste à utiliser "at now" ou "batch". Une autre solution consiste à faire un double fork et à "déplacer" le processus vers un autre groupe de contrôle. Ceci est un exemple de code python (un code similaire peut être écrit dans n'importe quelle langue):

os.closerange(0, 65535)  # just in case
pid = os.fork()
if not pid:
  pid = os.fork()  # fork again so the child would adopted by init
  if not pid:
    # relocate this process to another cgroup
    with open("/sys/fs/cgroup/cpu/tasks", "a+") as fd:
      fd.write(str(os.getpid()))
    sleep(3)  # defer execution by XX seconds
    # YOUR CODE GOES HERE
sleep(0.1)  # get forked process chance to change cgroup

La sortie de débogage peut être envoyée, par exemple, à syslog.

Shell a la capacité d'exécuter des commandes en arrière-plan:

(

lots of code

) &

Les commandes regroupées par les accolades avec esperluette après elles seront exécutées de manière asynchrone dans un sous-shell. Je l'utilise pour me connecter automatiquement lorsqu'un modem USB est inséré et commuté. Cela prend environ 20 secondes et fonctionne bien sous udev.

Je l'ai fait fonctionner avec setsid. Ma partie RUN de la règle udev:

RUN+="/bin/bash script.sh"

puis dans le script:

#!/bin/bash
if [ "$1" != "fo_real" ]; then
  /usr/bin/setsid $(/usr/bin/dirname $0)/$(/usr/bin/basename $0) fo_real &
  exit
fi

Rest of script is here....

Le premier appel au script renvoie avec l'état de sortie 0, mais le deuxième appel au script continue de fonctionner avec PPID = 1.

Probablement parce que son processus parent est terminé et que le signal de terminaison se propage à ses enfants, qui ne le bloquent pas (et dans le cas où SIGKILLils ne le peuvent même pas).